klaus SCHMIDT dirk BRAND
IT-REVISION IN DER PRAXIS
NACH DEN GRUNDSÄTZEN EINER ORDNUNGSGEMÄSSEN IT
Schmidt/Brand IT-Revision in der Praxis
v
Bleiben Sie einfach auf dem Laufenden: www.hanser.de/newsletter Sofort anmelden und Monat für Monat die neuesten Infos und Updates erhalten.
Klaus Schmidt Dirk Brand
IT-Revision in der Praxis
Klaus Schmidt, Neuhof,
[email protected] Dirk Brand, Borken,
[email protected]
Alle in diesem Buch enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Buch enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autoren und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen – oder Teilen davon – entsteht. Ebenso übernehmen Autoren und Verlag keine Gewähr dafür, dass beschriebene Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
Bibliografische Information der Deutschen Nationalbibliothek: Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
Dieses Werk ist urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) – auch nicht für Zwecke der Unterrichtsgestaltung – reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. © 2011 Carl Hanser Verlag München (www hanser.de) Lektorat: Margarete Metzger Herstellung: Irene Weilhart Copy editing: Jürgen Dubau, Freiburg/Elbe Umschlagdesign: Marc Müller-Bremer, www rebranding.de, München Umschlagrealisation: Stephan Rönigk Datenbelichtung, Druck und Bindung: Kösel, Krugzell Ausstattung patentrechtlich geschützt. Kösel FD 351, Patent-Nr. 0748702 Printed in Germany ISBN 978-3-446-41706-9
Für Susanne, Emily-Rose und Ainsley Slater, die in meinem Herzen wohnen. Für Irene, meine beste Hälfte, und meine Kinder Lucie, Ida und Jonas. Durch Euch bin ich vollständig.
Inhalt Vorwort................................................................................................................................XI Die Autoren.......................................................................................................................XIII
Teil I: Praxis der IT-Revision ......................................................................................... 1 1 1.1
1.2 1.3
1.4
2 2.1
Grundlagen der IT-Revision .................................................................................... 3 Das Wesen der IT-Revision .....................................................................................................3 1.1.1 Ziele der IT-Revision .................................................................................................4 1.1.2 Externe Revision ........................................................................................................7 1.1.3 Interne Revisionsarten ................................................................................................8 Mit der IT-Revision verwandte Funktionen .............................................................................9 Die IT-Revision im Unternehmen ..........................................................................................11 1.3.1 Position im Unternehmen .........................................................................................11 1.3.2 Befugnisse ................................................................................................................11 1.3.3 Mitarbeiter................................................................................................................13 1.3.4 Qualitätssicherung und Leistungsmessung ...............................................................15 1.3.5 Sicherheit der Revisionsabteilung ............................................................................18 Prüfungsaspekte .....................................................................................................................19 1.4.1 Rechtmäßigkeit.........................................................................................................19 1.4.2 Ordnungsmäßigkeit ..................................................................................................20 1.4.3 Sicherheit..................................................................................................................21 1.4.4 Zweckmäßigkeit/Funktionsfähigkeit ........................................................................22 1.4.5 Wirtschaftlichkeit .....................................................................................................23 1.4.6 Kontrollierbarkeit und Nachvollziehbarkeit .............................................................24 Prüfungsorganisation und Vorgehen................................................................... 25 Prüfungsplanung ....................................................................................................................25 2.1.1 Strategische Planung (3-Jahres-Plan) .......................................................................26 2.1.2 Jahresplanung ...........................................................................................................27 2.1.3 Planung und Vorbereitung einer einzelnen Prüfung .................................................28
VII
Inhalt 2.2 2.3
2.4
2.5
2.6
3 3.1 3.2 3.3 3.4
Zusammenspiel mit externen Wirtschaftsprüfern .............................................. 53 Aufgabe der externen Wirtschaftsprüfer ................................................................................ 53 Grundlagen der Prüfung durch einen Wirtschaftsprüfer ........................................................ 54 Vorgehen bei der Prüfung durch externe Wirtschaftsprüfer................................................... 56 Ergebnisse der internen Revision verwenden......................................................................... 57
4 4.1 4.2
Relevante Prüfungsgrundlagen............................................................................ 61 Prüfungsgrundlagen für die IT-Revision................................................................................ 61 Gesetze................................................................................................................................... 62 4.2.1 Handelsgesetzbuch (HGB) ....................................................................................... 63 4.2.2 Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG).......... 66 4.2.3 Bundesdatenschutzgesetz BDSG.............................................................................. 67 4.2.4 Telemediengesetz (TMG)......................................................................................... 69 4.2.5 SOX.......................................................................................................................... 70 Richtlinien für die IT-Revision .............................................................................................. 71 4.3.1 Allgemein................................................................................................................. 71 4.3.2 Verlautbarungen des IDW........................................................................................ 72 4.3.3 GDPdU..................................................................................................................... 73 4.3.4 GoBS........................................................................................................................ 74 Branchenvorschriften............................................................................................................. 76 4.4.1 Basel II ..................................................................................................................... 76 4.4.2 MaRisk (Mindestanforderungen an das Risikomanagement) ................................... 77 4.4.3 Solvency II ............................................................................................................... 78
4.3
4.4
VIII
Prüfungsauftrag...................................................................................................................... 30 Vorbereitung der Prüfungsdurchführung ............................................................................... 31 2.3.1 Analyse des Prüfobjekts/Voruntersuchung............................................................... 31 2.3.2 Prüfungsankündigung............................................................................................... 31 2.3.3 Kick-off-Meeting ..................................................................................................... 33 Prüfungsdurchführung ........................................................................................................... 33 2.4.1 Dokumentensichtung................................................................................................ 33 2.4.2 Fragebogenerhebung ................................................................................................ 35 2.4.3 Interviews................................................................................................................. 36 2.4.4 Verifikation der Aussagen........................................................................................ 40 Prüfungsbericht...................................................................................................................... 43 2.5.1 Dokumentation des Ist-Zustands im Prüfungsbericht............................................... 43 2.5.2 Bewertung des Ist-Zustands ..................................................................................... 44 2.5.3 Maßnahmenempfehlungen ....................................................................................... 47 2.5.4 Entwurf und Abstimmung des Prüfungsberichts ...................................................... 47 Prüfungsabschluss.................................................................................................................. 49 2.6.1 Schlussbesprechung ................................................................................................. 49 2.6.2 Vollständigkeitserklärung ........................................................................................ 50 2.6.3 Stellungnahme des geprüften Bereichs..................................................................... 51 2.6.4 Verfolgung der Umsetzung der Maßnahmen ........................................................... 51
Inhalt 5 5.1 5.2 5.3
5.4
5.5 5.6
6 6.1
6.2
7 7.1 7.2 7.3 7.4 7.5
Prüfung von IT-Verfahren...................................................................................... 79 Das Wesen eines IT-Verfahrens.............................................................................................79 Fragmentierung von Verfahrensprüfungen ............................................................................81 Prüfung der IT-Verfahrensplanung ........................................................................................83 5.3.1 Anforderungen an das neue IT-Verfahren ................................................................83 5.3.2 Einsatzplanung .........................................................................................................84 5.3.3 Einbettung in Geschäftsprozesse ..............................................................................85 5.3.4 Einbettung in die IT..................................................................................................86 Prüfung der Verfahrensdokumentation ..................................................................................87 5.4.1 Das Wesen der Verfahrensdokumentation................................................................87 5.4.2 Beschreibung der sachlogischen Lösung ..................................................................89 5.4.3 Beschreibung der technischen Lösung .....................................................................90 5.4.4 Programmidentität ....................................................................................................93 5.4.5 Datenintegrität ..........................................................................................................94 5.4.6 Arbeitsanweisungen für den Anwender....................................................................94 5.4.7 Prüfen der Verfahrensdokumentation.......................................................................95 Berechtigungskonzept ............................................................................................................97 Prüfung der Verfahrensdaten .................................................................................................99 5.6.1 Anforderungen an Daten in der Planungsphase........................................................99 5.6.2 Dateneingabe, -verarbeitung und -ausgabe.............................................................100 5.6.3 Datentransfer ..........................................................................................................101 5.6.4 Datensicherung und Archivierung..........................................................................101 5.6.5 Datenmigration.......................................................................................................102 5.6.6 Datenlöschung und -entsorgung .............................................................................103 Besondere Prüfungsgebiete ............................................................................... 105 Prüfungsgebiet Bundesdatenschutzgesetz ............................................................................105 6.1.1 BSI Grundschutzstandards und -kataloge...............................................................106 6.1.2 Vorgehen nach BSI Grundschutz ...........................................................................107 6.1.3 Umsetzung der Vorgaben anhand eines Sicherheitsrahmenkonzeptes ...................117 6.1.4 Audit eines Informationssicherheitsmanagementsystems (ISMS) nach BSI Grundschutz............................................................................................118 Prüfungsgebiet Dokumentenmanagement............................................................................120 6.2.1 Welche Rahmenbedingungen gibt es?....................................................................120 6.2.2 Bewertungsbereiche ...............................................................................................122 6.2.3 Prüfung und Zertifizierung .....................................................................................122 CobIT-Prüfungen.................................................................................................. 125 Bestimmung des Prüfungsziels ............................................................................................125 Aufnahme der bestehenden Situation...................................................................................127 Feststellung der CobIT-Erfüllung ........................................................................................128 Ermittlung des Reifegrades ..................................................................................................128 Prüfung des Ziel- und Kontrollsystems................................................................................131
IX
Inhalt 8 8.1 8.2 8.3 8.4 8.5
Tools zur Prüfungsunterstützung ...................................................................... 135 Wie alles begann .................................................................................................................. 135 Warum überhaupt Tools?..................................................................................................... 136 Welche Werkzeugarten gibt es?........................................................................................... 136 Prüfungsbegleitende Werkzeuge.......................................................................................... 137 8.4.1 Ablauf einer tool-unterstützten Prüfung ................................................................. 138 Prüfende Werkzeuge............................................................................................................ 147
Teil II: Grundsätze einer ordnungsgemäßen Informationstechnik (GoIT) .... 149 Einleitung......................................................................................................................... 151 Gliederung der IT in den GoIT......................................................................................................... 152 IT-Strukturierungsmodell..................................................................................................... 152 Fokus ............................................................................................................................... 154 IT-Lebenszyklusphasen in den GoIT................................................................................................ 155 Prüfungsaspekte in den GoIT ........................................................................................................... 156 Vorgehen bei der Anwendung der GoIT .......................................................................................... 157 A A.1
A.2 A.3
A.4
X
Physikalische Ebene ........................................................................................... 159 Planungsphase...................................................................................................................... 160 A.1.1 Bei der Planung einer physischen Einrichtung sind Sicherheitsmaßnahmen berücksichtigt worden. ........................................................................................... 160 A.1.2 Bei der Planung sind einschlägige Normen berücksichtigt worden........................ 161 A.1.3 Schützenswerte Gebäudeteile sind deklariert worden. ........................................... 162 A.1.4 Elektroversorgungsleitungen und Datenleitungen sind zukunftsorientiert geplant. . 163 A.1.5 Versorgungsleitungen sind redundant ausgelegt. ................................................... 164 Entwicklungsphase .............................................................................................................. 164 Implementierungsphase ....................................................................................................... 165 A.3.1 Bei der Realisierung sind die Anforderungen der Planungsphase berücksichtigt worden.................................................................................................................... 165 A.3.2 Beim Einzug in eine gemietete Einrichtung sind Sicherheitsmaßnahmen geprüft worden.................................................................................................................... 166 Betriebsphase ....................................................................................................................... 167 A.4.1 Der Zutritt zum Gebäude wird kontrolliert............................................................. 167 A.4.2 Es sind Schutzmaßnahmen gegen Bedrohungen von außen und aus der Umgebung getroffen worden.................................................................................. 168 A.4.3 Öffentliche Zugänge, Anlieferungs- und Ladezonen werden kontrolliert. ............. 169 A.4.4 Die Arbeit in Sicherheitszonen ist geregelt. ........................................................... 170 A.4.5 Betriebsmittel sind vor unerlaubtem Zugriff physisch gesichert. ........................... 171 A.4.6 Bei physischen Einrichtungen mit Publikumsverkehr sind die Informationsträger gesondert zu sichern. .............................................................................................. 172 A.4.7 Physische Einrichtungen, in denen sich Mitarbeiter aufhalten, sind gegen unbefugten Zutritt gesichert. .................................................................................. 173 A.4.8 Physische Sicherheitsmaßnahmen sind dokumentiert. ........................................... 174 A.4.9 Notfallmaßnahmen für physische Einrichtungen sind definiert.............................. 175
Inhalt
A.5 A.6
B B.1
B.2 B.3
B.4
B.5 B.6
C C.1
C.2
A.4.10 Notfallübungen werden durchgeführt.....................................................................176 Migration..............................................................................................................................176 Roll-Off................................................................................................................................177 A.6.1 Der Auszug aus physischen Einrichtungen ist geregelt. .........................................177 A.6.2 Betriebsmittel werden ordnungsgemäß entsorgt.....................................................178 A.6.3 Bestandsverzeichnisse sind auf dem aktuellen Stand. ............................................179 Netzwerkebene..................................................................................................... 181 Planungsphase......................................................................................................................182 B.1.1 Eine geeignete Netzwerksegmentierung ist geplant. ..............................................182 B.1.2 Bei der Planung sind Sicherheitsmaßnahmen zum Schutz des Netzwerkes getroffen worden. ...................................................................................................183 B.1.3 Das physische Netzwerk ist vor unbefugten Zugängen geschützt. .........................184 B.1.4 Ein Netzwerkrealisierungsplan ist vorhanden. .......................................................185 B.1.5 Eine geeignete Netzkopplung ist eingeplant...........................................................186 Entwicklungsphase...............................................................................................................186 Implementierungsphase........................................................................................................187 B.3.1 Das Netzwerk ist auf Engpässe überprüft...............................................................187 B.3.2 Die Verwaltung der Netzkomponenten ist zentral gesteuert...................................188 B.3.3 Eine vollständige Netzdokumentation ist vorhanden..............................................189 B.3.4 Mit Netzwerkbetreibern sind geeignete Verträge abgeschlossen............................190 B.3.5 Netzkomponenten sind sicher zu konfigurieren......................................................191 Betriebsphase .......................................................................................................................192 B.4.1 Der Netzwerkverkehr wird protokolliert. ...............................................................192 B.4.2 Die Protokolle werden regelmäßig ausgewertet und auf Unregelmäßigkeiten geprüft. ...................................................................................................................193 B.4.3 Ein Monitoring ist eingerichtet...............................................................................194 B.4.4 Das Verhalten bei Zwischenfällen ist definiert.......................................................195 B.4.5 Netzwerkadministratoren sind sorgfältig ausgewählt worden. ...............................196 B.4.6 Netzwerkspezifische Sicherheitsmaßnahmen sind dokumentiert. ..........................197 B.4.7 Notfallmaßnahmen für das Netzwerk sind definiert. ..............................................198 B.4.8 Notfallübungen werden durchgeführt.....................................................................199 Migrationsphase ...................................................................................................................199 Roll-Off................................................................................................................................200 B.6.1 Inhalte auf aktiven Netzwerkkomponenten sind ordentlich gelöscht worden.........200 B.6.2 Protokolle werden nach gesetzlichen Vorgaben vernichtet. ...................................201 Systemebene........................................................................................................ 203 Planungsphase......................................................................................................................204 C.1.1 Der Schutzbedarf des Systems ist ermittelt. ...........................................................204 C.1.2 Die sich aus dem Schutzbedarf ableitenden Sicherheitsanforderungen und -maßnahmen sind definiert. ....................................................................................205 C.1.3 Leistungs- und Kapazitätsanforderungen an das System sind definiert. .................206 C.1.4 Die Dimensionierung des Systems entspricht der zu erbringenden Leistung. ........207 C.1.5 Die Systeme folgen definierten Unternehmensstandards........................................208 Entwicklungsphase...............................................................................................................208
XI
Inhalt C.3
C.4
C.5
C.6
D D.1
D.2
D.3
XII
Implementierungsphase ....................................................................................................... 209 C.3.1 Bei erhöhtem Schutzbedarf wird das System gehärtet. .......................................... 209 C.3.2 Die Erfüllung der Leistungs- und Kapazitätsanforderungen wird nachgewiesen. .. 210 C.3.3 Die Systemfunktionen und -komponenten sind ausführlich getestet. ..................... 211 Betriebsphase ....................................................................................................................... 212 C.4.1 Alle Lizenzvereinbarungen werden eingehalten..................................................... 212 C.4.2 Das System ist vor zu langen Ausfällen geschützt. ................................................ 213 C.4.3 Die Wiederherstellung des Systems ist in der erforderlichen Zeit möglich............ 214 C.4.4 Das System wird durch Updates auf dem neuesten Stand gehalten........................ 215 C.4.5 Das System ist vor unberechtigten Zugriffen geschützt. ........................................ 216 C.4.6 Die Erfüllung der Leistungs- und Sicherheitsanforderungen wird regelmäßig analysiert und ggf. angepasst.................................................................................. 217 C.4.7 Das System ist angemessen dokumentiert.............................................................. 218 Migrationsphase................................................................................................................... 219 C.5.1 Die Systemfunktion bleibt zu jedem Zeitpunkt der Migration erhalten.................. 219 C.5.2 Für einen möglichen Fehlschlag von Änderungen/Migrationen ist ein Rollback vorhanden............................................................................................................... 220 C.5.3 Systemänderungen werden auf Seiteneffekte hin geprüft....................................... 221 C.5.4 Es gibt eine Übersicht, welche Systemeigenschaften des Altsystems denen des Neusystems entsprechen......................................................................................... 222 C.5.5 Änderungen und Migrationen unterliegen einem definierten und kontrollierten Change-Management-Prozess. ............................................................................... 223 Roll-Off ............................................................................................................................... 224 C.6.1 Alle Systemfunktionen werden nicht mehr benötigt. ............................................. 224 C.6.2 Alle Systemlizenzen erlöschen............................................................................... 225 C.6.3 Vor dem Roll-Off wird sichergestellt, dass ein zu entsorgendes, physisches System keine vertraulichen Daten mehr enthält. .................................................... 226 C.6.4 Das physische IT-System wird de-inventarisiert und die Entsorgung protokolliert............................................................................................................ 227 Applikationsebene............................................................................................... 229 Planungsphase...................................................................................................................... 230 D.1.1 Die Ziele und Aufgaben, welche die Anwendung erfüllen soll, sind definiert worden.................................................................................................................... 230 D.1.2 Die Anforderungen sind in einem Lastenheft/Anforderungskatalog konkretisiert worden.................................................................................................................... 231 D.1.3 Für die Entwicklung/Implementierung werden geeignete Ressourcen bereitgestellt. .......................................................................................................... 232 D.1.4 Die Daten, die verarbeitet werden sollen, sind klassifiziert und definiert worden.. 233 D.1.5 Eine geeignete Infrastruktur für den Betrieb wurde ausgewählt............................. 234 Entwicklungsphase .............................................................................................................. 235 D.2.1 Geeignete Vorgehensweisen zur Entwicklung sind mit den Anforderungen verglichen worden. ................................................................................................. 235 D.2.2 Die Entwicklung wird konform zur Vorgehensweise dokumentiert....................... 236 Implementierungsphase ....................................................................................................... 237 D.3.1 Quellcode ist gegen unbefugte Veränderung gesichert. ......................................... 237
Inhalt
D.4
D.5
D.6
E E.1
E.2
E.3
E.4
D.3.2 Applikationstests werden nach den Vorgaben der Planung umgesetzt. ..................238 Betriebsphase .......................................................................................................................239 D.4.1 Anforderungen der Applikation an den Betrieb sind dokumentiert. .......................239 D.4.2 Prozesse zur sicheren Applikationsverwaltung sind beschrieben. ..........................240 D.4.3 Integritäts- und vertraulichkeitssichernde Maßnahmen sind für den Betrieb beschrieben und umgesetzt.....................................................................................241 D.4.4 Etwaige Verschlüsselungsverfahren sind beschrieben............................................242 D.4.5 Prozesse für die Benutzerverwaltung innerhalb der Anwendung sind dem Betrieb bekannt und dokumentiert. .....................................................................................243 D.4.6 Eine Testumgebung der Applikation ist vorhanden................................................244 Migrationsphase ...................................................................................................................245 D.5.1 Der im Falle einer Migration durchzuführende Prozess ist definiert und dokumentiert...........................................................................................................245 D.5.2 Eine Migration erfolgt geplant................................................................................246 Roll-Off................................................................................................................................247 D.6.1 Die Benutzerverwaltung ist auch über die End-of-Life-Phase hinaus geregelt.......247 D.6.2 Betriebsmittel werden ordnungsgemäß entsorgt.....................................................248 D.6.3 Durch die Anwendung mitgenutzte Ressourcen sind durch Befugte freigegeben. .249 Inhaltsebene ......................................................................................................... 251 Planungsphase......................................................................................................................252 E.1.1 Es werden die und nur die Daten vorgesehen, die für den Geschäftszweck benötigt werden. .....................................................................................................252 E.1.2 Die Gewährleistung der Datenkonsistenz ist in der Planung berücksichtigt...........253 E.1.3 Die Gewährleistung der Datenqualität ist in der Planung berücksichtigt................254 E.1.4 Die Daten werden hinsichtlich der Kritikalität bewertet.........................................255 Entwicklungsphase...............................................................................................................256 E.2.1 Es werden möglichst keine Produktionsdaten in Entwicklungs- oder Testumgebungen verwendet. ..................................................................................256 E.2.2 Für Tests werden möglichst geeignete Testdaten verwendet..................................257 E.2.3 Testdaten werden möglichst automatisiert generiert...............................................258 E.2.4 Die Daten, die durch das entwickelte System entstehen, werden dokumentiert. ....259 Implementierungsphase........................................................................................................260 E.3.1 Es ist transparent, welche Daten in welchen Speicherorten geführt und auf welchen Datenträgern archiviert werden ................................................................260 E.3.2 Es wird kontrolliert, dass die Daten gemäß ihrer Spezifikation implementiert werden ....................................................................................................................261 Betriebsphase .......................................................................................................................262 E.4.1 Buchführungsrelevante Daten sind nach der Eingabe nicht mehr änderbar............262 E.4.2 Wichtige Daten werden vor der Speicherung validiert bzw. plausibilisiert ............263 E.4.3 Wichtige, kritische oder sensible Daten sind vor Verlust geschützt .......................264 E.4.4 Vertrauliche Daten sind nur den Personen zugänglich, für die sie bestimmt sind ..265 E.4.5 Vertrauliche bzw. personenbezogene Daten dürfen nur Personen zugänglich sein, die eine Verpflichtungserklärung zu Vertraulichkeit und Datenschutz abgegeben haben. .....................................................................................................................266 E.4.6 Der Zugriff auf vertrauliche/sensible Daten wird protokolliert ..............................267
XIII
Inhalt E.5
E.6
F F.1
F.2 F.3
F.4
F.5
Migrationsphase................................................................................................................... 268 E.5.1 Die Verfügbarkeit und Vertraulichkeit der Daten ist auch bei Änderungen und Migrationen zu jedem Zeitpunkt sichergestellt ...................................................... 268 E.5.2 Die Datensemantik wird von einer Migration nicht ungewollt verändert............... 269 E.5.3 Datenänderungen werden in einem geordneten Prozess durchgeführt ................... 270 E.5.4 Datenänderungen werden protokolliert .................................................................. 271 Roll-Off ............................................................................................................................... 272 E.6.1 Vorgeschriebene Aufbewahrungsfristen werden gewährleistet.............................. 272 E.6.2 Es ist definiert, wann und durch wen Daten gelöscht werden dürfen ..................... 273 E.6.3 Sensible Daten werden sicher, zuverlässig, dauerhaft und nachweisbar gelöscht .. 274 E.6.4 Die Vernichtung von Datenträgern mit sensiblen Daten wird geprüft und protokolliert............................................................................................................ 275 Personelle Ebene................................................................................................. 277 Planungsphase...................................................................................................................... 278 F.1.1 Aufgaben und Verantwortung von Angestellten sind definiert. ............................. 278 F.1.2 Stellenbeschreibungen werden verwendet.............................................................. 279 F.1.3 Anforderungen an besondere Stellen sind definiert................................................ 280 F.1.4 Eine Überprüfung der Angestellten fand im Einklang mit den Gesetzen statt........ 281 Entwicklungsphase .............................................................................................................. 281 Implementierungsphase ....................................................................................................... 282 F.3.1 Sicherheitsrichtlinien für Angestellte sind durch das Management in Kraft gesetzt worden........................................................................................................ 282 F.3.2 Angestellte sind Ihren Aufgaben entsprechend sensibilisiert. ................................ 283 F.3.3 Sensible Posten sind mit vertrauenswürdigen Angestellten besetzt........................ 284 F.3.4 Angestellte haben den vertraglichen Vereinbarungen ihrer Posten zugestimmt..... 285 Betriebsphase ....................................................................................................................... 286 F.4.1 Angestellte werden regelmäßig über die geltenden Regelungen informiert. .......... 286 F.4.2 Sanktionen sind definiert........................................................................................ 287 F.4.3 Mitarbeiter sind ausreichend geschult. ................................................................... 288 Roll-Off ............................................................................................................................... 289 F.5.1 Die Verantwortlichkeiten für das Ausscheiden der Angestellten sind geregelt. ..... 289 F.5.2 Alle organisationseigenen Wertgegenstände sind zurückgenommen worden. ....... 290
Literaturhinweise ............................................................................................................ 291 Register............................................................................................................................ 293
XIV
Vorwort Die IT-Revision ist als Teil der internen Revision in den meisten größeren Unternehmen1 ein etablierter Bestandteil der Unternehmensorganisation. Für viele im Unternehmen ist sie jedoch ein Buch mit sieben Siegeln. Zwar existiert für die funktionale Informationstechnik2, d h. Softwareprodukte, Netzwerktechnik usw. eine Fülle von Literatur, das Literaturangebot im Revisionsbereich hält sich jedoch in Grenzen und der Großteil der Revisionsliteratur bezieht sich eher allgemein auf die interne Revision und nicht speziell auf die ITRevision. Das vorliegende Werk hat aus diesen Gründen zwei Intentionen: Zum einen soll dargestellt werden, was die IT-Revision ist, wie sie aufgebaut ist und wie sie arbeitet, um Personen einen Ein- und Überblick zu geben, die bislang noch keine Vorstellung von oder Berührung mit der IT-Revision hatten. Zum anderen sollen Mitarbeiter3 der IT-Revision und andere Revisions-Insider methodische und inhaltliche Hinweise finden, die in der täglichen Revisionspraxis hilfreich sein können. Dazu wurde das Buch in zwei Teile geteilt: Teil I beschreibt das Wesen der IT-Revision und ihre Aufgabe: die Durchführung von Revisionsprüfungen. Nachdem in Kapitel 1 auf die Grundlagen der IT-Revision eingegangen wurde, wird in Kapitel 2 die Organisation von IT-Revisionsprüfungen beschrieben. Ein Punkt, der in Zusammenhang mit der Organisation steht, ist das Zusammenspiel zwischen der internen IT-Revision und externen Wirtschaftsprüfern, dies ist Thema von Kapitel 3. Einen Überblick über häufig verwendete Prüfungsgrundlagen bietet Kapitel 4, bevor in Kapitel 5 dann die Prüfung von IT-Verfahren behandelt wird, eine der primären Aufgaben der IT-Revision. Sich dabei ergebende, besondere Prüfungsgebiete werden in Kapitel 6 1
Wenn in diesem Buch von Unternehmen die Rede ist, sind damit in gleicher Weise auch andere Organisationen wie Behörden, Körperschaften usw. gemeint. 2 Wenn in diesem Buch der Begriff Informationstechnik bzw. IT verwendet wird, ist damit in gleicher Weise die Kommunikationstechnik bzw. Telekommunikation (TK) gemeint. Auf vereinende Abkürzungen wie IuK oder ITK wurde weitgehend verzichtet. Sie wurden nur dort verwendet, wo es im Sinnzusammenhang notwendig erschien. 3 Wenn bei personellen Bezeichnungen die männliche Form gewählt wurde (z.B. Mitarbeiter, Administrator), so ist damit in gleicher Weise die weibliche Form (Mitarbeiterin, Administratorin) gemeint.
XV
Vorwort vorgestellt, wobei es sich dabei angesichts der Breite von IT-Themen nur um eine kleine Auswahl handeln kann. Einer speziellen Art von IT-Revisionsprüfungen, der Prüfung nach dem CobIT-Standard, wurde mit Kapitel 7 ein eigenes Kapitel gewidmet. Kapitel 8 schließlich rundet den ersten Teil mit Betrachtungen zum Tooleinsatz in der IT-Revision ab. Teil II besteht aus den Grundsätzen für eine ordnungsgemäße Informationstechnik (GoIT). Diese Grundsätze sind in Form von Anforderungen formuliert, die in sechs logisch gegliederte Bereiche („Schichten“) aufgeteilt sind. Dieser „Anforderungskatalog“ soll Hilfestellungen für IT-Revisoren bei der Durchführung von IT-Revisionsprüfungen bieten. Zum einen lassen sich aus den in den Anforderungen aufgeführten Prüfungsfragen Checklisten für die Prüfungen erstellen, zum anderen wird die Argumentation gegenüber den geprüften Bereichen unterstützt (z.B. durch die Verweise auf die Vorgaben oder auf die potenziellen Folgen der Nichterfüllung). Ergänzend zu diesem Buch haben die Autoren eine tabellarische Arbeitshilfe in Microsoft Excel erstellt. Um sie zu erhalten, gehen Sie wie folgt vor: 1. Rufen Sie in Ihrem Webbrowser die Adresse http://downloads.hanser.de auf. 2. Geben Sie im Suchfeld die ISBN dieses Buches (978-3-446-41706-9) oder einen der Autorennamen oder den Titel an. 3. Laden Sie sich die Datei mit dem Namen „GoIT.xls“ herunter. Danksagungen Genau wie ein Film nicht nur vom Regisseur gemacht wird, ist dieses Buch nicht nur von den Autoren geschrieben worden. Daher möchten wir uns bei allen bedanken, die zum Entstehen und Gelingen dieses Buches beigetragen haben, und dies seit dem Tag, an dem ein Projekt bei einer Versicherung in Wiesbaden den Anstoß zu diesem Buch gab. An erster Stelle ist hier unsere Lektorin Frau Metzger zu nennen, die mit viel Geduld und Mühe den Entstehungsprozess begleitete, sowie unsere Familien, die uns in dieser Zeit oft entbehren mussten. Dank sei dem Institut für interne Revision (IIR), sowie Frau Gabriele Rinke und Herrn Ralf Kapitulski von der Delta Lloyd Deutschland für so manchen guten Hinweis. Zu erwähnen sind noch Benedikt Kisner und Patrick Kruse, die Zeit und Ressourcen zur Verfügung gestellt haben, das NETGO Systemhaus für die technische Unterstützung und Markus Olbring und Dennis Siegert für ihre Tipps und Tricks. Dirk Brand möchte ausdrücklich seinem ehemaligen Professor Herrn Dr. Kruse danken, ohne dessen Kommentare er seinen beruflichen Werdegang nicht so erfolgreich hätte gehen können. Ebenso danken wir allen anderen, die in Gesprächen und Diskussionen einen Beitrag zu diesem Buch geleistet haben. Allen, die konstruktive Kritik geübt und Hinweise gegeben haben: Ein herzliches Dankeschön dafür! Neuhof und Borken, im Herbst 2010 Klaus Schmidt und Dirk Brand
XVI
Die Autoren Dipl.-Inform. Klaus Schmidt ist Geschäftsführer der Innomenta GmbH & Co. KG, die Unternehmen in IT-Themen an der Schnittstelle zwischen Management und Technik unterstützt (IT-Revision, Security Management, Identity Management). Er ist Mitbegründer des ValueProtect-Konsortiums mit der Zielrichtung einer ganzheitlichen Sicherheit. Zahlreiche Publikationen, Seminare, die Ausbildung von Security Managern und ein Lehrauftrag an der Hochschule Fulda ergänzten bislang seine Tätigkeit, für die er Zertifizierungen zum Information Security Manager (CISM) und zum ISO27001-Trainer erlangt hat. Dirk Brand ist leitender Berater bei der SILA Consulting GmbH mit den Schwerpunkten IT-Revision und Informationssicherheitsmanagement nach nationalen und internationalen Standards, sowie Mitbegründer des ValueProtect-Konsortiums mit der Zielrichtung einer ganzheitlichen Sicherheit. Seminare zu den Themen Informationssicherheit und die Ausbildung ergänzen seine Tätigkeit, für die er Zertifizierungen zum TeleTrust Information Security Professional (T.I.S.P) und ISO27001-Trainer erlangt hat.
XVII
I Teil I: Praxis der IT-Revision
1
1 1 Grundlagen der IT-Revision Dieses Kapitel soll Sie in die Welt der IT-Revision einführen. Dazu ist zunächst zu klären, was unter Revision zu verstehen ist, und damit auch, was eine Revisionsabteilung tut und welche Ziele und Aufgaben sie besitzt. Ebenfalls zu den Grundlagen gehört die Frage, wie eine solche IT-Revision im Unternehmen eingebettet ist und wo Berührungspunkte mit anderen Abteilungen bzw. Bereichen existieren.
1.1
Das Wesen der IT-Revision Befragt man das beliebte Online-Lexikon Wikipedia nach dem Stichwort „Revision“, so bekommt man die Auskunft, dass sich der Begriff aus dem Verb revidieren ergibt, das sich aus dem lateinischen „re“ (Rückschau oder Überprüfung) und „videre“ (ansehen) zusammensetzt. Schon aus dem Begriff „IT-Revision“ ergeben sich damit drei wichtige Eigenschaften: Die IT-Revision konzentriert sich auf Dinge der Informationstechnik. Sie beschäftigt sich mit Dingen, die im Zusammenhang mit der Gestaltung, dem Betreiben, dem Management oder der Nutzung der Informationstechnik stehen. Diese Dinge können sehr unterschiedlicher Natur sein, z.B. Vorgänge (Migration eines Software-Systems) oder Objekte (z.B. ein Rechenzentrum). Die IT-Revision schaut sich diese Dinge im Unternehmen an und prüft sie. Das Anschauen besteht zunächst darin, den bestehenden Zustand festzustellen. In einem zweiten Schritt wird geprüft, ob dieser Zustand die Vorgaben erfüllt bzw. einhält, die von externen Instanzen (Gesetzgeber, Aufsichtsbehörden usw.) oder vom Unternehmen selbst gestellt werden. Diese Prüfung ist die zentrale Tätigkeit der Revision. Die IT-Revision schaut sich die Dinge nachträglich an. Im Fokus der IT-Revision liegen die Dinge, die bereits geschehen sind und damit ein Faktum darstellen, und nicht Dinge, die geschehen werden oder könnten1. 1
Damit ist die Prüfung bzw. Untersuchung zukünftiger Dinge gemeint, nicht das Ausblenden zukünftiger Entwicklungen, denn die IT-Revision macht sich sehr wohl Gedanken darüber, was aufgrund des bestehenden Zustandes in Zukunft geschehen könnte.
3
1 Grundlagen der IT-Revision Bisher noch unbeantwortet ist die Frage, warum es die Revision überhaupt gibt. Die oben erwähnten Vorgaben werden schließlich an die Fachbereiche gestellt und müssen von ihnen erfüllt bzw. eingehalten werden. Doch da beginnen die Probleme: Nicht selten wissen die Fachbereiche gar nicht, welche Vorgaben sie erfüllen müssen. Das gilt insbesondere dann, wenn Fachbereiche IT-Themen bearbeiten und nicht mit den Anforderungen an die Informationsverarbeitung vertraut sind. Praxistipp
Veranstalten Sie kurze Info-Workshops in den Fachbereichen und erläutern Sie den Fokus der bestehenden Soll-Vorgaben für die IT. Als Teilnehmer kommen alle Personen in Frage, die im Fachbereich mit IT-Aufgaben betraut sind.
Selbst wenn die Vorgaben bekannt sind, heißt das nicht, dass sie auch erfüllt werden, denn das primäre Interesse der Fachbereiche liegt woanders. Um die Konformitäten zu kontrollieren, wird daher eine von der Linie unabhängige Instanz wie die Revision benötigt.
1.1.1
Ziele der IT-Revision
Welche Zwecke verfolgt nun die IT-Revision? In der Regel sind es folgende Zielsetzungen, die sich die IT-Revision selbst gibt oder die vom Top-Management2 vorgegeben werden: Schutz des Unternehmens vor Bestrafung Eines der primären Ziele der Revisionstätigkeit liegt darin sicherzustellen, dass das Unternehmen nicht dafür belangt werden kann, dass gesetzliche oder aufsichtsrechtliche Vorgaben nicht eingehalten werden. Dies gilt insbesondere für strafrechtlich relevante Handlungen, die beispielsweise durch Missbrauch der Informationstechnik vorgenommen werden. Schutz des Unternehmens vor Schäden Es ist Aufgabe der Managementebene, das Unternehmen vor Schäden zu schützen. Jedes größere Unternehmen sollte dazu ein Risiko- und Sicherheitsmanagement einrichten. Große Kapitalgesellschaften sind dazu durch das Gesetz der Kontrolle und Transparenz im Unternehmensbereich (KonTraG) sogar gesetzlich verpflichtet. Die IT-Revision kann ein solches Sicherheitsmanagement unterstützen, indem sie prüft, ob es in den Fachbereichen Abweichungen von den internen und externen Sicherheitsrichtlinien gibt, die zu Schäden im Unternehmen führen können. Ziel ist es, die Entstehung der Schäden rechtzeitig mit entsprechenden Maßnahmen zu verhindern. Die Betrachtung ist allerdings begrenzt auf die Abweichungen von den Richtlinien. Schädliche Entwicklungen, die andere Ursachen haben, können von der IT-Revision nicht er-
2
4
Unter dem „Top-Management“ wird hier und im Folgenden die oberste Leitungsebene verstanden, z.B. Vorstand einer AG, Geschäftsführung einer GmbH usw.
1.1 Das Wesen der IT-Revision kannt werden. Deshalb kann das Unternehmen nicht auf ein Sicherheitsmanagement verzichten und sich alleine auf die IT-Revision verlassen. Berücksichtigung von berechtigten Interessen Dritter Unter dem berechtigten Interesse von Dritten sind alle Verpflichtungen gegenüber Geschäftspartnern, Kunden, Lieferanten, der Öffentlichkeit usw. zusammengefasst. Diese sind in der Regel vertraglich festgelegt, anderweitig vereinbart oder ergeben sich aus allgemeinen Grundsätzen. Auf der einen Seite wird in Prüfungen der IT-Revision kontrolliert, ob die bestehende Situation im geprüften Bereich gegen Verträge und Vereinbarungen verstößt. Auf der anderen Seite wird gleichzeitig geprüft, ob die betrachteten Dritten (Vertragspartner etc.) ihrerseits in der bestehenden Situation den vereinbarten Pflichten nachkommen. Auch die Vereinbarungen selbst sind meist Bestandteil der Prüfung. So wird untersucht, ob die Verträge bzw. Vereinbarungen Passagen enthalten, die gegen das berechtigte Interesse des Unternehmens gerichtet oder gar für das Unternehmen nicht hinnehmbar sind. In diesem Fall wird also nicht nur gegen die Vorgaben (Vertrag/Vereinbarung) geprüft, die Vorgabe selbst wird gegen das Unternehmensinteresse und allgemeine Vertragsgrundsätze geprüft. Identifizierung von Gefährdungen und Risiken Ähnlich wie beim Schutz vor Schäden obliegt auch die Identifizierung von Gefährdungen und Risiken der Managementebene innerhalb des Risiko- und Sicherheitsmanagements. Es ist jedoch gängige Praxis, durch risikoorientierte Prüfungen der Revision die Ergebnisse des Risiko- und Sicherheitsmanagements zu verifizieren. Nicht selten sind die Ergebnisse der Revision sogar die einzige Risikoidentifikation. Bei der risikoorientierten Revisionsprüfung wird der bestehende Zustand dahingehend untersucht, welche Risiken sich für das Unternehmen aus diesem Zustand ergeben. Grundlage für die Prüfung sind beispielsweise allgemeine Sicherheitsstandards, Normen, branchenübliche Maßstäbe oder Best-Practice-Ansätze (siehe dazu auch Kapitel 4). Erkennung von Schwachstellen und Lücken Neben risikobehafteten Umständen in der bestehenden Situation kann es auch Schwachstellen und Lücken geben, die nicht direkt ein Risiko für das Unternehmen darstellen. Beispielsweise könnten Änderungen in der IT sehr umständlich und bürokratisch sein. Dies ist nicht unmittelbar ein Risiko, beeinträchtigt aber die Performance, die Wirtschaftlichkeit und die Fehleranfälligkeit des Änderungsprozesses. Die Erkennung solcher Schwachstellen und Lücken wird daher bei der Revisionsprüfung erwartet. Bei einem Revisionsergebnis „Keine Mängel“ geht das Top-Management meist davon aus, dass nicht nur keine Verstöße gegen Gesetze und Vorschriften vorliegen, sondern beim Prüfobjekt auch keine Ungereimtheiten, Auffälligkeiten, Schwachstellen oder Lücken gefunden wurden, die es zu beheben gilt.
5
1 Grundlagen der IT-Revision Die Suche nach den Ursachen von gefundenen Schwachstellen und Lücken gehört nicht zwingend zum Aufgabenspektrum der IT-Revision, sie kann aber in vielen Fällen von der IT-Revision übernommen werden. Es kommt zum einen darauf an, wie die IT-Revision im Unternehmen gesehen wird und welchen Auftrag sie vom Top-Management bekommt, zum anderen müssen für eine Ursachenermittlung die notwendigen Ressourcen und das benötigte Know-how vorhanden sein. Erhaltung der Leistungsfähigkeit des Unternehmens Das Ziel der Erhaltung der Leistungsfähigkeit des Unternehmens ist eng mit dem Ziel des Erkennens von Schwachstellen und Lücken verbunden. Nicht selten ist eine Revisionsprüfung die erste Betrachtung des bestehenden Zustands bei einem Prüfobjekt. Die unabhängige, systematische und an Soll-Vorgaben orientierte Prüfung bringt oft Dinge ans Tageslicht, die lange Zeit nicht auffallen, weil man zu sehr auf das normale Tagesgeschäft konzentriert ist. Die Entdeckung von Fakten, die ein IT-Objekt, einen IT-Prozess oder einen IT-relevanten Managementbereich ineffektiv, unnötig kompliziert, langsam, teuer oder unpassend machen, hilft dem Unternehmen, behindernde Faktoren bei der IT-gestützten Leistungserbringung zu erkennen und auszuräumen. Damit wird die Leistungsfähigkeit des Unternehmens erhalten oder sogar verbessert. Gewährleistung des internen Kontrollsystems Das interne Kontrollsystem (IKS) soll sicherstellen, dass bestimmte Dinge im Unternehmen so gestaltet sind bzw. so ablaufen, wie sie vom Unternehmen geplant wurden. Die Revision ist nun sozusagen die „Kontrolle des Kontrollsystems“, denn auch in das IKS können sich Schwachstellen und Lücken einschleichen. Daher werden die in den Prozessen verankerten Kontrollen, die Kontrollmethodik und das Kontrollvorgehen in den Revisionsprüfungen berücksichtigt. Dies geschieht entweder, indem man eine eigene Revisionsprüfung ansetzt, die explizit das jeweilige IKS untersucht, oder bei jeder Prozessrevisionsprüfung wird das IKS mit untersucht. Unterstützung und Entlastung des Top-Managements Die Verantwortung für die Einhaltung von Rechtsvorschriften liegt beim Top-Management (Vorstand, Geschäftsführung). Angesichts der Vielzahl von Vorgaben und der Komplexität der heutigen Informationstechnik ist das Top-Management jedoch selbst nicht in der Lage zu beurteilen, ob das Unternehmen den geltenden Bestimmungen entspricht. In dieser Situation schafft die IT-Revision die Informationsgrundlage, mit der das TopManagement diese Beurteilung vornehmen kann. Das Top-Management sollte daher von der IT-Revision ungeschönte und interessensfreie Informationen bekommen. Und die ITRevision leistet noch mehr: Indem sie Verbesserungsvorschläge macht, sorgt sie mit dafür, dass die Prozesse ihren Anforderungen genügen. Nicht selten kommt es dabei jedoch zu Diskussionen und Auseinandersetzungen mit den Fachbereichen.
6
1.1 Das Wesen der IT-Revision Empfehlung von Verbesserungen Neben der Aufdeckung von Mängeln ist die Empfehlung von Verbesserungen ein wichtiger Bestandteil der Revisionsarbeit. Die geprüften Bereiche werden mit dem Prüfungsergebnis nicht alleine gelassen, vielmehr bekommen sie von der IT-Revision auch Hinweise, wie die Situation so verbessert werden kann, dass keine oder zumindest keine schwerwiegenden Mängel mehr existieren. Dazu empfiehlt die IT-Revision die Durchführung von geeigneten Maßnahmen, um eine Situation zu schaffen, in der die Anforderungen erfüllt werden, die für das Prüfobjekt existieren. Bei der Empfehlung von Maßnahmen sollte jedoch nicht anmaßend vorgegangen werden. Beurteilung von IT-relevanten Themen im Unternehmen Die IT-Revision ist für das Management eine gute Informationsquelle. Die Revisoren sind kompetent, nicht in das Interessensgeflecht der operativen Unternehmensorganisation („Linie“) verstrickt und haben einen guten Über- und Einblick, was die Informationstechnik des Unternehmens betrifft. Daher wird die Meinung der IT-Revision meist geschätzt, wenn es um Planungen oder Projekte in der IT geht. Die IT-Revision kann über bestehende Soll-Vorgaben informieren und Gutachten zu IT-relevanten Sachverhalten erstellen, wenn es um die Erfüllung der Soll-Vorgaben geht. Auch die Integration von Informationstechnik in das Unternehmen kann von der IT-Revision beurteilt werden. Es ist jedoch nicht Aufgabe der Revision, sich am operativen Geschäft des Unternehmens zu beteiligen, d.h. an Planungen oder ihrer Umsetzung inhaltlich mitzuarbeiten. Sie wird sich daher stets auf eine beratende Funktion zurückziehen. Von der IT-Revision kann auch eine „zweite Meinung“ eingeholt werden, die unabhängig von der operativen Unternehmensorganisation („Linie“) ist, da die IT-Revision selbst keine Managementfunktion hat und keine Entscheidungen in den Fachbereichen trifft. Ob und inwieweit die IT-Revision genutzt wird, um schon im Vorfeld spätere Mängel zu verhindern, ist von Unternehmen zu Unternehmen sehr unterschiedlich.
1.1.2
Externe Revision
Die Revision kann grob in externe und interne Revision unterschieden werden. Die externe Revision prüft regelmäßig von außen, ob das Unternehmen den gesetzlichen und behördlichen Bestimmungen entspricht. Diese Prüfung wird von Wirtschaftsprüfern vorgenommen. Sie ist auch zuständig, wenn das Top-Management oder die Revision selbst geprüft werden soll. Wozu aber die Doppelarbeit? Kann der externe Prüfer nicht einfach die Ergebnisse der internen IT-Revision übernehmen? In der Tat werden die Ergebnisse der internen ITRevision nicht unberücksichtigt bleiben, aber sie einfach zu übernehmen, ist jedoch aus mehreren Gründen nicht statthaft:
7
1 Grundlagen der IT-Revision Die Zielsetzungen sind verschieden. Die Zielsetzungen der internen IT-Revision (siehe Abschnitt 1.1.1) und die Zielsetzungen der externen Revision sind nicht deckungsgleich. Ziele wie die Erhaltung der Leistungsfähigkeit des Unternehmens oder der Schutz vor verkraftbaren Schäden haben für die externe Revision keine Bedeutung. Daher wären die internen Revisionsberichte für die externe Revision nur eingeschränkt aussagekräftig. Die Prüfungsgrundlagen sind verschieden. Nicht nur die Zielsetzungen, auch die zugrunde gelegten Soll-Vorgaben (Prüfungsgrundlagen) sind unterschiedlich. Interne Richtlinien des Unternehmens haben für die externe Revision keine Bedeutung, auch aus diesem Grund sind die internen Revisionsberichte für die externe Revision nicht direkt verwertbar. Die Prüfungsergebnisse sind nicht unabhängig. Der plausibelste und wichtigste Grund besteht darin, dass die Revisionsergebnisse der externen Revision völlig unabhängig vom geprüften Unternehmen sein müssen. Die internen Revisoren besitzen zwar im Unternehmen eine unabhängige Stellung und arbeiten losgelöst von der Linie, sie werden aber nach wie vor vom eigenen Unternehmen bezahlt. Mehr zur externen Revision und dem Zusammenspiel mit der internen Revision findet sich in Kapitel 3.
1.1.3
Interne Revisionsarten
Die interne Revision wird in mehrere Revisionsbereiche unterteilt, die sich dadurch unterscheiden, dass sie jeweils andere Prüfobjekte untersuchen, andere Prüfungsgrundlagen verwenden und teilweise verschiedene Prüfungsaspekte betrachten. Die Revisionsmethodik bleibt dabei gleich. Kaufmännische Revision Im Zentrum der kaufmännischen bzw. betriebswirtschaftlichen Revision stehen die Geschäftsprozesse des Unternehmens, unterteilt in die Kernprozesse und die wertschöpfungsbegleitenden, betriebswirtschaftlichen Prozesse. IT-Revision Wie bereits weiter oben beschrieben, konzentriert sich die IT-Revision auf die Beschaffenheit, den Betrieb, das Management und die Nutzung der Informationstechnik. Da die Geschäftsprozesse moderner Unternehmen intensiv durch die IT unterstützt werden, hat die IT-Revision an Bedeutung gewonnen. Technische Revision Die technische Revision prüft technische Einrichtungen im Unternehmen wie Fahrzeuge, Maschinen oder bauliche Einrichtungen. Besonderes Augenmerk liegt dabei auf der Betriebssicherheit der Prüfobjekte. In einigen Bereichen gibt es noch speziell ausgeprägte, branchenspezifische Revisionsarten, die jedoch hier nicht näher beleuchtet werden sollen.
8
1.2 Mit der IT-Revision verwandte Funktionen
1.2
Mit der IT-Revision verwandte Funktionen Mit den Tätigkeiten Erheben, Prüfen, Kontrollieren, Empfehlen und Beraten steht die ITRevision nicht alleine im Unternehmen. Es gibt mehrere Funktionsbereiche im Unternehmen, die ähnliche Zielsetzungen besitzen. Im Unterschied zu diesen anderen Funktionsbereichen ist die IT-Revision nicht in das operative Geschäft involviert. Sie trifft keine geschäftlichen Entscheidungen und beeinflusst nicht direkt die Planungen und Vorgehensweisen. Sie ist nicht in der Pflicht, die bestehende Situation in den geprüften Bereichen zu verbessern, und ist aufgrund der fehlenden Weisungsbefugnis3 dazu auch nicht in der Lage. Die Steuerung des Zustands der Prüfobjekte liegt in der Verantwortung des jeweiligen Fachbereichs. Externe Soll-Vorgaben wie Gesetze sind für das Unternehmen verpflichtend und können nicht umgangen werden. Wie in Abschnitt 1.4 gezeigt wird, ist es mit der Prüfung auf Gesetzeskonformität jedoch nicht getan. Für die Prüfung weiterer Prüfungsaspekte werden interne Vorgaben benötigt. Durch eine geschickte Auswahl bzw. eine Minimierung der Vorgaben kann beeinflusst werden, ob die Prüfungsergebnisse besser oder schlechter ausfallen. Die IT-Revision ist nicht verantwortlich dafür, welche Vorgaben vom Management für die einzelnen Bereiche festgelegt werden. Es ist jedoch vielfach sinnvoll, dass ihre Beratungsfunktion auch bei der Auswahl der Vorgaben in Anspruch genommen wird. Erstellt das Unternehmen eigene Richtlinien und Standards, so ist es möglich, die IT-Revision im Erstellungsprozess zu konsultieren. Schließlich ist es auch möglich, eine Revisionsprüfung dahingehend durchzuführen, dass festgestellt wird, ob die Vorgaben ausreichend sind bzw. die richtigen Vorgaben gewählt wurden. IT-Controlling Das IT-Controlling ist eine Überwachungs- bzw. Kontrollinstanz im operativen Management, die folgende Aufgaben besitzt: Überwachung der IT-Kosten (Budget- und Investitionskontrolle, Leistungsverrechnung) Überwachung der effektiven Gestaltung und Entwicklung der IT (Zielerfüllung, Projektpriorisierung) Kontrolle der Ausrichtung an der IT- und Unternehmensstrategie (Verfolgen der Übereinstimmung zwischen IT-Entscheidungen und der Strategie) Aus der Aufstellung ist ersichtlich, dass die Aufgaben des IT-Controllings etwas anders gelagert sind als die der IT-Revision. Beispielsweise liegt die kostengerechte Leistungsverrechnung nicht im Fokus der Revisionsbetrachtung. Dennoch sind IT-Controller wichtige Ansprechpartner für die IT-Revision.
3
Eine Ausnahme wäre eine Situation, in der eine akute Gefahr erkannt wird. Für diesen Fall sollte die Revision die Vollmacht besitzen, gefahrabwendende Schritte anordnen zu können.
9
1 Grundlagen der IT-Revision IT-Qualitätsmanagement Ziel des IT-Qualitätsmanagements ist die Steuerung und Verbesserung der IT-Qualität, vor allem die Qualität der erbrachten IT-Dienste für die Fachbereiche. In der Qualitätsplanung wird festgelegt, was unter dieser Qualität zu verstehen ist und welche Ausprägung sie besitzen soll oder muss. In der Qualitätssicherung werden Maßnahmen wie Qualitätsprüfungen ergriffen, um diese Qualität zu erreichen und zu erhalten. Die Prüfung der Konformität zu bestehenden Richtlinien gehört nicht zu den Aufgaben des IT-Qualitätsmanagements. IT-Risiko- und IT-Sicherheitsmanagement Wie der Name schon sagt, ist diese Funktion ein umfangreicher Managementbereich, der den Schutz gegen IT-Risiken wie Ausfall, Manipulation oder Ausspähung organisiert. Da die Sicherheit auch ein wichtiger Prüfungsaspekt der IT-Revision ist, gibt es hier eine inhaltliche Schnittmenge. Die Analyse der IT-Risiko- bzw. -Sicherheitssituation ist jedoch nur ein Teilbereich des IT-Sicherheitsmanagements. Das Prüfspektrum der IT-Revision geht weit über den Aspekt Sicherheit hinaus. IT-Governance Die Funktion der IT-Governance ist der auf die Informationstechnik bezogene Ansatz der Corporate Governance. Im Mittelpunkt der IT-Governance steht das Zusammenspiel zwischen dem Gesamtunternehmen und dem IT-Bereich: Die Eignung der IT, die Geschäftstätigkeit adäquat zu unterstützen (Business-IT-Alignment) Die Konformität der IT mit der Unternehmensstrategie Die Ermittlung der Anforderungen und Erwartungen an die IT und das Verfolgen ihrer Erfüllung Entsprechend diesen Schwerpunkten ist die Funktion der IT-Governance im strategischen Management angesiedelt (z.B. IT-Vorstand, CIO4). Im Gegensatz zur Revision ist die ITGovernance keine prüfende, sondern eine führende Funktion, d h. sie stellt keine Nachbetrachtungen an wie die Revision, sondern agiert „mitten im Geschehen“. IT-Compliance Ziel der IT-Compliance ist die Erfüllung der Soll-Vorgaben, die an die IT des Unternehmens gestellt werden. Das klingt deckungsgleich zur IT-Revision. Doch die IT-Compliance ist meist eine Funktion und kein Bereich, der als eigenständige Organisationseinheit in der Aufbauorganisation des Unternehmens verankert ist.
4
10
Chief Information Officer
1.3 Die IT-Revision im Unternehmen Datenschutz Diese Funktion kümmert sich um den Schutz personenbezogener Daten. Ziel ist die Wahrung des informationellen Selbstbestimmungsrechtes. Die Funktion wird in den meisten Fällen von einem vom Unternehmen bestellten Datenschutzbeauftragten wahrgenommen. Der Datenschutzbeauftragte prüft, ob die Erhebung, Speicherung, Verarbeitung und Nutzung personenbezogener Daten konform zu den geltenden Datenschutzbestimmungen (z.B. BDSG, siehe dazu Kapitel 4) erfolgt. Er erstellt datenschutzrechtliche Gutachten und gibt Empfehlungen an die Fachbereiche. Damit ähnelt seine Tätigkeit strukturell der Arbeit der IT-Revision, er wird jedoch in der Regel auf Anforderung tätig und beschränkt sich, wie beschrieben, auf personenbezogene Daten.
1.3
Die IT-Revision im Unternehmen 1.3.1
Position im Unternehmen
Für die Aufbauorganisation stellt sich die Frage, an welcher Stelle im Unternehmensgefüge die IT-Revision anzusiedeln ist. Da es um die Informationstechnik geht, könnte der erste Gedanke sein, die IT-Revision in den IT-Bereich einzugliedern. In diesem Fall wäre der IT-Leiter bzw. der IT-Vorstand der Vorgesetzte des Revisionsleiters. Es liegt auf der Hand, dass sich eine solche Platzierung in der Linie verbietet. In der Regel wird die Revision direkt unter dem Top-Management platziert. Damit ist die IT-Revision unabhängig und nur dem Top-Management gegenüber verantwortlich. Eine Ausnahme bildet der Fall, dass bei einer Revisionsprüfung entdeckt wird, dass schwerwiegende Verstöße mit Wissen bzw. Billigung oder sogar auf Veranlassung des Top-Managements stattfinden. In diesem Fall könnte das Top-Management die Verstöße vertuschen, wenn die Revision nur das Top-Management informiert. Daher muss in diesen Fällen auch eine externe Information (je nachdem Aufsichtsrat, Aufsichtsbehörde usw.) erfolgen. In großen Umgebungen kann es zusätzlich zur zentralen Revision noch Revisionsbeauftragte in den Fachbereichen geben, die von der Leitung des Bereichs benannt werden. Sie sind zum einen Ansprechpartner für die zentrale Revision, zum anderen wirken sie in den Fachbereich hinein. Die Bewertungen liegen weiterhin bei der zentralen Revision, daher müssen die Revisionsbeauftragten nicht unabhängig von der Linie sein.
1.3.2
Befugnisse
Die Position direkt unter dem Top-Management besitzt neben der Unabhängigkeit von der Linie einen entscheidenden Vorteil: Die Revision gewinnt dadurch an Gewicht und Respekt im Unternehmen. Voraussetzung ist, dass das Top-Management hinter der Revision steht. Das bedeutet:
11
1 Grundlagen der IT-Revision 1. Das Top-Management nimmt die Revision ernst und betrachtet sie nicht als AlibiVeranstaltung. Handelt das Top-Management nach der Devise: „Es muss was geschehen, aber es darf nichts passieren“, dann wird eine sachgerechte Arbeit für die Revision sehr schwierig. 2. Das Top-Management gibt der Revision Rückendeckung. Hält das Top-Management bei Konflikten mit den Fachbereichen immer zum Fachbereich, dann wird die Autorität der Revision untergraben, und sie wird nicht mehr ernst genommen. Ähnliches gilt, wenn ständig beschwichtigt wird („Dann verlegen Sie doch die Prüfung in den Herbst, damit endlich Ruhe ist“). 3. Die Revision wird personell, finanziell, mit Sachmitteln und Vollmachten ausreichend ausgestattet. Folgende Punkte sollten beachtet werden: Der Auftrag für Revisionsprüfungen sollte immer vom Top-Management kommen. Die Fachbereiche sollten gehalten sein, die Revision bei Prüfungen uneingeschränkt zu unterstützen. Vom Fachbereich angeführte Gründe, warum eine Prüfung nicht durchgeführt werden kann, sind in der Regel als Mangel zu werten (z.B. mangelnde Verfügbarkeit von Personen). Die Fachbereiche sollten gehalten sein, alle erforderlichen Unterlagen und Informationen unverzüglich und vollständig zur Verfügung zu stellen, z.B. Unterlagen, Einblick in Prozesse, Zutritt zu Räumen, Revisionszugriff auf Systeme. Die Revision sollte das Recht zum Zugang zu allen Informationen erhalten, die für die Prüfungen benötigt werden. Das sollte auch für vertrauliche Informationen gelten. Es sollte keine prüfungsfreien Räume (im Sinne von ungeprüften Prüfobjekten) geben. Alle Fachbereiche sollten eine Informationspflicht gegenüber der Revision haben (d h. von sich aus die Revision informieren), wenn dem Fachbereich schwerwiegende Mängel bekannt werden, im Fachbereich ein Verdacht für ein Fehlverhalten besteht, Änderungen am internen Kontrollsystem (IKS) vorgenommen werden. Die Revision sollte ein Weisungsrecht besitzen, wenn Gefahr im Verzug ist, wenn also beispielsweise begründeter Verdacht besteht, dass ein Fehlverhalten verschleiert oder ein Beweismittel vernichtet werden könnte. Praxistipp
Immer wieder sträuben sich Fachbereiche gegen Prüfungen mit Argumenten wie „Wir haben gerade eine besonders hohe Belastung durch das Tagesgeschäft“ oder „Die Person, die Auskunft geben kann, ist gerade im Urlaub“. Die oben genannten Rahmenbedingungen sollten daher schriftlich dokumentiert und vom Top-Management unterschrieben werden. Zusätzlich sollten die Punkte vom Top-Management in deutlicher Form an die Fachbereiche kommuniziert werden.
12
1.3 Die IT-Revision im Unternehmen
1.3.3
Mitarbeiter
Die Revision lebt von dem Wissen und den Fähigkeiten ihrer Mitarbeiter. Daher sollte das Unternehmen in eigenem Interesse darauf achten, die Revision personell entsprechend auszustatten. Die Revision wird zwar von den Fachbereichen oft als lästiges Übel gesehen, für das Top-Management ist sie aber eine wichtige Informationsquelle. Revisionsleitung Natürlich muss der Revisionsleiter die Revision methodisch und inhaltlich organisieren können. Doch daneben muss er vor allem unternehmenspolitisch beschlagen sein, denn er wird oft in der Kritik der Fachbereiche stehen, besonders dann, wenn diese sich ungerecht behandelt und bewertet fühlen. Das erfordert ein gutes Standing5 im Unternehmen. Er muss das „Ohr am Unternehmen haben“, mitbekommen, was sich tut, wo akute Probleme entstehen, die in einer Sonderprüfung untersucht werden sollten. Er sollte einen guten Draht zum Top-Management haben und die Revision als Unterstützung des Top-Managements begreifen. Er muss loyal zum Unternehmen sein, aber auch das Rückgrat besitzen, um bei besonders schwerwiegenden, strafrechtlich relevanten Mängeln konsequent zu handeln. Revisoren Mit den Revisoren steht und fällt die Güte der IT-Revision. Daher ist es wichtig, schon bei der Personalauswahl gezielt Revisoren zu gewinnen, die über die benötigten bzw. wünschenswerten Qualifikationen verfügen: Revisionswissen Unter Revisionswissen wird hier das Wissen um die Vorbereitung und Durchführung von Revisionsprüfungen verstanden. Der Revisor muss den Aufbau und Ablauf von Revisionsprüfungen kennen und die Prüfungsmethoden beherrschen. Er muss in der Lage sein, die Prüfungsgrundlagen zu bestimmen, die Prüfungsfragen auszuwählen, den bestehenden Zustand des Prüfobjekts zu ermitteln und anschließend zu bewerten. Organisationswissen Ein allgemeines Wissen um die IT-Organisation ist bei annähernd jeder IT-Revisionsprüfung notwendig. Der Revisor muss wissen, welche Bereiche das IT-Management umfasst, welche IT-Prozesse es gibt und wie die IT technisch gestaltet werden kann. Das Wissen um die konkrete Ausprägung im eigenen Unternehmen erleichtert dabei die Arbeit des Revisors. Anforderungswissen Die IT-Revision prüft immer gegen bestehende Soll-Vorgaben, die in Form von Anforderungen in den Prüfungsgrundlagen (siehe Kapitel 4) vorgegeben sind. Der Revisor muss die relevanten Prüfungsgrundlagen zumindest in ihrer Existenz kennen. Wichtige 5
Eine Mischung aus Rückgrat, Ruf, Respekt und Durchsetzungsfähigkeit.
13
1 Grundlagen der IT-Revision Prüfungsgrundlagen sollte er inhaltlich erschlossen haben und anwenden können. Er muss die Absicht erkennen, die hinter den Anforderungen steht und somit wissen, worauf es bei den Prüfungen ankommt. Psychologische Robustheit Zu den wichtigen sogenannten „Soft Skills“ gehört eine gewisse psychologische Robustheit, oder einfacher gesagt: ein dickes Fell. Es kommt öfter vor, dass es widerspenstige Fachbereiche gibt, die sich durch Revisionsprüfungen in die Mangel genommen fühlen und nicht mitarbeiten wollen. Der Revisor muss auch mit solch schwierigen Situationen umgehen können und darf sich nicht persönlich angegriffen fühlen. Erfahrung Besonders für die Erkennung und Feststellung von Mängeln innerhalb der Bewertung des bestehenden Zustandes ist es notwendig, einen gewissen Spürsinn zu entwickeln und zu erahnen, wo „der Hase im Pfeffer liegt“. Dabei hilft der Faktor Erfahrung. Wer bereits viele Prüfungen durchgeführt hat, der bemerkt schnell, wenn der Fachbereich etwas zu verbergen hat. Auch hier hilft die Erfahrung im eigenen Unternehmen, denn dann kennt man die Abteilungen und Personen, die kritisch sein können. Revisoren mit viel Erfahrung kennen zudem die Tricks der Fachbereiche, um sich in Revisionsprüfungen gut zu verkaufen. Engagement und Charakter Zwar sind Revisionsprüfungen nach einem festen Schema organisiert, dennoch hängt die Qualität der Ergebnisse davon ab, wie engagiert der Revisor in der Prüfung agiert. Wichtig ist vor allem eine gewisse Hartnäckigkeit, d.h. der Revisor darf sich nicht gleich mit dem zufriedengeben, was ihm der Fachbereich anbietet. Besonders in Interviews erlebt man es oft, dass die Interviewten von den Fragen ablenken und andere, unwichtige Details beschreiben oder durch lange „Referate“ die Interviewzeit verkürzen wollen. Engagement bedeutet daher auch, die Führung in der Prüfung zu behalten. Ein weiterer Punkt ist in diesem Zusammenhang die Fähigkeit des Revisors, eigenständig zu arbeiten und seine Tätigkeit zu organisieren. Unabhängigkeit Revisoren dürfen nicht in betriebliche Abläufe eingebunden sein, die sie als Revisor zu prüfen haben. Im Hinblick auf eine Prüfung darf kein Interessenkonflikt entstehen, z.B. weil der Revisor privat oder nebenberuflich6 eng mit einem Unternehmen verbunden ist, das in ein Prüfobjekt des Revisors involviert ist, weil er (wenn er aus dem Unternehmen kommt) noch Verpflichtungen gegenüber seiner alten Abteilung hat oder weil er aufgrund einer Liebesbeziehung befangen ist. Revisoren dürfen nicht voreingenommen sein. Sie dürfen sich von persönlichen Sympathien/Antipathien, Zu- oder Abneigungen nicht leiten lassen und müssen möglichst objektiv bleiben. Sie dürfen sich nicht „um den Finger wickeln lassen“, müssen Charme-Attacken widerstehen und dürfen sich nicht einschüchtern lassen.
6
14
Die Prüfung von nebenberuflichen Tätigkeiten ist bei Revisoren besonders wichtig.
1.3 Die IT-Revision im Unternehmen Integrität Revisoren dürfen nicht bestechlich sein. Bei einigen Unternehmen werden daher auch die Revisoren überprüft. Ist das polizeiliche Führungszeugnis in Ordnung? Steckt der Revisor in finanziellen Schwierigkeiten? Ist er erpressbar? Wurden bei einer Sicherheitsüberprüfung (Hintergrund-Check) Auffälligkeiten festgestellt? Der Revisor muss loyal zum Unternehmen sein. Eine Selbstverständlichkeit sollte die Verschwiegenheit der Revisoren sein. Das gilt gegenüber anderen Unternehmen, der Presse, Kollegen und selbst gegenüber der eigenen Familie.
1.3.4
Qualitätssicherung und Leistungsmessung
Die im vorhergehenden Abschnitt genannten Eigenschaften sind Voraussetzungen (Kompetenzen), die erfüllt sein sollten, damit die Revisionsleistung erbracht werden kann. Diese Voraussetzungen müssen zunächst definiert und eingefordert werden. Wie kann aber auch die Güte der Revisionsleistung festgestellt werden? Wie kann die Qualität beurteilt, erhalten und verbessert werden? Anwendung von Qualitätskennzahlen Bei diesem Verfahren werden mehrere Kennzahlen definiert, mit deren Hilfe die Qualität eingeschätzt werden kann. Solche Kennzahlen können sein: Die durchschnittliche Dauer einer Revisionsprüfung. Die zeitliche Belastung für den Fachbereich (z.B. durch Interviews). Das zur Verfügung gestellte Zeit- und Kostenbudget für die Weiterbildung der Revisoren (und das Verhältnis zu dem, was davon in Anspruch genommen wurde). Diese Kennzahlen werden fortlaufend (bei jeder Prüfung) erhoben und über die Zeit verfolgt, sodass sich eine zeitliche Entwicklung erkennen lässt. Wichtig ist, dass die Kennzahlen in einer objektiven7 Größe angegeben werden können und unabhängig vom Inhalt der Prüfungen sind. Vergleich mit externen Prüfungen Eine weitere Möglichkeit besteht darin, einen Vergleich zu externen Prüfungen zu ziehen. Dies ist natürlich nur dann möglich, wenn es um das gleiche Prüfobjekt und einen vergleichbaren Prüfungsumfang geht. War der Zeitaufwand größer? Wurden weniger oder mehr Mängel gefunden? Wurden die gleichen Soll-Vorgaben zugrunde gelegt? Diese oder ähnliche Fragen würde man sich bei diesem Verfahren stellen. Selbstbeurteilung Das Verfahren mit Qualitätskennzahlen hat den wesentlichen Nachteil, dass Qualitätsfaktoren unberücksichtigt bleiben, die nicht in einer objektiven Kennzahl erfasst werden kön7
Objektiv im Sinne einer Größe, die sich über mehrere Prüfungen hinweg vergleichen lässt
15
1 Grundlagen der IT-Revision nen. In diesem Fall hilft die Selbstbeurteilung weiter. Jeder Revisor hält bei jeder Prüfung fest, welche Schwierigkeiten es bei der Durchführung der Revisionsarbeit gab. In regelmäßigen Abständen setzt sich dann das Revisionsteam zusammen, diskutiert diese Schwierigkeiten und sucht nach Verbesserungen. Bisweilen reicht schon der Austausch von Tipps, um die Arbeit zu verbessern. In anderen Fällen sind strukturelle Änderungen (z.B. im Revisionsprozess, der Personalausstattung usw.) oder Unternehmensentscheidungen (z.B. im Streit mit der Linie, für Befugnisse usw.) nötig. Beurteilung durch die geprüften Bereiche Das Problem der Selbstbeurteilung ist, dass so mancher verbesserungswürdige Punkt den Revisoren selbst nicht auffällt („Blinder Fleck“). Daher sollten auch die geprüften Bereiche die Revisionsarbeit beurteilen. Am Ende einer jeden Revisionsprüfung sollte deshalb eine Rückmeldung des geprüften Bereichs erfolgen. Die Gefahr einer solchen Beurteilung liegt darin, dass bei einem schlechten Prüfungsergebnis (viele Mängel) der Fachbereich nun „Rache“ nehmen könnte und die Prüfung schlecht bewertet. Daher sollte darauf geachtet werden, dass der Fachbereich in seiner Wertung keine allgemeinen Meinungsäußerungen abgibt, sondern konkret angibt, wo es unter Berücksichtigung der Vorgaben für die Revision Anlass zur Kritik gibt. Beurteilung durch das Top-Management Auch das Top-Management als Auftraggeber der Prüfungen und Empfänger der Revisionsberichte8 sollte die Dienstleistungsqualität (Performance) der Revision beurteilen. Doch hier wird es schwierig, denn ein Auftraggeber hat immer bestimmte Erwartungen an das Ergebnis. Das können konkrete oder diffuse, explizite und implizite, ausgesprochene und nicht ausgesprochene Erwartungen sein. In der Praxis ergibt sich vom Prüfungsauftrag bis zur Auswertung des Prüfungsergebnisses ein Kreislauf, wie in Abbildung 1.1 zu sehen ist. Der Top-Manager wird immer bewerten, ob das, was er vom Prüfungsergebnis wahrnimmt, mit dem übereinstimmt, was er im Prüfungsauftrag von der Revision wollte. Letzteres wird in Form von Anforderungen an die Revisionsdienstleistung definiert und als Soll-Zustand formuliert. Beispiel: „Die Prüfungsberichte sollen übersichtlich gestaltet sein“. Die Bewertung kann nun erfolgen, indem der Manager die Anforderung auf einer Skala von „viel besser als erwartet“ bis „viel schlechter als erwartet“ einschätzt. Das Problem hierbei ist, dass der Grund für die Bewertung nicht klar wird. Lag es bei einer guten Bewertung daran, dass der Manager vorher der Revision nichts zugetraut hat? Wo lag der Grund bei einer schlechten Bewertung? War die IT-Revision nicht in der Lage, das Ergebnis zu liefern? Hat der Manager das Ergebnis nur nicht wahrgenommen oder hatte er zu hohe, unrealistische Erwartungen?
8
16
Als „Kunden“ der Revision kommen auch der Aufsichtsrat, das Audit Committee, Aufsichtsbehörden und externe Prüfer in Betracht.
1.3 Die IT-Revision im Unternehmen Erwartungen an die Leistung der IT-Revision „Das, was der Auftraggeber von der IT-Revision will“ Match? Auswertung durch den Auftraggeber „Das, was der Auftraggeber vom Ergebnis wahrnimmt“
Wahrnehmung der Erwartungen durch die IT-Revision „Das, was die IT-Revision glaubt, dass der Auftraggeber will“
Bericht an den Auftraggeber „Das, was dem Auftraggeber kommuniziert wird“
Leistungsangebot der IT-Revision „Das, was die IT-Revision aufgrund der Wahrnehmung anbietet“
Ergebnis der Revisionsprüfungen „Das, was die Prüfungen ergeben haben“
Abbildung 1.1 Erbringung der Revisionsdienstleistung und Erwartungserfüllung
Ein etwas ausführlicheres Verfahren beurteilt daher zunächst die Anforderungen und gibt erst dann die Ist-Einschätzung. Dazu werden drei Schritte durchgeführt: 1. Anforderung beurteilen (Stimmt der jeweilige Top-Manager der Anforderung zu? Ist sie für ihn relevant und wichtig?). Für diese Einschätzung gibt es entsprechende Skalierungsverfahren mit mehreren Stufen9. Beispiel mit vier Stufen: Stimme in vollem Umfang zu / Stimme in hohem Maße zu / Stimme in geringem Maße zu / Stimme überhaupt nicht zu. 2. Ist-Einschätzung. Anforderung als erfüllt formulieren („Die Prüfungsberichte sind übersichtlich gestaltet“) und mit dem gleichen Skalierungsverfahren bewerten. 3. Ist-Wert vom Soll-Wert abziehen. Positives Ergebnis = Erwartungen werden übertroffen, 0 = Erwartungen werden erfüllt, negatives Ergebnis = Erwartungen werden nicht erfüllt. Praxistipp
Beachten Sie, dass die Beurteilung der Anforderungen subjektiv erfolgt. Positive Werte können daher auch dadurch erreicht werden, dass einfach die Anforderungen „herunterbewertet“ werden. Vergleichen Sie die Anforderungsbewertungen verschiedener Personen. Weichen sie stark ab? Aus welchem Grund?
Zusätzlich zu solchen formalisierten Verfahren ist es in der Praxis am besten, in persönlichen Gesprächen die Erwartungen und Leistungen gegenseitig abzugleichen. Kennt die IT-Revision die Erwartungen des Auftraggebers und nimmt sie diese richtig wahr? Sind die Erwartungen des Auftraggebers realistisch und angemessen oder verlangt er etwas, was die IT-Revision nicht leisten kann oder darf? Dazu listet der Auftraggeber die Erwartungen auf und gibt an, wie wichtig jede Erwartung aus seiner Sicht ist und warum das so ist. Auch die IT-Revision gibt an, wie wichtig die 9
Gebräuchlich sind Verfahren mit 2 bis 7 Stufen.
17
1 Grundlagen der IT-Revision Erwartungen aus ihrer Sicht sind. Abweichungen werden diskutiert, und es wird versucht, sich gegenseitig besser zu verstehen. Um sicher zu sein, dass die IT-Revision angesichts der Erwartungen die richtigen Leistungen ausführt, muss der Auftraggeber näher spezifizieren, woran er merken würde, dass die Leistung den Erwartungen entspricht. Das bedeutet, dass der Auftraggeber die Leistungen hinsichtlich Geschwindigkeit, Detailliertheit, Treffen der Zielsetzung, richtige Vorgehensweise, Methode oder Kosten spezifiziert. Im Gegenzug gibt die IT-Revision die Leistungen an, die sie erbringen kann. Abweichungen werden wieder diskutiert und daraus Vorgaben entwickelt, die in der Praxis kontrolliert werden. Wichtig ist auch die Frage, ob die erbrachte Leistung beim Auftraggeber ankommt. Die Revisoren sollten kommunikationstechnisch geschult sein, um die Ergebnisse richtig präsentieren zu können und gleichzeitig zu erfahren, was der Auftraggeber will und meint. Wird die erbrachte Leistung an den Auftraggeber kommuniziert? Nimmt er sie wahr? Kann er sie verstehen und gebrauchen? Bekommt er von verschiedenen Revisoren unterschiedliche Informationen? Wird betont, worauf es ankommt?
1.3.5
Sicherheit der Revisionsabteilung
Es liegt auf der Hand, dass die Revision eine sensible Abteilung darstellt, da sie nicht nur im Zuge ihrer Prüfungen Dinge erfährt, die vertraulich zu behandeln sind, sondern auch selbst durch die Feststellungen von Mängeln sensible Informationen produziert und austauscht. Die Abteilung ist daher entsprechend zu sichern. Das beginnt bei den Räumlichkeiten der IT-Revision. Im Idealfall verfügt die Revision über eigene Räume, die von den anderen Büros räumlich getrennt sind (je nach Größe der Revision ein eigenes Büro, ein eigener Flur oder eine eigene Büroetage). Die Räume sollten weder für den Publikumsverkehr noch für die außerhalb der Revision tätigen Mitarbeiter des Unternehmens frei zugänglich sein. Gibt es keine Einzelbüros, dann muss jeder Revisor für die Sicherheit seines Arbeitsplatzes sorgen. In der Praxis bedeutet das, die Schränke verschlossen zu halten, den Schreibtisch beim Verlassen des Arbeitsplatzes zu verschließen, sensible Unterlagen nicht offen auf dem Schreibtisch liegen zu lassen und den Computer beim Verlassen des Arbeitsplatzes zu sperren. Ein Großraumbüro ist aus den geschilderten Gründen für die Revisionsabteilung eher nicht geeignet. Ist es trotzdem unumgänglich, dann sollte der Revisionsbereich möglichst in einer Ecke der Etage liegen und mit höheren Schränken und Sichtblenden optisch und akustisch (Telefongespräche) abgetrennt werden. Auch in der Kommunikation ist einiges zu beachten. Sensible Informationen sollten nicht unversiegelt mit der normalen Hauspost versendet werden, bei elektronischer Kommunikation (z.B. E-Mail) sollten sensible Informationen vor der Übertragung verschlüsselt werden.
18
1.4 Prüfungsaspekte Alle Dokumente, bei denen die Bewahrung der Ursprünglichkeit wichtig ist, müssen vor nachträglicher Veränderung geschützt werden (z.B. nicht änderbares Format oder Schreibschutz) bzw. es muss sichergestellt werden, dass nachträgliche Veränderungen erkennbar sind (z.B. durch eine digitale Signatur). Nicht mehr benötigte Unterlagen, die sensible Informationen enthalten, sollten sicher vernichtet oder über einen sicheren Kanal (eigene Sammelstellen für sensible Dokumente) entsorgt werden.
1.4
Prüfungsaspekte Die Prüfungsaspekte geben an, worauf ein Prüfobjekt geprüft werden soll. Sie werden im Zuge der Prüfungsvorbereitung vor oder während der Erstellung des Prüfungsauftrags festgelegt. Aus den Prüfungsaspekten ergeben sich die Zielsetzungen für die Prüfung und letztlich auch die Prüfungsfragen, die in der Prüfung zu stellen sind. Es gibt eine Vielzahl von denkbaren Prüfungsaspekten. Zudem können Prüfungsaspekte in andere Prüfungsaspekte integriert werden. So kann bei Buchführungssystemen die Nachvollziehbarkeit in die Ordnungsmäßigkeit integriert werden, da die Soll-Vorgabe der Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS, siehe Kapitel 4) die Nachvollziehbarkeit fordert. Die im Folgenden beschriebenen Aspekte sind diejenigen, die man häufig bei Revisionsprüfungen findet.
1.4.1
Rechtmäßigkeit
Die fundamentalste Forderung an ein Prüfobjekt ist die Forderung, dass die geltenden Gesetze und rechtlichen Vorschriften und Bestimmungen eingehalten werden. Das Prüfobjekt wird daher fast immer auf die Rechtmäßigkeit hin geprüft. Bezogen auf die Informationstechnik des Unternehmens bedeutet die Rechtmäßigkeit, dass ... die physische Beschaffenheit der IT den geltenden Normen und Vorschriften entspricht. Das betrifft die bauliche Beschaffenheit von IT-relevanten Bauwerken, Gebäuden und Räumen (Vorschriften der Bauordnung, Brandschutz, Klimatisierung etc.). ... die technische Beschaffenheit der IT den geltenden Normen und Vorschriften entspricht. Das betrifft die technische Beschaffenheit von ITK-Netzwerken sowie von ITHardware- und Software-Komponenten (Funkentstörung, Schutzerdung, EMV-Verhalten etc.). ... Abläufe in der IT den gültigen Gesetzen und Bestimmungen entsprechen. Das betrifft die Planung/Entwicklung, die Implementierung, den Betrieb, die Änderung/Migration und die Entfernung/Entsorgung (Roll-Off) von IT-Komponenten und deren Inhalte/Daten (Datenschutz, Archivierung etc.). ... das IT-Management gesetzlichen Vorgaben und rechtlichen Bestimmungen entspricht (Corporate Governance, Verfahrensmanagement, Risikomanagement etc.)
19
1 Grundlagen der IT-Revision Es ist dabei zu prüfen, ob der bestehende Zustand zulässig und gesetzeskonform ist. Falls nicht, ist zu prüfen, gegen welche Bestimmungen verstoßen wird und als wie gravierend dieser Verstoß für das Unternehmen anzusehen ist. Ein Gesetzesverstoß ist in der Regel ein schwerwiegender Mangel.
1.4.2
Ordnungsmäßigkeit
Die Prüfung auf Ordnungsmäßigkeit geht in die gleiche Richtung wie die Prüfung auf Rechtmäßigkeit, ist jedoch weiter gefasst. Nun wird nicht mehr nur auf Konformität mit Gesetzen geprüft, sondern generell auf Konformität mit Soll-Vorgaben, die von externen Instanzen (Gesetzgeber, Aufsichtsbehörde, Vertragspartner10, Kunden) oder vom Unternehmen selbst an die IT im Unternehmen gestellt werden (z.B. aufsichtsrechtliche Vorschriften, Policies, interne Richtlinien und Anweisungen, Betriebsvereinbarungen, Sicherheitsstandards etc.). Die Prüfung auf Ordnungsmäßigkeit schließt die Prüfung auf Rechtmäßigkeit mit ein, daher taucht meist der Prüfungsaspekt der Rechtmäßigkeit in Prüfungen nicht mehr explizit auf. Es wird zwischen der formellen und der materiellen (inhaltlichen) Ordnungsmäßigkeit unterschieden: Die formelle Ordnungsmäßigkeit ist gegeben, wenn sichergestellt ist, dass die relevanten Soll-Vorgaben für die Form (das „Wie“) unabhängig vom Einzelfall eingehalten werden. Beispiel: Im Unternehmen existiert eine Einkaufsrichtlinie für die IT, die für Beschaffungen über 10.000 € eine Ausschreibung vorschreibt. Die Vorgabe konzentriert sich auf den Beschaffungsprozess, unabhängig davon, was beschafft wird. Bei der Beschaffung eines großen Servers wird damit nicht verhindert, dass ein falscher Server beschafft wird. Die materielle Ordnungsmäßigkeit ist gegeben, wenn sichergestellt ist, dass die relevanten Soll-Vorgaben für den Inhalt (das „Was“) im Einzelfall eingehalten werden. Beispiel: In der bereits genannten Einkaufsrichtlinie wird vorgeschrieben, dass IT-Einrichtungen gemäß ihrer funktionalen Spezifikation beschafft werden müssen. Die Vorgabe konzentriert sich auf den Inhalt der Beschaffung – unabhängig davon, wie beschafft wird. Bei der Beschaffung eines großen Servers wird damit nicht verhindert, dass ein zu teurer Server beschafft wird. Damit wird klar, dass in der Praxis nur eine Kombination aus formeller und materieller Ordnungsmäßigkeit sinnvolle Ergebnisse liefert. Leider wird dies bei der Erstellung der Soll-Vorgaben nicht immer berücksichtigt. Zumindest die internen Soll-Vorgaben können jedoch wiederum Prüfobjekte darstellen, die von der IT-Revision geprüft werden. Damit kann die IT-Revision solche Schwächen aufdecken und kommunizieren.
10
20
Verträge sind dabei auch Versicherungspolicen, Wartungsverträge, Service Level Agreements (SLAs) oder Leasingvereinbarungen.
1.4 Prüfungsaspekte
1.4.3
Sicherheit
Ein wichtiger Prüfungsaspekt ist die Sicherheit oder etwas konkreter: die Sicherheit der Informationstechnik im Unternehmen. Der Grund dafür liegt in der Verletzbarkeit der Informationstechnik und den weitreichenden Folgen, die sich daraus für das Unternehmen ergeben können. In modernen Unternehmen sind die Geschäftsprozesse in der Wertschöpfungskette größtenteils IT-gestützt und damit von der IT abhängig. Durch einen Ausfall oder Missbrauch entsteht für das Unternehmen mitunter ein erhebliches Risiko für Ertrag und Bestand. Aufgabe der IT-Revision ist es deshalb, dazu beizutragen, dass die mit der IT verbundenen Risiken minimiert oder ganz verhindert werden11. Es gibt viele Modelle, wie Risiken eingeteilt werden können. So unterscheidet man beispielsweise zwischen: Grundrisiken Das sind Risiken, die naturgegeben vorhanden sind oder bereits dann entstehen, wenn das Unternehmen die Geschäftstätigkeit aufnimmt. Sie sind untrennbar mit dem Unternehmen verbunden, die Ursache lässt sich nicht beseitigen. Ein Beispiel dazu sind Elementarrisiken wie Blitzschlag, Erdbeben, Brand oder Überschwemmung. Ungewollt entstehende Risiken Darunter werden Risiken verstanden, deren Ursache in einem Versehen, einer Fahrlässigkeit oder einem Irrtum liegen. Hierzu gehört das oft gebrauchte „menschliche Versagen“, von Mensch oder Maschine veranlasste Fehler oder auch Verschleiß. Gewollt entstehende Risiken Liegt dem Risiko ein Vorsatz zugrunde, dann hat man es mit einem gewollt entstehenden Risiko zu tun. Beispiele sind Manipulation, Ausspähung, Sabotage oder Diebstahl. Man kann Risiken auch danach einteilen, an welcher Stelle das Risiko entsteht. In diesem Fall könnte man beispielsweise folgende Einteilung wählen: Erkennungsrisiken Darunter wird das Risiko verstanden, dass Brände, Fehler, Manipulationen etc. nicht oder nicht rechtzeitig erkannt bzw. bemerkt werden. Die IT-Revision würde in diesem Fall fragen, welche Ereignisse welche Meldungen auslösen (z.B. löst ein Brand einen Brandmelder aus). Kontrollrisiken Das sind Risiken, die dadurch entstehen, dass Kontrollen nicht vorhanden sind oder nicht greifen. Kontrollen können sehr unterschiedlicher Art sein: Es gibt Applikationskontrollen in Software-Systemen (z.B. Eingabeprüfungen), Nutzungskontrollen (mit Plausibilitätsprüfungen) oder IT-Verfahrenskontrollen (z.B. im Change-Management). Entscheidungsrisiken Risiken, die durch falsche, unvollständige oder zu späte/zu frühe Entscheidungen entstehen , können als Entscheidungsrisiken zusammengefasst werden. 11
Alle Risiken zu verhindern, würde absolute Sicherheit bedeuten. Dies ist in der Praxis nicht möglich.
21
1 Grundlagen der IT-Revision Weitere, mögliche Einteilungen: Nach der Struktur des gesamten IT-Bereichs Risiken in der Gestaltung der IT (technische Risiken), im Ablauf der IT (Prozessrisiken) und im Management der IT (Steuerungs- und Führungsrisiken). Nach den Auswirkungen der Risiken Risiken für Leib und Leben, finanzielle Risiken, Imagerisiken etc. IT-Sicherheit äußert sich in drei grundlegenden Sicherheitskriterien: Verfügbarkeit: Schutz vor Verlust, Ausfall, Unterbrechung, Fehler und Störungen. Vertraulichkeit: Schutz vor Missbrauch, Ausspähung, unbefugter Verbreitung und unberechtigtem Zugriff. Integrität: Schutz vor Manipulation, Verfälschung und Betrug. Es gibt nationale und internationale Sicherheitsstandards wie die IT-Grundschutzkataloge des BSI12 oder die ISO13-Standardfamilie 2700x, die beschreiben, wie diese Sicherheitskriterien in der IT konkretisiert und umgesetzt sowie gemanagt werden können. Daneben erstellen viele Unternehmen (insbesondere große Unternehmen) eigene Sicherheitsrichtlinien für die Informationstechnik („IT Security Policies“). In den Revisionsprüfungen der IT-Revision ist zunächst die Ordnungsmäßigkeit des Prüfobjekts hinsichtlich der Soll-Vorgaben für die IT-Sicherheit zu prüfen. Im Zentrum stehen dabei meist die internen Sicherheitsrichtlinien des Unternehmens, da die externen Sicherheitsstandards nicht unbedingt zwingend anzuwenden sind14. In einem zweiten Schritt gilt es zu prüfen, an welcher Stelle welche Risiken für das Unternehmen bestehen oder entstehen können.
1.4.4
Zweckmäßigkeit/Funktionsfähigkeit
Es liegt im Interesse des Unternehmens, nicht nur sicherzustellen, dass keine Strafen oder Risiken drohen, sondern auch zu untersuchen, ob das jeweilige Prüfobjekt seiner Bestimmung gerecht wird. Ein Maß dafür ist die Zweckmäßigkeit, die durch folgende Eigenschaften gekennzeichnet ist: Funktionserfüllung Die IT liefert termingerecht die geplanten/erwarteten Ergebnisse. Die Ergebnisse sind inhaltlich richtig und vollständig. Effektivität Die IT ist dazu geeignet, den ihr zugedachten Zweck zu erfüllen.
12
Bundesamt für Sicherheit in der Informationstechnik International Organization for Standardization 14 Es sei denn, das Unternehmen oder eine übergeordnete Instanz (Muttergesellschaft, Holding o.Ä.) erklärt sie für das Unternehmen als verbindlich. 13
22
1.4 Prüfungsaspekte Ziel- und Strategiekonformität Die IT stimmt mit der IT- und Geschäftsstrategie überein und unterstützt die Erfüllung der an sie gestellten Ziele. In den Revisionsprüfungen der IT-Revision muss zunächst geklärt werden, wie die geplante Funktion beschaffen ist, welchem Zweck sie dienen soll und welche Ziele festgelegt wurden. Anschließend wird der bestehende Zustand erhoben, d h. wie die Funktion aktuell beschaffen ist. Schließlich werden die vorhandenen Ziel- und Funktionsabweichungen festgestellt und Verbesserungsvorschläge vorgelegt. Die Funktionsprüfung wird auch als „Operational Auditing15“ bezeichnet
1.4.5
Wirtschaftlichkeit
Es geht in Revisionsprüfungen auch um das Aufspüren von Nachteilen für das Unternehmen. Auch wenn das Prüfobjekt ordnungsgemäß, sicher und zweckmäßig arbeitet, heißt das nicht, dass sich das Management entspannt zurücklehnen kann. Die Einhaltung dieser Prüfungsaspekte kann mit einem unverhältnismäßig hohen Aufwand erkauft worden sein oder das Anforderungsniveau ist so niedrig, dass Ressourcen verschwendet werden. Aus diesen Gründen ist auch die Wirtschaftlichkeit ein wichtiger Prüfungsaspekt, der jedoch in vielen Fällen aus Zeitgründen nicht in jeder Prüfung zum Zuge kommt. Unter dem betriebswirtschaftlichen Begriff der Wirtschaftlichkeit wird das Verhältnis zwischen dem Mitteleinsatz und dem damit erzielten Ergebnis (Erfolg) verstanden. Je höher der Mitteleinsatz für ein bestimmtes Ergebnis, desto geringer bzw. schlechter wird die Wirtschaftlichkeit. In den Revisionsprüfungen der IT-Revision werden zunächst die Kennzahlen für das Ergebnis erhoben, z.B. Mengengerüste an Daten, die vom Prüfobjekt verarbeitet werden. In einem zweiten Schritt wird ermittelt, wie das Prüfobjekt dimensioniert ist und welcher initiale und laufende Aufwand damit verbunden war und ist. Damit ergibt sich, ob das Prüfobjekt hinsichtlich seiner Funktion und der erzielten Ergebnisse angemessen ist und wirtschaftlich arbeitet. Beispiel: Ein IT-System der mittleren Datentechnik als reines E-Mail-System einzusetzen, um in der Bürokommunikation ein E-Mail-Aufkommen von täglich 1.000 E-Mails16 zu bewältigen, kann sicher als unwirtschaftlich gelten und würde von der internen Revision zu Recht bemängelt, sofern keine gewichtigen Gründe für diese Dimensionierung vorliegen.
15
Der Begriff stammt ursprünglich von der Untersuchung der Geschäftstätigkeit hinsichtlich Effektivität und Effizienz. 16 Hier wird von „normalen“ E-Mails durchschnittlicher Größe und Komplexität ausgegangen.
23
1 Grundlagen der IT-Revision
1.4.6
Kontrollierbarkeit und Nachvollziehbarkeit
Ein Prüfungsaspekt, der besonders für die IT-Revision selbst von Bedeutung ist, stellt die Kontrollierbarkeit und die damit verwandte Nachvollziehbarkeit dar. Für die Kontrollierbarkeit ist die Transparenz des Prüfobjekts entscheidend. Die Transparenz ist gegeben, wenn die Beschaffenheit des Prüfobjekts zeitnah (d h. ohne unverhältnismäßig großen Aufwand) vollständig, klar und eindeutig ermittelt werden kann. Dies sollte möglich sein, ohne auf spezielle Personen angewiesen zu sein. Um kontrollieren zu können, werden schließlich noch Richtwerte benötigt, deren Einhaltung bzw. Übereinstimmung geprüft werden kann. Um eine Nachvollziehbarkeit einer Handlung, einer Systemeigenschaft, eines Entscheidungsprozesses etc. zu erreichen, gibt es hauptsächlich zwei Methoden: Die Momentaufnahme (Snapshot) Der Zustand wird in regelmäßigen oder unregelmäßigen Abständen in seiner Gesamtheit festgehalten. Das hat den Nachteil, dass Zustände zwischen den Momentaufnahmen nicht eindeutig festgestellt werden können. Das Protokoll Jede Veränderung an dem Zustand wird protokolliert. So lässt sich aus dem Ausgangszustand zu Beginn der Protokollierung der Zustand zu einem bestimmten Zeitpunkt rekonstruieren. Der Nachteil liegt in der Kompliziertheit und dem hohen Aufwand, der für eine solche Rekonstruktion getrieben werden muss. Die Nachvollziehbarkeit ist wichtig, um Ereignisse und deren Entstehung nachweisen können. In den Revisionsprüfungen von IT-Verfahren und IT-Systemen wird daher auch geprüft, ob das Prüfobjekt über eine Protokollierung (Logging) verfügt.
24
2 2 Prüfungsorganisation und Vorgehen Das vorliegende Kapitel behandelt die beiden Fragen: „Wie kommt man zu den zu prüfenden Objekten und Themen?“ und „Wie führt man eine IT-Revisionsprüfung durch?“. Die erste Frage ergibt sich aus dem großen Umfang und der hohen Komplexität der IT-Landschaft moderner Unternehmen und führt zur Prüfungsplanung, während es für die zweite Frage ein standardisiertes Vorgehen für Revisionsprüfungen gibt, das 1:1 für IT-Revisionsprüfungen angewendet werden kann.
2.1
Prüfungsplanung Die Prüfungsplanung im Sinne einer Planung des Prüfungsprogramms kümmert sich um die Frage, welche Prüfungsobjekte im Unternehmen überhaupt geprüft werden sollen und wann dies geschehen soll. Es geht also darum, eine Strategie zu definieren, nach der die Prüfungen stattfinden sollen. Wovon aber wird die Entscheidung abhängig gemacht, welche Bereiche im Unternehmen zu welchem Zeitpunkt mit welcher Intensität zu prüfen sind? Hier gibt es mehrere Möglichkeiten: Die Entscheidung wird abhängig gemacht: von dem Risiko, das von den Prüfobjekten für die IT oder für Geschäftsprozesse des Unternehmens ausgeht. Besonders risikoreiche Prüfobjekte werden bevorzugt behandelt1. von dem, was bereits durchgeführte Prüfungen ergeben haben. Organisationseinheiten, in denen die Prüfungen immer wieder größere Mängel ergeben, werden bevorzugt behandelt. von dem, was das Top-Management vorgibt. Das Top-Management kann natürlich von sich aus bestimmen, welche Prüfobjekte besonders wichtig und daher bevorzugt zu behandeln sind. In der Praxis sind solche Alleingänge des Top-Managements nicht die
1
Bevorzugt bedeutet hier, dass die Prüfobjekte früher, öfter und/oder intensiver geprüft werden.
25
2 Prüfungsorganisation und Vorgehen Regel, meist legt das Top-Management zusammen mit der Revisionsleitung die Richtung fest. von dem, was die Revisoren aufgrund ihrer Erfahrung zugrunde legen. Damit ist nicht die Erfahrung bzgl. der Prüfungsergebnisse gemeint, sondern das Gespür für Prüfungsobjekte, bei denen es für das Unternehmen erfahrungsgemäß zu Problemen kommen kann und die daher bevorzugt behandelt werden sollten. von dem, was Drittquellen empfehlen. Dafür gibt es entsprechende Veröffentlichungen von revisionsnahen Organisationen wie dem Institut für interne Revision (IIR). davon, wie die IT-Revision von den Organisationseinheiten wahrgenommen wird. Haben sie noch nicht erkannt, dass die Prüfungen auch in ihrem Interesse sind, dann besteht die Gefahr, dass sie versuchen werden, möglichst große Prüfungsintervalle zu erreichen und intensive Prüfungen zu verhindern. Neben dem Prüfungsprogramm müssen auch die einzelnen Prüfungen geplant werden. Dazu wird für jede Prüfung ein Prüfungsplan erstellt, in dem festgehalten wird, welche Prüfungsgebiete und -aspekte geprüft werden sollen und welche Methodik angewendet werden soll. Auch für diese Planung wird der Begriff Prüfungsplanung verwendet. Schließlich wird auch die Revisionstätigkeit als solche strategisch geplant, z.B. in welche Richtung sich die IT-Revision methodisch entwickeln soll.
2.1.1
Strategische Planung (3-Jahres-Plan)
Die gesamte Revisionstätigkeit wird in einer Planung, die mehrere Jahre (meist drei Jahre) umfasst, ganzheitlich im Voraus durchdacht. Ganzheitlich bedeutet, dass nicht nur das Prüfungsprogramm, sondern auch die IT-Revision als solche immer wieder durchdacht wird. Schwerpunkte der strategischen Planung sind: Das Prüfungsprogramm Das ist die Programmplanung, so wie sie bereits angesprochen wurde, d.h. in welchen Bereichen in welchen Intervallen welche Prüfobjekte untersucht werden sollen. Dem Ziel einer möglichst flächendeckenden Revision2 stehen dabei u.U. Unternehmensinteressen entgegen, wenn beispielsweise eine Prüfung den Wert eines Bereichs reduzieren würde, der zum Verkauf steht. Auch weiche Faktoren wie persönliche Freundschaften zwischen Top-Managern und Führungskräften der Linie können in manchen Fällen von Bedeutung sein. Die Prüfungsmethodik Wo sollen nachbetrachtende (ex-post) und wo vorbetrachtende (ex-ante) Prüfungen durchgeführt werden? Wo kann bis zu welchem Grad automatisiert geprüft werden? Sollen eher standardbezogene Konformitätsprüfungen oder eher klassische Mängelprüfungen durchgeführt werden? Konzentriert man sich eher auf das Risiko (Schutz vor
2
26
Alle Bereiche bzw. Verfahren werden in regelmäßigen Abständen geprüft. Dieser Ansatz verliert mit der Priorisierung der Bereiche zunehmend an Bedeutung.
2.1 Prüfungsplanung Bestrafung und Schäden) oder eher auf die Optimierung im Unternehmensinteresse (Steigerung der Leistungsfähigkeit, Wirtschaftlichkeit)? Die Ressourcen Die Ressourcenplanung geht Hand in Hand mit der Programmplanung. Entweder es wird vom Programm ausgegangen und dann die dafür benötigten Ressourcen geplant oder es wird von den zur Verfügung stehenden Ressourcen ausgegangen und geplant, welches Programm damit erledigt werden kann. Im Zentrum steht die Frage, wie sich die Ressourcensituation in den nächsten drei Jahren entwickeln soll und entwickeln kann. Die kontinuierliche Verbesserung Auch die Entwicklung der IT-Revision selbst in den nächsten drei Jahren ist Bestandteil der strategischen Planung. Wie kann die Qualität und der Nutzen der Prüfungen noch gesteigert werden? Was kann die IT-Revision in den nächsten drei Jahren tun, um ihr Image zu verbessern? Wie sollen die Revisionsmitarbeiter weitergebildet werden? Welches Know-how wird erforderlich werden und wie soll es gewonnen werden?
2.1.2
Jahresplanung
Die Jahresplanung konkretisiert und operationalisiert die strategische 3-Jahres-Planung, in der operationale Elemente wie beispielsweise eine konkrete Terminplanung oder eine detaillierte Ressourcenzuordnung noch nicht vorhanden sind. Der wichtigste Teil ist die Aufstellung, welche Bereiche und Prüfobjekte aus dem 3-Jahres-Plan in dem Planungsjahr geprüft werden sollen. Abbildung 2.1 zeigt dazu ein mögliches Vorgehen. Alle möglichen Prüfobjekte (Audit Universe) fließen in die strategische Prüfungsplanung. Business Impact Audit Universe
Strategische Prüfungsplanung
Business Risk Management Priority
Priorisierung
Jahresprüfprogramm
Abbildung 2.1 Mögliches Vorgehen für die Jahresplanung
Die Menge der sich daraus ergebenden Prüfobjekte wird nun in der Jahresplanung auf der Grundlage der geschäftlichen Bedeutung (Business Impact), des durch das Prüfobjekt erzeugten Risikos (Business Risk) und der Bedeutung, die das Management dem Prüfobjekt gibt (Management Priority), priorisiert. Als Ergebnis erhält man das Prüfungsprogramm für das Planungsjahr und die Prüfungslandschaft (Audit Landscape3), d h. welche Bereiche bzw. Verfahren in diesem Jahr geprüft werden. 3
Der Begriff der Prüfungslandschaft oder -landkarte deutet auf das gleichrangige Prüfen (Round-RobinVerfahren) aller Bereiche in einem festen Zeitintervall hin und erscheint daher beim priorisierten Prüfen etwas ungeschickt.
27
2 Prüfungsorganisation und Vorgehen Die ausgewählten Prüfobjekte werden zeitlich geordnet und mit Prüfungsterminen versehen. Bei der Terminplanung sollte darauf geachtet werden, nur 60 % der verfügbaren Arbeitszeit für reguläre Prüfungen zu verplanen. Der Rest wird erfahrungsgemäß für Sonderprüfungen, Beratungen, Gutachten, Personalabwesenheit (Krankheit, Urlaub, Mutterschutz, Weiterbildung usw.), Organisation (z.B. Besprechungen) und Unvorhergesehenes benötigt. Für jede Prüfung wird eine Aufwandschätzung erstellt. Als Basis dienen die Erfahrungswerte von bereits durchgeführten Prüfungen. Daraus ergibt sich, dass die zeitlichen Aufwände der Prüfungen erfasst und dokumentiert werden müssen. Mit der Zeit lassen sich auf diese Weise normierte Arbeitsvolumina für die Prüfungsschritte erstellen. Ein weiterer Planungspunkt ist die Ressourcenplanung und -zuordnung. Das benötigte Know-how für die Prüfungen wird dem vorhandenen Know-how gegenübergestellt. Ist das Know-how vorhanden, muss sichergestellt werden, dass die Prüfer mit diesem Know-how nicht überplant werden. Ist das Know-how nicht vorhanden, kommt der Einsatz von externen Revisoren in Betracht. Der fertig erstellte Jahresplan wird vom Top-Management in Absprache mit den Organisationseinheiten und der Revision in Kraft gesetzt. Die Revision gibt am Jahresende einen Gesamtbericht über alle Prüfungen an das TopManagement. Aus diesem Bericht sollte hervorgehen, ob der Prüfplan eingehalten wurde, welche gravierenden Mängel es gab und welche wichtigen Maßnahmen sich aus den Prüfungen ergaben.
2.1.3
Planung und Vorbereitung einer einzelnen Prüfung
Nun geht es an die Planung einer konkreten Prüfung und an die Beantwortung einiger grundlegender Fragen: Ex-post oder Ex-ante? Ist die Prüfung nachbetrachtend oder vorbetrachtend?
28
Ex-ante
Ex-post
Prüfung vor oder während der Entwicklung einer IT-Lösung
Prüfung während der Betriebsphase der IT-Lösung
Prüfung von laufenden IT-Projekten
Prüfung von bereits abgeschlossenen IT-Projekten
Prüfung von IT-Investitionsvorhaben
Prüfung von getätigten IT-Investitionen
Prüfung der IKS-Struktur bei der Einrichtung des IKS
Prüfung der IKS-Wirksamkeit
2.1 Prüfungsplanung Black-box oder White-box? Wird das Prüfobjekt inhaltlich erschlossen oder als Ganzes betrachtet? Black-box
White-box
In welcher Umgebung existiert das Prüfobjekt?
Wie ist das Prüfobjekt intern beschaffen (aus welchen Teilen besteht es)?
Worin besteht die Funktion, die nach außen hin sichtbar ist?
Wie spielen die einzelnen Teile des Prüfobjekts zusammen?
Welchen Schaden kann es anrichten, wenn es nicht oder falsch funktioniert?
Welche Risiken birgt das Gefüge der einzelnen Teile?
Entspricht das Prüfobjekt als Ganzes den Revisionsanforderungen?
Entsprechen die einzelnen Teile den Revisionsanforderungen?
Mängelprüfung oder Konformitätsprüfung? Wird das Prüfobjekt auf Mängel hin untersucht oder werden die Abweichungen zu einem Zielzustand bestimmt? Mängelprüfung
Konformitätsprüfung
Es wird untersucht, welche Mängel im Prüfobjekt festzustellen sind und wie gravierend sie sind.
Es werden nur die Abweichungen festgestellt, unabhängig davon, welche Risiken für das Unternehmen entstehen.
Die Prüfung orientiert sich an den SollVorgaben für das Unternehmen.
Die Prüfung orientiert sich ausschließlich an der Definition des Zielzustands.
Ergebnis ist eine Mängelliste und empfohlene Maßnahmen zur Beseitigung.
Ergebnis ist der Erfüllungsgrad, den das Prüfobjekt erreicht.
Planmäßige Prüfung oder Sonderprüfung? Handelt es sich um eine vorgesehene oder unvorhergesehene Prüfung? Planmäßige Prüfung
Sonderprüfung
Angekündigt bei normalem Rege betrieb.
Unangekündigt bei akuten Vorfällen (Vorrang vor geplanten Prüfungen).
Prüfung in der Breite.
Punktueller Auftrag.
Termine, Interviewpartner und Prüfungsplanung darf bekannt sein.
Äußerste Verschwiegenheit bei der Vorbereitung und Durchführung.
Bei einer planmäßigen Prüfung ergibt sich das Prüfobjekt, der Prüfungsumfang4, das benötigte Prüf-Know-how und die benötigte Prüfzeit aus der Jahresplanung. In der Vorbereitung der konkreten Prüfung müssen zusätzlich noch einige Punkte geklärt werden: 4
Der Umfang ergibt sich aus Prüfungsthema und -ziel, d.h. der Frage, worauf das Prüfobjekt geprüft werden soll. Aus dem Umfang ergibt sich das Vorgehen (z.B. Anwendung eines Stichprobenverfahrens).
29
2 Prüfungsorganisation und Vorgehen Was ist explizit nicht Bestandteil der Prüfung (Abgrenzung)? Können Ergebnisse bereits durchgeführter Prüfungen bei diesem Prüfobjekt gesichtet werden? Wie ist das Prüfobjekt beschaffen? Was (welche Teile) sollen von wem wann mit welcher Methodik geprüft werden? Welche Soll-Vorgaben (Prüfungsgrundlagen) sind für die Prüfung relevant? Welche Prüfungsfragen sind zu stellen (es ist üblich, eine Checkliste mit diesen Fragen zu erstellen)? Vorbereitend zur Prüfung sollte auch eine Datenablage eingerichtet werden, in der alle zur Prüfung gehörenden Dokumente zusammengefasst werden, wie Prüfungsauftrag oder Prüfungsbericht, vom zu prüfenden Bereich zur Verfügung gestellte Dokumente, Schriftverkehr oder Gesprächsnotizen. In vielen Unternehmen gilt der Grundsatz, dass als Stand der Prüfung der Dokumentationsstand gilt.
2.2
Prüfungsauftrag Für jede Prüfung sollte es einen schriftlichen Auftrag geben. Der Auftrag sollte immer von der obersten Leitungsebene des Unternehmens kommen5 und vom Top-Management unterzeichnet werden. Dies ist zum einen eine Absicherung für die Revision, die damit im Nachhinein belegen kann, was genau beauftragt wurde (sofern der Prüfungsauftrag ausreichend präzise formuliert ist). Zum anderen ist damit für die zu prüfenden Bereiche klar ersichtlich, dass der Vorstand hinter der Prüfung steht. Für planmäßig durchgeführte Prüfungen leitet sich der Auftrag aus der Jahresplanung ab. Er sollte folgende Angaben enthalten: Welcher Bereich und welches Prüfobjekt soll geprüft werden? Wie lautet das Prüfungsthema (worum geht es in der Prüfung)? Was ist die Zielsetzung der Prüfung? Welche Prüfungsgebiete (Teilbereiche) sind Bestandteil der Prüfung? In welchem Zeitraum soll die Prüfung stattfinden? Wann wurde die Prüfung in Auftrag gegeben (Datum des Auftrags)? Wer wird die Prüfung auf Seiten der Revision leiten? Wie ist der Revisor zu erreichen? Wer sind die Empfänger (wer bekommt den Auftrag zugesandt)? Unterschrift des Top-Managements
5
30
Das heißt nicht, dass das Top-Management den Auftrag auch erstellen muss. Die Erstellung kann in der IT-Revision erfolgen, der Auftrag wird dem Top-Management dann zur Genehmigung und Unterschrift vorgelegt.
2.3 Vorbereitung der Prüfungsdurchführung Praxistipp
Der Prüfungsauftrag sollte nicht zu speziell formuliert werden, um den Revisor in seiner Arbeit nicht zu sehr einzugrenzen. Vielfach zeigt sich in der Prüfung, dass hier und da noch Dinge betrachtet werden müssen, die zu Beginn der Prüfung nicht so offensichtlich waren. Bei einem sehr stark eingegrenzten Auftrag können die zu prüfenden Bereiche darauf bestehen, dass auch nur die beauftragten Dinge geprüft werden.
Problematisch wird es, wenn das Top-Management Prüfungen nach dem Motto „Wasch mir den Pelz, aber mach mich nicht nass“ in Auftrag gibt. In diesem Fall soll eifrig geprüft werden, aber es sollen keine größeren Mängel zutage kommen, da das vielleicht dem Ansehen im Konzern oder der eigenen Karriere schaden könnte. Hier sollte der Revisionsleiter das Gespräch suchen. Auf keinen Fall darf es Alibi-Prüfungen mit Gefälligkeitsberichten geben!
2.3
Vorbereitung der Prüfungsdurchführung 2.3.1
Analyse des Prüfobjekts/Voruntersuchung
Ausgehend vom Prüfungsauftrag arbeiten sich die Revisoren in diesem Schritt in die Materie ein. Im Falle der Erstprüfung verschaffen sie sich einen generischen Überblick über das Prüfobjekt und konstruieren die Struktur und das Gefüge der zu prüfenden IT durch eine entsprechende Recherche. Sie eruieren die Vorgaben, die für ein solches Gefüge gelten, und überlegen, welche Unterlagen sie für die Prüfung des jeweiligen Bereichs benötigen. Wurde das Prüfobjekt bereits geprüft (vielleicht mit einer anderen Zielsetzung), so bilden die dort angefertigten Prüfungsberichte die Grundlage für die Einarbeitung.
2.3.2
Prüfungsankündigung
Bei planmäßigen Prüfungen ist es üblich, die Prüfung rechtzeitig anzukündigen. Was unter rechtzeitig zu verstehen ist, richtet sich nach der Unternehmenskultur, der Komplexität der Prüfung und danach, wie viel Vorlauf der zu prüfende Bereich benötigt, um Unterlagen zusammenzustellen und die Verfügbarkeit bestimmter Mitarbeiter für die Prüfung zu organisieren. In der Praxis liegt die Zeitspanne zwischen einigen Tagen und sechs Wochen. Wenn ein Überraschungseffekt gewünscht wird oder es einen Verdacht auf akute Verstöße gibt, erfolgt die Prüfung ohne Ankündigung. Gegen eine Prüfungsankündigung lässt sich einwenden, man würde den zu prüfenden Bereich warnen und ihm noch vor der Prüfung Gelegenheit geben, Unterlagen zu manipulieren bzw. verschwinden zu lassen oder einige Dinge noch schnell „gerade zu rücken“. Dazu zwei Überlegungen: 1. Die IT ist in ihrer technischen, organisatorischen und prozessualen Gesamtheit dermaßen komplex, dass es dem zu prüfenden Bereich schwer fallen dürfte, kurzfristig vor der Prüfung alles in Ordnung zu bringen, zumal, wie bereits erwähnt wurde, die Vor-
31
2 Prüfungsorganisation und Vorgehen gaben oft gar nicht bekannt sind. Zwar können Dokumente verschwinden, aber sie hinterlassen im Gesamtgefüge Spuren. Umfangreiches Tatsachenmaterial ist kaum beeinflussbar. 2. Ziel ist es, den zu prüfenden Bereich in eine Situation zu führen, in der die Vorgaben eingehalten werden. Das kann nach der Prüfung mithilfe der Maßnahmenempfehlungen erreicht werden oder auch in einer Hauruck-Aktion kurz vor der Prüfung. Wenn der Bereich demnach kurz vor der Prüfung „alles in Ordnung bringt“, wird damit zwar ein falscher positiver Eindruck erzeugt6, die vorherige, unbefriedigende Situation wird aber auch auf diese Weise verbessert. Mit der Prüfung sollte in diesem Fall darauf hingewirkt werden, den verbesserten Zustand über die Zeit zu stabilisieren. Die Prüfungsankündigung soll folgende Fragen beantworten: Was ist der Anlass für die Prüfung? Was soll geprüft werden (Prüfobjekt)? In welcher Hinsicht soll es geprüft werden (Prüfungsthema)? Wann ist der vorgesehene Beginn der Prüfung und wie lange wird sie dauern? Wer sind die Ansprechpartner für die Prüfung? Wer wird die Prüfung durchführen? Wann soll das Vorgespräch (Kick-off) stattfinden? Welche Unterlagen benötigen die Prüfer im Vorfeld der Prüfung bzw. zum Zeitpunkt des Vorgesprächs vom zu prüfenden Bereich? Die Prüfungsankündigung wird an die Leitung des zu prüfenden Bereichs (Abteilungsleiter o.Ä.) gerichtet. Es ist verständlich, dass eine Revisionsprüfung einer Organisationseinheit nie gelegen kommt, und daher häufig versucht wird, die Prüfung zu verschieben oder zu verhindern. Dazu wendet sich die Organisationseinheit mit ähnlichen wie den folgenden Argumenten an das Top-Management, um die IT-Revision auszuhebeln: „Unsere ganze Abteilung ist gerade jetzt in eine kritische Migration verwickelt, und die Mitarbeiter sind jetzt schon überlastet. Wir schaffen es nicht, nun auch noch eine Revisionsprüfung zu machen.“ „Sie müssen sich im Klaren sein, dass Sie mit einer solchen Prüfung in ein Wespennest stoßen. Denken Sie daran, was dabei herauskommen könnte ...“ „Wir planen doch schon, die Prozesse umzustellen und neue Applikationen einzuführen. Da macht eine Revisionsprüfung zu diesem Zeitpunkt doch keinen Sinn.“ Es kommt in diesen Fällen auf das Top-Management an, ob es sich von solchen Argumenten beeinflussen lässt. Der Revisionsleiter sollte deutlich machen, dass die Autorität der Revision auf dem Spiel steht, wenn man dem Verlangen der zu prüfenden Bereiche nachgibt.
6
32
Ein erfahrener Revisor wird in der Lage sein festzustellen, dass die Dinge in der Vergangenheit nicht in Ordnung waren.
2.4 Prüfungsdurchführung
2.3.3
Kick-off-Meeting
Vor dem Beginn der Prüfung findet in der Regel ein Treffen zwischen der Revision und dem zu prüfenden Bereich statt7. Die IT-Revision lädt dazu die Leitung des zu prüfenden Bereichs ein und bittet sie, ihrerseits maßgebliche Mitarbeiter einzuladen. Falls noch nicht klar sein sollte, was Revision und eine Revisionsprüfung ist, kann die Tätigkeit der Revision kurz zu Beginn des Meetings erklärt werden. Dann stellt sich der oder die Prüfer kurz vor. Der erste wichtige Teil des Meetings ist die Vorstellung des Prüfungsinhaltes. Hier wird das Prüfobjekt genannt und die Organisationseinheit darüber informiert, in welcher Hinsicht das Prüfobjekt geprüft werden soll und was der Anlass für die Prüfung ist. Der zweite wichtige Teil des Meetings ist die Vorstellung des Vorgehens. Es wird erläutert, welcher Ablauf für die Prüfung vorgesehen ist, in welchem Zeitraum welche Prüfungshandlungen vorgesehen sind, wie lange sie dauern und welche Personen dafür benötigt werden. Es sollte auch dargestellt werden, was nach Abschluss der Prüfungshandlungen passiert (Prüfungsbericht und dessen Durchsicht im geprüften Bereich, Feedback von ihm, sofern das vorgesehen ist). Für den Fall, dass der zu prüfende Bereich bereits einige der in der Prüfungsankündigung angeforderten Dokumentationen geliefert hat, kann im Kick-off-Meeting noch einmal auf die ausstehenden Dokumente hingewiesen werden. Dokumente in Papierform können auch direkt im Meeting übergeben werden. Das Meeting dient nicht nur dem Kennenlernen und der Information, es soll auch ein grundlegendes Vertrauen schaffen und Ängste vor der Prüfung bzw. deren Ergebnis abbauen. Der Revisor kann die Information als Präsentation oder als Gespräch gestalten. Fragen sollten jederzeit gestellt werden können. Den Vertretern des zu prüfenden Bereichs sollte auch Gelegenheit gegeben werden (sofern dies gewünscht wird), im Meeting ihre Sicht zum Prüfobjekt und dem Prüfungsthema darzulegen.
2.4
Prüfungsdurchführung 2.4.1
Dokumentensichtung
Der erste Schritt der Prüfungsdurchführung besteht darin, sich aufgrund der Dokumente, die zum Prüfungsthema im zu prüfenden Bereich vorliegen, ein erstes Bild zu machen. Bereits in der Prüfungsankündigung und im Vorgespräch wurde mitgeteilt, welche Unterlagen im Hinblick auf die Zielsetzung der Prüfung wichtig erscheinen. Diese Unterlagen wurden vom zu prüfenden Bereich angefordert und werden nun ausgewertet.
7
Für dieses Treffen findet man neben dem Begriff Kick-off-Meeting viele andere Bezeichnungen wie Vorgespräch, Eröffnungsgespräch oder Prüfungsvorstellung.
33
2 Prüfungsorganisation und Vorgehen Zunächst ist wichtig, ob die angeforderten Dokumente geliefert wurden. Wurden sie nicht geliefert, kann das verschiedene Gründe haben: 1. Die Dokumente existieren im zu prüfenden Bereich nicht. Das kann bereits auf Schwächen in der Dokumentation hinweisen. Entweder ist es im Bereich nicht vorgesehen, die Dokumente zu erstellen (Organisationsmangel), oder es ist vorgesehen und wird nicht getan (Ausführungsmangel). Bei Letzterem kommt noch hinzu, dass es den internen Kontrollkreisläufen nicht gelungen ist, den Mangel zu beheben – sei es, weil das Fehlen nicht aufgefallen ist bzw. die Existenz nicht kontrolliert wurde (Kontrollmangel) oder weil die Forderung der Erstellung nicht durchgesetzt wurde (Autoritätsmangel). 2. Der Bereich hat schlicht vergessen, die Dokumente zu liefern. Falls die Lieferung vergessen wurde, spricht das nicht gerade für die Zuverlässigkeit des zu prüfenden Bereichs. Der Grund kann auch darin liegen, dass generell Probleme mit der Bearbeitung von Aufgaben existieren (Prozessmangel). Manchmal wird die Vergesslichkeit auch als Ausrede benutzt, um zu testen, ob die IT-Revision sich damit zufrieden gibt oder ob sie nachhakt. 3. Der Bereich verfügt über die Dokumente, möchte sie aber nicht zur Verfügung stellen. Das ist relativ selten und immer dann der Fall, wenn die Dokumente größere Mängel oder sogar Rechtsbrüche offenbaren würden. Wenn sich die Revision sicher ist, dass die Dokumente existieren, kann das zu investigativen Maßnahmen bis hin zu Beschlagnahmungen o.Ä. führen. Praxistipp
Wenn Sie den Verdacht haben, dass Dokumente vorsätzlich nicht geliefert wurden, kontrollieren Sie die gelieferten Dokumente. Gibt es dort Hinweise auf die vorenthaltenen Dokumente? Wird auf diese Dokumente verwiesen oder sich auf dortige Verweise bezogen? Zu einem späteren Zeitpunkt können in der Prüfung auch die IT-Einstellungen kontrolliert werden. Werden die Dokumente dort als Ressourcen geführt (existieren z.B. Berechtigungen dafür?)
Die gelieferten Dokumente können bereits in dieser frühen Prüfungsphase hinsichtlich der Dokumentationsanforderungen untersucht werden. Sind die Dokumente aktuell und gültig? Aktuell heißt dabei nicht unbedingt, dass das Erstellungsdatum noch nicht lange zurückliegt, sondern dass der Inhalt der aktuellen Situation entspricht. Es ist sicher unglaubwürdig, wenn der aktuell geprüfte Bereich ein sieben Jahre altes Dokument zur IT-Strategie als aktuell darstellen will. Auch die Gesamtheit der Dokumente gibt erste Hinweise. Wurde die IT-Revision mit vielen einzelnen Dokumenten „zugeschüttet“, für die kein logisches Gesamtkonzept zu erkennen ist? Ist die Gesamtheit der Dokumente lückenhaft (wurden beispielsweise nur Planungsdokumente geliefert)? Sind sie in der Form einheitlich? Geht aus ihnen hervor, an welche Stelle sie in dem IT-Gesamtgefüge gehören? Nun wird der Inhalt im Hinblick auf das Prüfobjekt analysiert. Welcher Ist-Zustand würde sich nach der Dokumentationslage ergeben? Dabei gilt der Grundsatz: Was nicht doku-
34
2.4 Prüfungsdurchführung mentiert ist, ist auch nicht vorhanden. Auch für Absichtserklärungen o.Ä. in den Dokumenten gilt, dass sie für den Ist-Zustand nicht berücksichtigt werden. Das Sprichwort „Papier ist geduldig“ gilt auch hier. Nicht selten stimmen Dokumentation und Realität nicht überein. Manchmal wurden Änderungen ad hoc vollzogen (z.B. bei Betriebsstörungen) und anschließend nicht dokumentiert oder es ist für die Dokumentation ein bestimmter Mitarbeiter zuständig, der nicht informiert oder längere Zeit abwesend war. Aus diesem Grund die Auswertung der Dokumentation in keinem Fall ausreichend und muss ergänzt und validiert werden.
2.4.2
Fragebogenerhebung
Um Angaben vom geprüften Bereich einzuholen, kann ein Fragebogen erstellt und an den Bereich gesendet werden. Die Befürworter dieses Vorgehens argumentieren, auf diese Weise wären Informationen sehr effizient zu gewinnen. In der Tat ist nach der Erstellung des Fragebogens der Aufwand für die IT-Revision gering, wenn der geprüfte Bereich den Fragebogen selbständig ausfüllen kann. Für eine erfolgreiche Arbeit mit Fragebögen sind einige Punkte zu beachten: Die Fragen müssen eindeutig und für den geprüften Bereich verständlich formuliert sein. Einfachheit hat Vorrang vor sprachlicher Gewandtheit. Fragebögen sind nur bei standardisierten Prüfungen sinnvoll, da es ansonsten keine Einsparungen beim Aufwand gibt. Jede Prüfung mithilfe eines Fragebogens sollte systematisch ausgewertet werden und die dadurch gewonnenen Erkenntnisse in zukünftige Fragebögen einfließen. Praxistipps
Achten Sie darauf, dass mit dem Fragebogen nur Fakten erhoben werden und keine subjektiven Einschätzungen oder Meinungen. Beachten Sie auch, dass der Aufwand für die Auswertung steigt, je mehr freie Antworten Sie zulassen. Bauen Sie Plausibilitätsprüfungen in den Fragebogen ein, d.h. mehrere Fragen, bei denen sich aus den Antworten Widersprüche ergeben könnten. Stellen Sie auch nicht zu viele Fragen.
Kritiker dieses Vorgehens sehen vor allem viele Nachteile in der Anwendung von Fragebögen: Die Fragen werden vom geprüften Bereich oft nicht oder falsch verstanden und damit nicht aussagekräftig beantwortet. Der geprüfte Bereich muss oft zur Beantwortung gedrängt werden. Es fehlt die Möglichkeit, Nachfragen zu stellen. Durch die Distanz zum Prüfer wächst die Gefahr von geschönten, wohlformulierten Antworten oder von Angaben, die sich im Nachhinein als haltlos erweisen. Die Autoren haben es beispielsweise einmal erlebt, dass der IT-Bereich angab, eine ausgearbei-
35
2 Prüfungsorganisation und Vorgehen tete IT-Strategie zu besitzen. Es stellte sich heraus, dass damit ein einzelner Satz auf einer Powerpoint-Folie gemeint war. Aufgrund der schriftlichen Fixierung sind manche Befragte sehr vorsichtig beim Ausfüllen des Fragebogens, denn sie haben Bedenken, dass alles, was sie antworten, gegen sie verwendet werden kann. Bei freien Antworten kann der Fragebogen auch vom Befragten dazu umfunktioniert werden, „einmal richtig die Meinung zu sagen“. Die Antworten sind dann entsprechend emotional gefärbt und nicht gut verwertbar. Es empfiehlt sich daher nicht, den Ist-Zustand ausschließlich mittels eines Fragebogens zu erheben. Nur dort, wo eindeutige Fragen gestellt werden können, die keinen großen Interpretationsspielraum lassen, ist ein Fragebogen sinnvoll.
2.4.3
Interviews
Die am häufigsten gewählte Technik zur Erhebung des Ist-Zustandes ist das Interview. Sie gleicht einige Nachteile der Fragebogentechnik aus. So ist der Interviewer zum Zeitpunkt der Befragung anwesend. Er kann das Interview steuern, Fragen erläutern und bekommt außer der inhaltlichen Antwort auch über die Körpersprache weitere Informationen. Vorbereitung des Interviews Eine gute Vorbereitung ist für ein erfolgreiches Interview wichtig. Der Interviewer muss wissen: Welche Informationen sollen nach dem Interview vorliegen? Auf welche Weise sollen diese Informationen erhoben werden (Interviewleitfaden)? Mit wem hat es der Interviewer zu tun (Persönlichkeit, Position etc.)? Wie soll das Interview verlaufen (zeitliche Planung, Gesprächsphasen etc.)? Welche Interviewpartner werden zu welchem Zeitpunkt benötigt? Der erste Punkt ist besonders wichtig. Nach dem Interview muss ein bewertbarer IstZustand vorliegen, d h. es muss der bestehende Zustand aller Teilobjekte erhoben sein, an die externe und interne Vorgaben gestellt werden. Dazu werden zuerst die Vorgaben mit ihren Anforderungen zusammengestellt und daraus ein Gerüst erstellt, welche Gebiete des Prüfobjekts betrachtet werden müssen. Für diese Gebiete wird dann ein Fragenkatalog mit Prüfungsfragen erstellt, mit dem der Ist-Zustand aufgenommen wird. Beispiel
Die Sicherheit der Datensicherung (Prüfobjekt) soll geprüft werden. Aus den Vorgaben (Sicherheitsstandards, Security Policy) ergeben sich die Prüfgebiete Sicherungsstrategie, Sicherungsressourcen (Hardware, Software, Personal, Backup-Medien usw.), BackupProzess, Datenaufbewahrung und internes Kontrollsystem der Datensicherung.
36
2.4 Prüfungsdurchführung Eine Anforderung im Gebiet Datenaufbewahrung wäre, dass die Backup-Daten räumlich getrennt von den Originaldaten aufbewahrt werden müssen. Daraus wird die Prüfungsfrage „Wo werden die Backup-Medien aufbewahrt?“ abgeleitet. Wo die Originaldaten zu finden sind, sollte schon vorher erfragt worden sein. Damit hat man für diese Anforderung einen prüfbaren Ist-Zustand.
Der Interviewer sollte von der Fachkompetenz her in der Lage sein, den Antworten des Interviewten zu folgen, sie während des Interviews zu beurteilen und ggf. nachzufragen. Er sollte möglichst unbefangen sein und seine eigene Meinung außer Acht lassen. Der Interviewtermin muss frühzeitig genug vereinbart werden, damit der Termin in die Terminplanung integriert werden und sich der Interviewpartner vorbereiten kann. Im Zuge dieser Vereinbarung kann der Interviewpartner über die Zielsetzung des Interviews informiert werden. Interviews sollten nicht länger als zwei Stunden dauern, denn sonst schwindet die Konzentration. Werden mehr Informationen benötigt, als in zwei Stunden erhoben werden können, sollte besser ein weiterer Termin vereinbart werden. Die Interviewatmosphäre sollte möglichst störungsfrei sein, d h. keine laufenden Störungen durch Telefon- bzw. Handyanrufe, Besuche, laute Maschinen, Verkehr oder ähnliche Einflüsse. Es sollte keine Verhöratmosphäre entstehen, und deshalb ist von einem sturen Durchgehen einer Checkliste abzuraten, auch wenn eine solche Checkliste im Vorfeld des Interviews erstellt werden sollte. Besser ist es, ein lockeres Gespräch zu führen, im Verlauf dessen die Informationen gegeben werden. Jedoch darf der Interviewer die Lenkung des Gesprächs nicht an den Interviewpartner abgeben. Einige Personen erzählen sonst ihre halbe Lebensgeschichte und andere unwichtige Details, und der Interviewer bekommt trotz eines langen Interviews nicht die benötigten Informationen. Deswegen muss der Interviewer immer wieder „auf den Punkt kommen“ und Abschweifungen möglichst elegant, aber auch konsequent beenden. Praxistipps
Sagen Sie nicht so etwas wie „Erzählen Sie doch mal, wie Sie das so machen ...“. Damit laden Sie den Interviewpartner ein, die Kontrolle über das Interview zu übernehmen. Beziehen Sie sich immer auf etwas Konkretes. Lassen Sie sich nicht durch Informationen täuschen, die sich zwar sehr interessant anhören, aber nichts mit dem zu tun haben, was Sie erfahren möchten. Einige Interviewpartner füllen damit ein Großteil der Interviewzeit, lenken ab und drücken sich so vor weiteren, eventuell unangenehmen Fragen. Passen Sie auch auf, dass der Interviewte nicht anfängt, Sie zu interviewen. Gegenfragen sind in Ordnung, solange sie nicht von einer Antwort ablenken sollen oder eben zu einem Gegeninterview führen.
Die Fragen des Leitfadens muss der Interviewer nicht auswendig lernen, aber es ist besser, die Fragen in freier Rede einfließen zu lassen, als sie ständig vom Blatt abzulesen. Außerdem sind Sie dann flexibler und können durch Nebenfragen mehr erfahren.
37
2 Prüfungsorganisation und Vorgehen Durchführung des Interviews Nach einem kurzen Warm-Up startet die eigentliche Befragung. Hier gilt es einige Dinge zu beachten, wenn das Interview erfolgreich sein soll: Die Fragen sollten nicht so gestellt werden, dass man sofort erkennen kann, welche Antwort als „schlecht“ eingestuft werden würde. Wenn gefragt wird: „Wurden bei der Planung des IT-Verfahrens die Anforderungen der Geschäftsprozesse berücksichtigt?“, dann ist klar, dass der Prüfer ein „Ja“ hören möchte, um zufrieden zu sein. Besser wäre eine Formulierung wie „Welche Anforderungen haben denn die Geschäftsprozesse an das geplante IT-Verfahren gestellt?“. Es sollten keine manipulativen Fragen (Suggestivfragen) gestellt werden. Das sind Fragen, bei dem der Interviewer eine bestimmte Antwort bekommen möchte, und deshalb die Frage so stellt, dass der Befragte zur „richtigen“ Antwort gedrängt wird. Beispiel: „Sie sind doch sicher auch der Meinung, dass ...?“. Es sollte vermieden werden, dass die Meinung des Interviewers in das Interview einfließt. Beispiel: „Das ist doch viel zu umständlich ...“. Für die Erhebung des Ist-Zustands sollten möglichst durchgehend offene Fragen (WFragen wie Warum? Welche? Wie?) gestellt werden. Konkrete Prüfpunkte werden dagegen besser mit geschlossenen Fragen geprüft (also solchen, die nur mit Ja oder Nein beantwortet werden können). Beispiel
Eine Anforderung des BDSG lautet, dass es aus Datenschutzgesichtspunkten nur statthaft ist, diejenigen Daten einer Person zu speichern, die in der Geschäftsbeziehung mit der Person benötigt werden (Grundsatz der Datenminimierung). Im Interview gibt es verschiedene Möglichkeiten zur Erfragung dieser Anforderung: Geschlossene Frage nach der Konformität „Werden nur diejenigen Daten einer Person gespeichert, die in der Geschäftsbeziehung mit der Person benötigt werden?“ Geschlossene Frage nach der Potenz der Erfüllung „Ist definiert/dokumentiert, welche personenbezogenen Daten in einer Geschäftsbeziehung benötigt werden?“ Offene Frage nach dem Ist-Zustand „Welche personenbezogenen Daten werden in einer Geschäftsbeziehung gespeichert?“, „Welche personenbezogenen Daten werden in einer Geschäftsbeziehung benötigt?“ Offene Plausibilitätsfrage „Wie wurde/wird ermittelt, welche personenbezogenen Daten in einer Geschäftsbeziehung benötigt werden?“ Offene Frage nach der Kontrolle „Wie wird sichergestellt, dass nur die für die Geschäftsbeziehung benötigten personenbezogenen Daten gespeichert werden?“ Offene Frage nach dem Störfall „Wie wird erkannt, dass personenbezogene Daten gespeichert sind, die nicht in der Geschäftsbeziehung benötigt werden?“
38
2.4 Prüfungsdurchführung Besonders Führungskräfte und Personen in Leitungsfunktionen sind sich bewusst, dass jede ihrer Aussagen eine fachliche und gleichzeitig eine politische Dimension besitzt. Daher sollte man ihnen möglichst präzise und objektive Fragen stellen. Manchmal wird auch um eine Antwort gefeilscht ... Es darf nur darum gehen, die Ist-Situation aufzunehmen, und nicht darum, bestimmte Interessen zu verfolgen oder Schuldige für Missstände zu finden. Der Interviewer muss nachfragen, wenn er etwas nicht verstanden hat. Viele Interviewer schweigen, um nicht inkompetent zu wirken, doch das ist hier nicht angebracht. Der Interviewer darf sich nicht mit fadenscheinigen Aussagen zufriedengeben, er muss hartnäckig nachfragen und schon im Interview nach Fakten suchen, die die Aussagen belegen. Umgang mit Widerständen Niemand wird gerne geprüft, und so ist es nicht verwunderlich, dass auch die Organisationseinheiten eher ein Unbehagen spüren, wenn sich die IT-Revision ankündigt. Zum einen ist es eine zusätzliche Belastung zum Tagesgeschäft, zum anderen die Besorgnis, im Prüfungsbericht nicht gut „wegzukommen“. Das führt manchmal zu Widerstand gegen die Revisionsprüfung. Dabei sind verschiedene Ausprägungen denkbar: Offener Widerstand Hat man es mit selbstbewussten Personen zu tun, dann kann es zur Konfrontation kommen. Klar hat der Revisor angesichts der Rückendeckung durch das Top-Management die besseren Karten, aber die Organisationseinheiten wissen natürlich, dass ein Vorgehen mit der Brechstange nicht positiv gewertet wird. Erkennen lässt sich der Widerstand an Aussagen wie: „Wo steht, dass ich das erfüllen muss?“, „Das ist bei uns nicht möglich/aus Kostengründen nicht realisierbar“, „Die Notwendigkeit, das zu erfüllen, sehe ich nicht“. Verdeckter Widerstand Bei einem guten Standing der IT-Revision kann eine zu prüfende Organisationseinheit nur schwer offenen Widerstand leisten. Es gibt jedoch eine andere Möglichkeit: den Revisor ausbremsen. Erste Maßnahme: Zeit gewinnen und Interviewtermine hinauszögern. „Ich habe im Moment überhaupt keine Zeit für ein Interview8, und ich bin der Einzige, der Ihnen Auskunft geben könnte“. Im Interview werden dann nur die nötigsten Informationen gegeben und ständig interveniert: „Ich glaube nicht, dass das hier relevant ist“, „Was meinen Sie damit?“, „Was wollen Sie mir damit unterstellen?“. Lethargie Der zu prüfende Bereich zeigt totales Desinteresse an der Prüfung. Unterlagen bekommen Sie nur, wenn Sie sie ausdrücklich und präzise anfordern („Wir haben so viel, da
8
Das Gleiche geht natürlich auch mit Urlaub, Krankheit, Weiterbildung usw.
39
2 Prüfungsorganisation und Vorgehen müssen Sie schon genau sagen, was Sie haben wollen“). Im Interview stellt sich der Befragte dumm oder Sie bekommen auf Fragen nur eine allgemeine, nichtssagende Antwort. Beispiel: Auf die Frage, wie die Datensicherung vor sich geht, kommt die Antwort: „Wie man das halt so macht.“ Protokollierung der Aussagen Die Aussagen des Interviewpartners sollten an Ort und Stelle schriftlich festgehalten werden, am besten gleich während des Gesprächs. Es gibt keinen Dokumentationsstandard, wie dies zu geschehen hat. Einige Interviewer notieren frei auf einem Zettel, andere verwenden die Mind-Map-Methode und benutzen einen Laptop. Das Protokoll ist nicht geheim! Die Mitschrift darf nicht vor dem Interviewten verborgen werden und sollte so verfasst sein, dass der Interviewte sie nachvollziehen kann (keine Stenografie, sehr kleine oder unleserliche Schrift, unverständliche Abkürzungen usw.). Der Interviewer kann auch mit dem Interviewten zusammen grafisch die Zusammenhänge entwickeln und dazu Medien wie Whiteboard, Flipchart o.Ä. verwenden.
2.4.4
Verifikation der Aussagen
Bislang wurden durch die Dokumentenanalyse, Fragebögen und Interviews nur Behauptungen aufgenommen. Dokumente können aber veraltet und Interviewantworten schöngefärbt sein. Daher gilt der Grundsatz: Behauptungen müssen belegt werden. Nur was belegt ist, ist auch vorhanden! In der Regel überzeugt sich der Revisor selbst, ob ein behaupteter Sachverhalt der Realität entspricht. Es werden nur Tatsachen festgestellt, keine Vermutungen, Planungen, mündliche (nicht belegte) Absprachen, Meinungen, Wertungen, Über-/Untertreibungen, Belangloses oder nicht Dazugehörendes. Für die Kontrolle, ob die Behauptungen der Realität entsprechen, wird zwischen formellen und materiellen Prüfungshandlungen unterschieden: Formelle Prüfungshandlungen untersuchen, wie mit dem Prüfobjekt verfahren wird (Konzeption, Prozesse). Materielle Prüfungshandlungen untersuchen das Prüfobjekt inhaltlich. Der erste Schritt besteht in der Kontrolle der Existenz, anschließend werden die Eigenschaften des Prüfobjekts untersucht. In einer Prüfung der Autoren kam es einmal vor, dass in einem Systemkonzept eine Funktionalität einer Software behandelt wurde. Sie war in den Handbüchern beschrieben, und es gab auch entsprechende Prozessdiagramme und Berechtigungsstrukturen. Bei der Verifikation stellte sich dann heraus, dass diese optionale Funktionalität aus Kostengründen gar nicht implementiert wurde.
40
2.4 Prüfungsdurchführung Beispiel: Prüfung von Berechtigungen
Formell Wird die Berechtigungssystematik tatsächlich so gelebt, wie sie konzipiert wurde? Entsprechen die Abläufe bei der Rechtevergabe der Dokumentation? Wurden und werden die Vorgaben für die Rechtevergabe bzw. den Rechteentzug in der Praxis eingehalten (z.B. Genehmigung, Funktionstrennung usw.)? Materiell Besitzt das betrachtete System überhaupt die Möglichkeit, Berechtigungen einzurichten, und sind sie tatsächlich eingerichtet (Existenzprüfung)? Sind die Berechtigungen fein genug, um ihren Zweck zu erfüllen? Entsprechen die im System eingerichteten Berechtigungen dem Soll-Zustand laut Berechtigungskonzept?
Die früher noch energisch betriebene Unterscheidung der beiden Arten von Prüfungshandlungen wird heute oft nicht mehr explizit vollzogen. Für die Planung der Verifikation ist sie jedoch noch eine nützliche Hilfestellung. Die Verifikation kann progressiv geprüft werden, d h. von einer Einzelheit hin zur Gesamtheit (Beispiel: Von einer einzelnen Berechtigung über Rechteprofile und Rollen bis zur Identität – damit lässt sich die Frage beantworten, welche Identitäten über ein bestimmtes Recht verfügen). Oder es wird retrograd geprüft, d.h. von der Gesamtheit hin zu einer Einzelheit (Beispiel: Von einer Identität hin zu den Berechtigungen – damit lässt sich die Frage beantworten, über welche Rechte eine bestimmte Identität verfügt). Verifikation durch Plausibilität In der Praxis ist es wirtschaftlich nicht vertretbar, jede einzelne Aussage zu verifizieren, und das ist in den meisten Fällen auch nicht nötig. Denn schon bei der Betrachtung der Gesamtheit von System, Dokumentation, Interviewergebnissen usw. kann der Revisor recht schnell erkennen, ob er es mit einem chaotisch oder systematisch arbeitenden Bereich zu tun hat. Eine wichtige Frage hierbei ist, ob die Dokumente und die Aussagen, die der geprüfte Bereich gegeben hat, in sich schlüssig und widerspruchsfrei sind. Die Autoren haben es erlebt, dass eine Datenflussübersicht mit EDI-Übertragungsstrecken vorgelegt wurde, obwohl EDI im gesamten Unternehmen nicht mehr im Einsatz war. Auf Nachfrage tauchten mehrere andere Übersichten auf, die inhaltlich unterschiedlich waren. Die Realität bestand aus einem Mix der verschiedenen Übersichten. Verifikation durch Stichprobenprüfung Bei der Stichprobenprüfung wird aus einer Gesamtheit (z.B. alle Aussagen der Interviews oder alle Rollen im Berechtigungskonzept eines IT-Systems etc.) ein gewisser Anteil ausgewählt und verifiziert. Was nach welchem Verfahren ausgewählt werden soll, kann schon im Prüfungsauftrag festgelegt werden. Damit erspart man sich entsprechende Diskussionen. Wichtig ist, dass der geprüfte Bereich nicht in der Lage sein darf, aus bereits durchgeführten Prüfungen das Auswahlverfahren abzuleiten, um sich damit auf folgende Prüfungen vorzubereiten. Für die Auswahl gibt es mehrere Strategien: Bewusste Auswahl Der zu prüfende Anteil wird vom Revisor aufgrund seiner Qualifikation und Erfahrung ausgewählt. Es gibt drei vorherrschende Verfahren: 1) Der Anteil wird so gewählt, dass
41
2 Prüfungsorganisation und Vorgehen er typisch für die Gesamtheit ist, oder 2) Es wird der Teil ausgewählt, der den größten Anteil an der Gesamtheit ausmacht bzw. die größte Bedeutung für die Gesamtheit besitzt, oder 3) Es wird der Teil ausgewählt, der wahrscheinlich die meisten oder größten Mängel hat. Beispiel: Alle Rollen in einem IT-System. Nach 1) werden die typischen Rollen ausgewählt, nach 2) die Rollen, denen die meisten oder kritischsten Berechtigungen zugeordnet sind, und nach 3) die Rollen, bei denen am wahrscheinlichsten ist, dass sie falsche oder zu viele Berechtigungen enthalten. Zufallsauswahl Der Teil wird hier mithilfe von mathematisch-statistischen Verfahren nach dem Zufallsprinzip ausgewählt. Bei der einfachen Stichprobe werden aus allen M Elementen n Elemente per Zufall ausgewählt. Bei der geschichteten Stichprobe werden alle M Elemente zunächst in m zusammengehörende Bereiche eingeteilt und dann aus jedem Bereich (Elementevorrat in einem Bereich: M/m) n Elemente per Zufall ausgewählt. Verifikation durch Vollprüfung In bestimmten Fällen (z.B. wenn der Verdacht eines konkreten Verstoßes besteht oder die Gesamtheit relativ chaotisch erscheint, sodass aus einer Einzelheit keine Rückschlüsse auf die Gesamtheit gezogen werden können) ist es erforderlich, alle Elemente (z.B. Berechtigungen) lückenlos zu prüfen. Eine solche Prüfung ist wirtschaftlich jedoch nur dann vertretbar, wenn die Anzahl der Elemente überschaubar bleibt oder die Vollprüfung zwingend notwendig ist. Automatisierte Verifikation Mit dem Einsatz einer Audit-Software (siehe Kapitel 8) können Prüfungsfälle automatisiert geprüft werden. Das vermindert natürlich den Aufwand, erfordert jedoch eine intensivere Vorbereitung, sodass die automatisierte Verifikation vor allem bei standardisierten Prüfungen eingesetzt wird. Gegenlesen der Aussagen Die Mitschrift gibt das wieder, was der Protokollant verstanden und festgehalten hat. Das ist nicht unbedingt immer deckungsgleich mit dem, was der Interviewpartner tatsächlich gesagt oder gemeint hat (Stille-Post-Phänomen). Aus diesem Grund ist es notwendig, im Nachgang zum Interview im Anschluss an die Auswertung des Interviews eine Kopie des aufbereiteten Protokolls dem Interviewpartner zur Verfügung zu stellen, damit er überprüfen kann, ob die protokollierten Aussagen und die Darstellung der Zusammenhänge korrekt sind. Darin liegt natürlich auch eine Gefahr, denn die Aussagen aus dem Interview können so nachträglich verfälscht oder zensiert werden. Die Gefahr ist umso größer, wenn der Interviewte das Protokoll seinem Vorgesetzten vorlegt bzw. vorlegen muss. Dieser könnte inte-
42
2.5 Prüfungsbericht ressengeleitet bestimmte Aussagen umformulieren oder brisante Aussagen entschärfen wollen. Bemühen Sie sich, dass Informationen nicht einfach weggestrichen, sondern nur korrigiert werden, und lassen Sie sich die Richtigkeit der korrigierten Information belegen.
2.5
Prüfungsbericht 2.5.1
Dokumentation des Ist-Zustands im Prüfungsbericht
Die Ergebnisse der Dokumentensichtungen, Interviews, Verifikationen usw. sollten ein detailliertes und realitätsgetreues Bild des bestehenden Zustands ergeben. Schon bei der Vorbereitung der Interviews wurden die relevanten Vorgaben für das Prüfobjekt in die Interviewleitfäden eingearbeitet, sodass der im Prüfungsbericht dargestellte Ist-Zustand alle Informationen enthält, die für die Bewertung benötigt werden. Der Ist-Zustand wird im Prüfungsbericht so formuliert, dass nicht erkennbar ist, ob der bestehende Zustand einen Mangel darstellt oder nicht. Beispiel: „Die Loggingdaten können vom Sachbearbeiter nachträglich verändert werden.“ Hier erkennt der geprüfte Bereich, dass ein Mangel vorliegt, und könnte versucht sein, dies so nicht stehen zu lassen. Besser ist die Formulierung: „Im Berechtigungskonzept ist die Zugriffsberechtigung des Sachbearbeiters auf die Loggingdaten enthalten.“ Hier ist der Mangel nicht auf den ersten Blick ersichtlich. Ein Mangel kann sogar positiv formuliert werden, sodass der Eindruck entsteht, diese Tatsache wäre vorteilhaft für die Organisationseinheit. Beispiel: „Der Zugriff auf die Loggingdaten ist auf den Sachbearbeiter beschränkt.“ Ob diese Formulierung jedoch fair ist, sei dahingestellt. Im Bericht sollte immer nur erwähnt werden, was vorhanden ist, und nicht das, was fehlt. Beispiel: „Eine Verschlüsselung der Daten vor der Übertragung ist nicht vorhanden.“ Zum einen wird auch hier der Mangel ersichtlich, zum anderen bläht es den Bericht auf, wenn nur wenig vorhanden ist und vieles fehlt. Besser: „Die Daten werden im Klartext übertragen.“ Selbstverständlich darf nur das im Bericht stehen, was auch der Realität entspricht. Behauptungen, Vermutungen, Pauschalisierungen oder unbelegte Schlussfolgerungen haben keinen Platz im Bericht. Eine weitere Forderung besteht darin, nur wesentliche Fakten aufzunehmen. Der Begriff „wesentlich“ darf nicht mit „wichtig für den geprüften Bereich“ verwechselt werden, denn auch in diesem Sinne unwichtige Fakten können für das Prüfungsergebnis wesentlich sein. Nachdem der Ist-Zustand im Bericht niedergeschrieben und intern in der Revision abgestimmt wurde, wird der Bericht (der ausschließlich den Ist-Zustand enthält) der Leitungsebene des geprüften Bereichs zugesendet. Der geprüfte Bereich kann nun kontrollieren, ob
43
2 Prüfungsorganisation und Vorgehen der Revisor die Aussagen richtig verstanden und die bestehende Situation korrekt wiedergegeben hat. Der geprüfte Bereich kann Korrekturen anbringen oder Fakten ergänzen und sendet den Bericht zurück. Der Revisor wird nun wiederum kontrollieren, ob die Korrekturen und ergänzten Fakten zutreffen oder ob der Bereich Dinge nur beschönigen oder aus dem Bericht herausnehmen will. Gegen „schönere“ Formulierungen ist nichts einzuwenden, solange die Faktenlage dadurch nicht verfälscht wird. Die finale Fassung des Berichts mit dem Ist-Zustand sollte von der Leitungsebene des geprüften Bereichs gegengezeichnet und damit die im Bericht erwähnten Fakten bestätigt werden. So wird späteren Diskussionen über die Richtigkeit des Zustands, der der Bewertung zugrunde liegt, vorgebeugt. Mit der Unterschrift wird aber auch die Vollständigkeit bestätigt (und das ist den geprüften Bereichen nicht immer klar). Es ist also nur das vorhanden, was im Bericht aufgeführt wird, und nicht mehr (sonst hätte es ergänzt werden müssen). Immer dann, wenn eine Zuarbeit von dem geprüften Bereich benötigt wird (z.B. dass der Bericht unterschrieben zurücksendet wird), sollte eine angemessene Frist gesetzt werden. Es sollte festgelegt werden, dass der Bericht als genehmigt zu betrachten ist, wenn innerhalb der Frist keine Antwort erfolgt ist.
2.5.2
Bewertung des Ist-Zustands
Der bestehende Zustand des Prüfobjekts wird nun hinsichtlich der Soll-Vorgaben bewertet. Bei klassischen Revisionsprüfungen wird bewertet, ob es Mängel in der Erfüllung der SollVorgaben gibt, und wie schwer diese Mängel wiegen. Die von den Revisoren erarbeitete Bewertung mit den festgestellten Mängeln ist im Prüfungsbericht dokumentiert. Der geprüfte Bereich hat keinen Einfluss auf die Bewertung und kann nur in der Schlussbesprechung auf die Bewertung reagieren. Zu einer objektiven Bewertung gehört auch, nicht nur nach Mängeln zu suchen, sondern außerdem zu erwähnen, was positiv zu vermerken ist und was gut gelöst wurde. Im Hinblick auf das Ergebnis der Bewertung ist die Leitungsebene der Organisationseinheiten in der Regel recht empfindlich, denn das Ergebnis wird auch als Urteil über die Qualität und die Befähigung der leitenden Personen wahrgenommen. Daher fällt es den Bereichen oft schwer, die Mängel zu akzeptieren. Sie versuchen nachzuweisen, dass die aufgeführten Mängel falsch oder haltlos sind, dass die Revision unzureichend gearbeitet hat, dass von falschen Bedingungen ausgegangen wurde (z.B. Soll-Vorgaben, die nicht relevant sind), dass andere Untersuchungen (z.B. bei Zertifizierungen) zu einem anderen Ergebnis gekommen sind oder dass es keine vertretbare Alternative zum bestehenden Zustand gibt. Es ist daher sehr wichtig, dass alle Feststellungen im Prüfungsbericht den „Angriffen“ und Diskreditierungsversuchen standhalten können. Die Mängel müssen „wasserdicht“ begründet und durchgängig belegt werden. Ist dies der Fall, dann wird die Bewertung nicht mehr auf Drängen des geprüften Bereichs relativiert!
44
2.5 Prüfungsbericht Die Bewertung sollte kompakt, übersichtlich, verständlich, nachvollziehbar, belegt und objektiv formuliert sein. Persönliche Schuldzuweisungen („Der Bereichsleiter hat es versäumt, ...“), emotionale Färbungen („Dieser Zustand ist haarsträubend und ein Skandal!“) oder subjektive Bemerkungen („Das ist in den Augen der Revisoren purer Unsinn“) haben in der Bewertung nichts zu suchen. Zu jedem Mangel wird ermittelt, welche Folgen dem Unternehmen aus diesem Mangel heraus entstehen können. Dazu werden die Auswirkungen in Kategorien eingeteilt. Eine mögliche Einteilung wäre: A) Verstoß gegen Gesetze, Vorschriften, Bestimmungen, Verträge und Vereinbarungen Unzulässige Handlungen wie Betrug, Manipulation, Untreue, Unterschlagung oder Urkundenfälschung. B) Verstoß gegen interne Richtlinien. C) Beeinträchtigung der Aufgaben- bzw. Funktionserfüllung (d.h. termingerecht richtige und vollständige Ergebnisse zu liefern). D) Überschreitung von Kompetenzen und Befugnissen. E) Risiko für das Unternehmen. Verlust, Ausfall, Fehler und Störungen Unberechtigte Kenntnisnahme, Missbrauch Negative Auswirkungen (finanzieller Verlust, Imageschaden, Gefahr für Leib und Leben, Beeinträchtigung der informationellen Selbstbestimmung) F) Nachteil für das Unternehmen (fehlende Wirtschaftlichkeit und Zweckmäßigkeit, umständliche Prozesse, fehlende Angemessenheit, leistungsmindernde Zustände, fehlende Transparenz und Kontrollierbarkeit usw.). Die Folgen des Mangels werden in den Kategorien mit einem Schweregrad bewertet. Es gibt verschiedene Metriken für diese Schweregrade, daher ist die folgende Einstufung nur als Beispiel zu sehen. Stufe 1: Keine Mängel (Farbe: Grün) Kategorie
Ausprägung
A
Es liegt kein Verstoß gegen Gesetze und Vorschriften vor.
B
Es liegt kein Verstoß gegen interne Richtlinien vor.
C
Es sind keine Beeinträchtigungen der Aufgabenerfüllung vorhanden.
D
Die Kompetenzen und Befugnisse werden eingehalten.
E
Es sind keine Risiken für das Unternehmen zu finden.
F
Nachteile, die aus den bestehenden Zuständen resultieren, sind nicht zu erkennen.
45
2 Prüfungsorganisation und Vorgehen Stufe 2: Geringfügige9 Mängel (Farbe: Gelb) Kategorie Ausprägung A
Es liegt kein Verstoß gegen Gesetze und Vorschriften vor.
B
In Einzelfällen wird gegen interne Richtlinien verstoßen.
C
Es g bt tolerierbare zeitliche Abweichungen und seltene Abweichungen in Richtigkeit und Vollständigkeit der Ergebnisse.
D
Kompetenzen und Befugnisse werden selten, nur intern und ohne finanzielle Auswirkungen überschritten.
E
Es existiert nur ein geringes Risiko für Ertrag und Bestand, der zu erwartende Schaden ist tragbar und hat keine Außenwirkung.
F
In einigen punktuellen Dingen sind Nachteile zu beobachten, die Wettbewerbsfähigkeit ist nur in geringem Maße beeinträchtigt.
Stufe 3: Erhebliche10 Mängel (Farbe: Orange) Kategorie Ausprägung A
In seltenen Fällen und nur in unkritischen Bestimmungen kommt es zu Verstößen gegen Gesetze und Vorschriften.
B
Gegen interne Richtlinien wird mehrfach bis regelmäßig verstoßen.
C
Es g bt öfters größere zeitliche Abweichungen (selten kommt es zu Ausfällen in der Funktionserfüllung) und/oder unrichtige oder unvollständige Ergebnisse.
D
Intern werden Kompetenzen und Befugnisse öfters überschritten, was finanzielle Auswirkungen nach sich zieht, die für das Unternehmen verkraftbar sind.
E
Es existiert ein mittleres bis hohes Risiko für Ertrag und Bestand mit verkraftbaren Folgen. Der zu erwartende Schaden ist mittel bis hoch und besitzt eine Außenwirkung.
F
Die bestehenden Zustände besitzen deutliche Nachteile für das Unternehmen, die Wettbewerbsfähigkeit ist dadurch spürbar eingeschränkt.
Stufe 4: Schwerwiegende11 Mängel (Farbe: hellrot) Kategorie Ausprägung
9
A
Es kommt mehrfach bis regelmäßig zu Verstößen gegen kritische Bestimmungen (z.B. Straftatbestände) von Gesetzen und Vorschriften.
B
Gegen interne Richtlinien wird permanent und vorsätzlich verstoßen.
C
Es g bt öfters bis regelmäßig Ausfälle der Funktionserfüllung, unrichtige oder unvollständige Ergebnisse sind an der Tagesordnung.
D
Kompetenzen und Befugnisse werden intern und extern massiv überschritten mit finanziellen Schäden bis hin zum Ruin der Gesellschaft.
oder auch unwesentliche, unbedenkliche oder unbedeutende oder auch wesentliche, umfangreiche, starke oder große 11 oder auch gravierende, folgenschwere oder weitreichende 10
46
2.5 Prüfungsbericht E
Es existiert ein hohes bis sehr hohes Ris ko für Ertrag und Bestand, es sind hohe bis sehr hohe Schäden zu erwarten, die u.U. nicht mehr verkraftbar sind.
F
Die bestehenden Zustände zeigen gravierende Nachteile für das Unternehmen, die Wettbewerbsfähigkeit ist dadurch ernsthaft gefährdet.
In einer weiteren Stufe 5 finden sich besonders schwerwiegende Mängel (Farbe: dunkelrot). Das sind Mängel mit verheerenden Folgen für das Unternehmen (als Folge könnte die Existenz des Unternehmens auf dem Spiel stehen) und schwerwiegende Mängel, die der obersten Leitungsebene bekannt sind, von ihr gedeckt werden oder sogar von ihr selbst veranlasst wurden. Bei diesen Mängeln sind neben dem Top-Management auch verantwortliche Dritte (Aufsichtsrat, Aufsichtsbehörde) zu informieren.
2.5.3
Maßnahmenempfehlungen
Mit der Nennung der Mängel ist es nicht getan: Der geprüfte Bereich sollte auch eine Hilfestellung bekommen, wie diese Mängel behoben werden können. Sinnvoll ist es, zunächst zu vermitteln, welche Anforderungen existieren (welche Situation muss erreicht werden?) und dann Maßnahmen zu nennen, die diese Situation herstellen können. Wichtig ist, dass sich die IT-Revision nicht in die Entscheidungskompetenz der Linie einmischt, d h. nicht sagt: „Auf diese Weise und mit dieser Maßnahme muss es gemacht werden“. Mit einem solchen Vorgehen würde der geprüfte Bereich von Verantwortung freigesprochen, denn er könnte immer argumentieren, dass die Maßnahme ja von der ITRevision angeordnet wurde. Die IT-Revision würde damit auch operative Verantwortung übernehmen, was sie per Definition gerade nicht tun soll. Zudem besitzt die IT-Revision keine Weisungsbefugnis in den Organisationseinheiten. Die Verantwortung für die Maßnahmen liegt immer beim geprüften Bereich! Deshalb sind die Maßnahmen nur Empfehlungen, denen der geprüfte Bereich zustimmen und folgen oder aber widersprechen kann. Um zu verhindern, dass der geprüfte Bereich einfach aus einer Oppositionshaltung heraus pauschal widerspricht, sollte ein Widerspruch nur akzeptiert werden, wenn plausibel begründet wird, warum in dem Bereich die jeweilige Maßnahme nicht umgesetzt werden soll. Die Maßnahmenempfehlungen werden üblicherweise mit einer Frist für die Umsetzung versehen. Die Frist sollte hinsichtlich der Anzahl und der Umfang der Maßnahmen angemessen sein. Für die Einhaltung der Frist ist der geprüfte Bereich verantwortlich!
2.5.4
Entwurf und Abstimmung des Prüfungsberichts
Durch den Prüfungsbericht12 wird die Arbeit der IT-Revision nach außen sichtbar. Der Auftraggeber und die geprüften Bereiche lesen die Berichte u.U. sehr genau, daher muss
12
oder auch Revisionsbericht.
47
2 Prüfungsorganisation und Vorgehen bei der Gestaltung und Erstellung der Berichte sorgfältig gearbeitet werden. Die Anforderungen an einen Prüfungsbericht lassen sich wie folgt einteilen: Formale Anforderungen Der Bericht enthält alle erforderlichen dokumentarischen Angaben. Diese Angaben umfassen: Datum des Berichts, Versionierung, Empfängerkreis des Berichts13, Bearbeitungsvermerke und Unterschriften, Inhaltsverzeichnis. Der Bericht enthält alle erforderlichen Angaben zur Prüfung. Das sind: Zeitraum, geprüfter Bereich, Prüfobjekt, Prüfungsthema, Prüfer, Angaben zur Planmäßigkeit der Prüfung. Der Bericht liegt möglichst zeitnah nach dem Abschluss der Prüfung vor. Üblich sind Zeiträume zwischen wenigen Tagen und vier Wochen. Visualisierungen Komplexe Zusammenhänge (Systeme, Strukturen usw.) werden am besten grafisch dargestellt (ein Bild sagt mehr als tausend Worte). Der Bericht verfügt über eine Zusammenfassung (Management Summary) des Prüfungsergebnisses. Vor allem das Top-Management als üblicher Auftraggeber ist daran interessiert, schnell einen Überblick über die wichtigsten Feststellungen, deren Schwere und die daraus resultierenden Empfehlungen zu gewinnen. Gibt es Dinge, die nur das Top-Management und nicht der geprüfte Bereich erfahren soll, dann werden sie mit einem separaten Schreiben an das Top-Management übermittelt. Inhaltliche Anforderungen Das Prüfungsergebnis wird objektiv, verständlich und fachlich fundiert dargestellt. Bei der Dokumentation sind die in Abschnitt 2.5.2 gemachten Ausführungen zu beachten. Der Stil sollte nicht dozierend sein und auf komplizierte Satzgebilde verzichten. Aus dem Bericht geht hervor, auf welche Weise die Fakten ermittelt wurden. Damit wird nachgewiesen, dass die Prüfung in quantitativer und qualitativer Hinsicht ordnungsmäßig durchgeführt wurde. Es wird beschrieben, welche Prüfungshandlungen in welchem Umfang mit welcher Methodik und aus welchem Grund vorgenommen wurden. Der bestehende Zustand ist im Bericht in verständlicher Form wiedergegeben. Es muss im Bericht zu erkennen sein, welche Faktenlage zu den Feststellungen führte. Aus diesem Grund wird im Bericht der von dem geprüften Bereich bestätigte IstZustand beschrieben (siehe dazu auch Abschnitt 2.5.1). Die Ausführungen sind so zu formulieren, dass sie auch von Dritten verstanden werden können. Dabei ist darauf zu
13
48
Mindestens an Top-Management als Auftraggeber und an den geprüften Bereich. Auf Anforderung auch an den Aufsichtsrat, den Wirtschaftsprüfer und die Aufsichtsbehörde (soweit vorhanden).
2.6 Prüfungsabschluss achten, Begriffe eindeutig zu verwenden und auf Begriffe zu verzichten, die eine Wertung enthalten. Im Bericht finden sich Empfehlungen, wie die gefundenen Mängel behoben werden können. Die Empfehlungen werden üblicherweise als Maßnahmenliste verfasst. Es gelten auch die Aussagen aus Abschnitt 2.5.3. Das Prüfobjekt bzw. der Prüfungsgegenstand und die Prüfkriterien werden im Bericht dargestellt. Die Leser des Prüfungsberichts sind im Bezug auf das Prüfobjekt keine Spezialisten. Neben der Angabe, welches Prüfobjekt untersucht wurde, wird dem Leser das Prüfobjekt auch erklärt. Dazu wird die Funktion (Für was wird es wie genutzt?) und die Beschaffenheit (Wie ist es gestaltet? Aus welchen Komponenten besteht es und wie wirken diese zusammen?) vorgestellt. Ebenfalls wird erläutert, welche Prüfkriterien angewendet wurden, denn die Auswahl der Kriterien hat entscheidenden Einfluss auf die Beurteilung des Prüfobjekts.
2.6
Prüfungsabschluss 2.6.1
Schlussbesprechung
Wenn in der Prüfung keine Mängel festgestellt wurden, kann der finale Revisionsbericht erstellt und verteilt werden. Ansonsten ist es üblich, die gefundenen Mängel vor der finalen Version des Revisionsberichts mit dem geprüften Bereich zu besprechen. Die Ziele dieser Besprechung sind: Der geprüfte Bereich soll erfahren, welche Mängel aus Sicht der IT-Revision vorliegen und warum diese Mängel als solche zu betrachten sind. Der geprüfte Bereich soll auf die Schwere der Mängel hingewiesen werden und besser verstehen können, wie die Einstufung der Mängel zustande kam. Die Maßnahmenempfehlungen sollen dem geprüften Bereich vorgestellt werden, und es soll erläutert werden, woher sie kommen und wie sie in der Praxis umgesetzt werden könnten. Es soll Einigkeit über die Maßnahmen erzielt und die Zusage des geprüften Bereichs zur Umsetzung eingeholt werden. Der geprüfte Bereich soll die Möglichkeit bekommen, seine Sicht zu Punkten darzustellen, mit denen er nicht einverstanden ist, und Punkte zu diskutieren, die er als Fehler ansieht. Der Revisionsbericht und die Maßnahmenempfehlungen sollen verabschiedet werden. Der Teilnehmerkreis der Schlussbesprechung entspricht dem des Kick-off-Meetings. Die Einladung der Teilnehmer erfolgt durch die Revisoren zeitnah nach Prüfungsende, meist
49
2 Prüfungsorganisation und Vorgehen innerhalb von zwei Wochen, wobei dem geprüften Bereich zur Vorbereitung auf die Besprechung ein vor-finaler14 Prüfungsbericht zur Verfügung gestellt wird. Praxistipp
Sorgen Sie für ein „Gleichgewicht der Kräfte“ in der Schlussbesprechung. Haben Sie es mit einer starken Organisationseinheit zu tun, der mit seiner Leitung in der Schlussbesprechung vertreten ist, so empfiehlt es sich, auch auf Seiten der Revision mit der Leitung vertreten zu sein. Bei besonders wichtigen Prüfungen und brisanten Prüfungsergebnissen kann es sinnvoll sein, dass auch ein Top-Manager als Vorgesetzter der Revision teilnimmt.
Die Besprechung wird in der Regel von dem Revisor moderiert, der die Prüfung maßgeblich geführt hat. Nimmt der Revisionsleiter teil, so kann auch er die Moderation übernehmen. Die Besprechung wird auf Seiten der Revision durch ein Ergebnisprotokoll dokumentiert, in dem besonders die Punkte aufgenommen werden, bei denen es Meinungsverschiedenheiten gibt, denn die IT-Revision hat keine direkte Weisungsbefugnis gegenüber dem geprüften Bereich. Besteht die Gefahr, dass im Nachhinein Aussagen des Protokolls bezweifelt werden, dann sollte die Protokollmitschrift von den Teilnehmern unterzeichnet werden. Aus verständlichen Gründen besteht nicht selten das Interesse des geprüften Bereichs darin, in der Besprechung dafür zu sorgen, dass die Feststellungen abgeschwächt oder sogar ganz eliminiert werden. Die Revisoren sollten dies nur dann zulassen, wenn bei der Bewertung ein Fehler gemacht wurde oder überzeugende Gründe angeführt werden, die auch die IT-Revision vertreten kann. Die Schlussbesprechung ist keine Verhandlung!
2.6.2
Vollständigkeitserklärung
Alle Prüfungsergebnisse sind nur so gut wie das Material, das der Prüfung zugrunde liegt. Es kommt vor, dass Dokumente zurückgehalten oder in den Interviews Tatsachen verschwiegen werden, obwohl klar ist, dass sie für die Bewertung wichtig sind. Fällt das irgendwie auf, kommt oft als Rechtfertigung: „Das (Dokument) ist ja nicht explizit angefordert worden“ bzw. „Danach bin ich ja nicht gefragt worden“. Bereits zu einem frühen Zeitpunkt sollte daher darauf hingewiesen werden, dass es in der Verantwortung des geprüften Bereichs liegt, den Revisoren alle Dokumente und Auskünfte zu geben, die für die Beurteilung relevant sind. Praxistipp
Fordern Sie als Revisor nicht direkt einzelne Dokumente an, sondern fragen Sie nach Dokumenten in einzelnen Prüfungsgebieten. Beispiel: Statt das Notfallhandbuch anzufordern (das vielleicht nicht existiert oder mit anderen Dokumenten ergänzt werden muss), sollte nach Dokumenten gefragt werden, die das Vorgehen im Notfall beschreiben.
14
50
Im IT-Jargon spricht man auch von der Version 0.99, also der letzten Entwurfsversion vor der ersten freigegebenen Version 1.0.
2.6 Prüfungsabschluss Mit der Vollständigkeitserklärung bestätigt der geprüfte Bereich, dass er nach bestem Wissen und Gewissen alle prüfungsrelevanten Informationen zur Verfügung gestellt und nichts vorenthalten hat. Die Erklärung ist schriftlich gegenüber der Revision abzugeben und von der Leitungsebene des geprüften Bereichs zu unterzeichnen.
2.6.3
Stellungnahme des geprüften Bereichs
Wie in Abschnitt 2.5.2 erwähnt wurde, werden die Bewertung und die empfohlenen Maßnahmen nicht mit dem geprüften Bereich verhandelt, sondern allenfalls Fehler korrigiert. Es kann jedoch vorkommen, dass der geprüfte Bereich mit der Bewertung oder einzelnen Maßnahmen auch nach der Besprechung überhaupt nicht einverstanden ist. Für diesen Fall sollte dem geprüften Bereich die Möglichkeit gegeben werden, eine Stellungnahme zum Prüfungsbericht abzugeben. Der im Bericht dargestellte Ist-Zustand kann dabei nicht kritisiert werden, da dessen Richtigkeit bereits bestätigt wurde (siehe Abschnitt 2.5.1). Widerspricht eine Organisationseinheit einer Maßnahme, so übernimmt sie das damit entstehende Risiko. Dies ist nur dann zulässig, wenn sie für dieses Risiko auch geradestehen kann. In allen anderen Fällen entscheidet die Instanz bzw. Ebene, die das Risiko tragen kann, und in letzter Instanz das Top-Management. Die Empfänger des Berichtes erhalten zusammen mit dem Bericht die Stellungnahme und können sich so ein eigenes Bild machen. Für die Qualitätssicherung der IT-Revision ist es sinnvoll, den geprüften Bereich zu bitten, die Durchführung der Prüfung zu beurteilen und ein entsprechendes Feedback zu geben. Dafür kann ein formalisierter Feedbackbogen erstellt werden. Eine Gefahr liegt darin, dass der geprüfte Bereich nun „Rache“ für schlechte Bewertungen im Prüfungsbericht oder (aus seiner Sicht) mangelndes Entgegenkommen nehmen könnte. Da eine solche Beurteilung bei jeder Prüfung stattfindet, fällt ein solches Verhalten jedoch schnell auf.
2.6.4
Verfolgung der Umsetzung der Maßnahmen
Nicht selten werden die Empfehlungen zähneknirschend akzeptiert, und dann wird versucht, mit minimalem Aufwand durch die Maßnahmen zu kommen. Dabei obliegt es dem geprüften Bereich, der IT-Revision schriftlich über die Mängelbeseitigung zu berichten. Um sicherzugehen, dass die Umsetzung auch tatsächlich erfolgt ist und die Maßnahmen die erforderliche Qualität und Wirksamkeit besitzen, muss es eine Kontrolle der Umsetzung geben. Die von der IT-Revision erstellten und mit dem geprüften Bereich vereinbarten Maßnahmenempfehlungen werden, wie in Abschnitt 2.5.3 erwähnt, mit einer Frist für die Umsetzung versehen. Daher sollte nach Ablauf der Frist eine Überprüfung stattfinden, die als Follow-up, Nachprüfung, Nachschau oder Nachrevision bezeichnet wird. Kontrolliert wird im Follow-up, ob die Maßnahmen fristgerecht umgesetzt wurden (die Verantwortung dafür liegt beim geprüften Bereich),
51
2 Prüfungsorganisation und Vorgehen ob die Maßnahmen so wie vereinbart umgesetzt wurden, ob die Art und Weise, wie die Maßnahmen umgesetzt sind, die Mängel beheben, die den Maßnahmen zugrunde liegen. Wird die Frist versäumt oder ist die Mängelbeseitigung unzureichend, kann der Fall schriftlich an das Top-Management eskaliert werden. In der Praxis ist hier Fingerspitzengefühl gefragt. Im Vordergrund muss stehen, dass die Ziele (Maßnahmenumsetzung) erreicht und keine Fronten aufgebaut werden.
52
3 3 Zusammenspiel mit externen Wirtschaftsprüfern Für die Revision ist die Dokumentation des Prüfungsvorhabens von großer Bedeutung. Aber nicht nur für interne Empfänger wie die Unternehmensleitung, sondern auch für externe können die Ergebnisse der Revision von großem Nutzen sein, insbesondere für Wirtschaftsprüfer. Wann Sie in Ihrer täglichen Revisionsarbeit mit externen Wirtschaftsprüfern in Kontakt kommen und wo sich Synergien Ihrer Arbeit ergeben, das soll dieses Kapitel beleuchten.
3.1
Aufgabe der externen Wirtschaftsprüfer Externe Wirtschaftsprüfer haben einen bestimmten Prüfungsauftrag. Eine Definition des Inhaltes der Arbeit und somit der Aufgabe eines Wirtschaftsprüfers findet sich in § 2 des Gesetzes über eine Berufsordnung der Wirtschaftsprüfer (Wirtschaftsprüferordnung). Dort heißt es: § 2 Inhalt der Tätigkeit (1) Wirtschaftsprüfer haben die berufliche Aufgabe, betriebswirtschaftliche Prüfungen, insbesondere solche von Jahresabschlüssen wirtschaftlicher Unternehmen, durchzuführen und Bestätigungsvermerke über die Vornahme und das Ergebnis solcher Prüfungen zu erteilen. (2) Wirtschaftsprüfer sind befugt, ihre Auftraggeber in steuerlichen Angelegenheiten nach Maßgabe der bestehenden Vorschriften zu beraten und zu vertreten. (3) Wirtschaftsprüfer sind weiter befugt, 1. unter Berufung auf ihren Berufseid auf den Gebieten der wirtschaftlichen Betriebsführung als Sachverständige aufzutreten; 2. in wirtschaftlichen Angelegenheiten zu beraten und fremde Interessen zu wahren; 3. zur treuhänderischen Verwaltung.
53
3 Zusammenspiel mit externen Wirtschaftsprüfern Für den Zweck dieses Kapitels, Ihnen das Zusammenspiel zwischen Wirtschaftsprüfung und Revision näherzubringen, ist Absatz 1 der ausschlaggebende. Die Aufgabe eines Wirtschaftsprüfers ist also die Prüfung von Jahresabschlüssen und die Erteilung von Testaten (Bestätigungsvermerken). Geprüft werden dabei nicht nur die Buchhaltungen in Papierform, sondern auch die elektronischen Buchhaltungen bzw. Nebenbuchhaltungen wie Geschäftsbriefe oder die Arbeitszeiterfassung sowie die Systeme, auf denen diese betrieben werden. Die Prüfungen weiten sich also auch auf die IT aus. Folgende Fragen stellen sich deshalb für die Arbeit des Revisors: Welche Grundlagen hat eine Prüfung durch einen Wirtschaftsprüfer? Wie prüft der Wirtschaftsprüfer die IT? Wie beeinflusst meine Arbeit die Ergebnisse des Wirtschaftsprüfers? Wie kann eine Zusammenarbeit aussehen?
3.2
Grundlagen der Prüfung durch einen Wirtschaftsprüfer Die gesetzlichen Grundlagen, nach denen ein Wirtschaftsprüfer einen Jahresabschluss zu prüfen hat, sind in den Paragraphen §§ 316 ff HGB definiert. Das Vorgehen zur Prüfung eines Jahresabschlusses findet sich im § 317 (Gegenstand und Umfang einer Prüfung). Es unterteilt sich in drei Schritte: Jahresabschlussprüfung Die Jahresabschlussprüfung ist der Ausgangspunkt für die Wirtschaftsprüfung und dient der orientierenden und gleichzeitig kritischen Einordnung des Kunden durch Sammlung und Analyse von prüfungsrelevanten Unternehmensinformationen über wirtschaftliche Rahmenbedingungen, Geschäftstätigkeit, das zur Fehlerverhütung und -entdeckung eingerichtete Kontrollsystem (internes Kontrollsystem, kurz IKS) und über die Grundlagen des Rechnungswesens. Hinweise auf Quellen möglicher Unrichtigkeiten und Verstöße sind zu gewinnen; die gesamte Vorkenntnis des Prüfers über denkbare Quellen spielt bereits in dieser Phase eine große Rolle. Prüfprogrammentwicklung Hier wird der relevante Prüfungsstoff sachlich in Prüffeldergruppen und einzelne Prüffelder gegliedert. In der Phase der Prüfprogrammentwicklung werden neben den Prüfungsinhalten auch die Prüfungsumfänge und die sachlichen und zeitlichen Abfolgen festgelegt; zudem werden Prüfer und Prüfungsgehilfen den Aufgaben zugewiesen. Programmdurchführung Hier finden Funktionsprüfungen des betrieblichen Kontrollsystems statt, ebenso werden die Jahresabschlussergebnisse verifiziert. Die Regelungen der Paragraphen § 316 und § 317 HGB gelten für den gesamten Jahresabschluss. Im Zentrum der Prüfung stehen dabei die Buchführung und deren Ergebnisse. Aus den für die Buchführung geltenden Regelungen hat der Fachausschuss für Informations-
54
3.2 Grundlagen der Prüfung durch einen Wirtschaftsprüfer technologie (FAIT) beim Institut der Wirtschaftsprüfer in Deutschland e.V. (IDW) die „Grundsätze ordnungsmäßiger Buchführung (GoB)“-Anforderungen für den Einsatz der IT weiter ausgeführt und hierzu verschiedene Rechnungslegungsstandards veröffentlicht: GoB bei Einsatz von Informationstechnologie (IDW RS1 FAIT 1), GoB bei Einsatz von Electronic Commerce (IDW RS FAIT 2), GoB beim Einsatz elektronischer Archivierungsverfahren (IDW RS FAIT 3). Bei der Durchführung von IT-Prüfungen finden auch die „Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS)“ sowie das dazu ergangene Begleitschreiben des Bundesministers der Finanzen (BMF) Anwendung (siehe Kapitel 4). Die „Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU)“ sind ebenso zu beachten wie die Grundsätze zur Aufbewahrung von Unterlagen. Das Gesamtgebilde der Informationstechnik wird zur Eingrenzung der Prüfungen in mehrere Teile gegliedert, die die in Abbildung 3.1 gezeigte Struktur besitzen.
Abbildung 3.1 IT-Strukturierung des IDW
Für die konkrete Prüfung ist demnach festzulegen, welcher Teil der IT geprüft werden soll (Prüfungsgegenstand und Prüfungsziel) und welche Anforderungen an die IT dazu geprüft werden sollen (Prüfungskriterien). Der Prüfungsumfang wird im Einzelfall durch den Prüfer bestimmt. Das Vorgehen dabei resultiert aus dem IDW PS2 330 und wird dort genau beschrieben. 1
RS = Stellungnahme zur Rechnungsprüfung
55
3 Zusammenspiel mit externen Wirtschaftsprüfern Die einzelnen Standards, die in diesem Kapitel erwähnt werden, können in elektronischer oder Papierform beim Institut der Wirtschaftsprüfer auf der Website http://www.idw.de erworben werden. Nun wissen wir, welche Grundlagen die Wirtschaftsprüfer bei einem Jahresabschluss anzuwenden haben. Wie eine solche Prüfung durchgeführt wird, soll der nächste Abschnitt vermitteln.
3.3
Vorgehen bei der Prüfung durch externe Wirtschaftsprüfer Da die Prüfung von Informationstechnologie innerhalb eines Unternehmens nicht zu den Haupttätigkeitsgebieten eines Wirtschaftsprüfers gehört, wurde die Prüfung der einzelnen Bereiche durch den Fachausschuss für Informationstechnik (FAIT) genauer definiert. Danach geht der Wirtschaftsprüfer in den folgenden Schritten vor: 1. Auftragsannahme und Prüfungsplanung 2. Erhebung von Informationen 3. Prüfung des IT-Umfelds und der IT-Organisation 4. Prüfung der IT-Infrastruktur Physische Sicherungsmaßnahmen Logische Zugriffskontrollen Datensicherungs- und Auslagerungsverfahren Maßnahmen für den Regel- und Notbetrieb Sicherung der Betriebsbereitschaft 5. Prüfung der IT-Anwendungen Programmfunktionen Auswahl-, Entwicklungs- und Änderungsprozess Implementierung 6. Prüfung IT-gestützter Geschäftsprozesse 7. Prüfung des IT-Überwachungssystems 8. Prüfung des IT-Outsourcing Vor der eigentlichen Prüfung muss eine Bestandsaufnahme des IT-Systems durchgeführt werden. Die Ergebnisse dieser IT-Systemaufnahme dienen als Basis für eine Risikoeinschätzung, auf die wiederum die weitergehende Prüfungsstrategie aufbaut wird. Die Ergebnisse zeigen die im weiteren Prüfungsvorgehen zu vertiefenden (IT-bezogenen) Prüffelder auf. 2
56
PS = Prüfungsstandard
3.4 Ergebnisse der internen Revision verwenden Anschließend wird pro Prüffeld eine Aufbauprüfung vorgenommen, bei der die Angemessenheit der konkreten Ausgestaltung des IT-Systems beurteilt wird. Ziel ist die Beurteilung, ob das eingerichtete (und dokumentierte) IT-System unter Berücksichtigung der prüffeldspezifischen Risiken angemessen ist und im geplanten Umfang wirksam sein kann. Im Anschluss hieran wird im Rahmen der Funktionsprüfung in den Bereichen, in denen das System in der Aufbauprüfung als angemessen beurteilt wurde, geprüft, ob die eingerichteten Kontrollen im Ist-Zustand wirksam sind. Die jeweiligen Soll-Zustände sind die Anforderungen der IDW-Prüfungsstandards. Wie in Abschnitt 3.2 erwähnt, gibt es jeweils passende Standards für die einzelnen Teilbereiche des Systems. Dieser Überblick über die Aufgaben und das Vorgehen eines Wirtschaftsprüfers macht deutlich, dass die Vorgehensweisen und die Ergebnisse denen der Revision ähneln. Daraus ergibt sich die Möglichkeit, Ergebnisse zwischen der externen Wirtschaftsprüfung und der internen Revision auszutauschen und dadurch Synergieeffekte zu erzielen.
3.4
Ergebnisse der internen Revision verwenden Um die Ergebnisse der internen Revision verwenden zu können, muss der Wirtschaftsprüfer oder derjenige, der im Auftrag des Wirtschaftsprüfers die IT-Prüfung durchführt, sich in der Dokumentation wiederfinden, d h. die Dokumentation sollte den Anforderungen der externen Wirtschaftsprüfer entsprechen. Nun kann man sich berechtigterweise fragen, ob auch jemand anderes als der Wirtschaftsprüfer prüfen darf und ob dieser Prüfer genauso informiert werden muss. Da sich, wie bereits erwähnt, die Kernkompetenz eines Wirtschaftsprüfers nicht unbedingt auf die ITPrüfung bezieht, lassen die Prüfungsvorgaben die Unterstützung durch IT-Sachverständige zu. Dies sieht der IDW PS 330 explizit vor: Sofern der Abschlussprüfer nicht selbst über die erforderlichen Kenntnisse zur Durchführung einer IT-Systemprüfung verfügt, ist es im Rahmen der Prüfungsdurchführung erforderlich, Arbeitsergebnisse oder Untersuchungen von IT-Sachverständigen in die eigenverantwortliche Bildung des Prüfungsurteils einzubeziehen. Deren Arbeit kann unbeschadet der Eigenverantwortlichkeit des Abschlussprüfers als Prüfungsnachweis für die Abschlussprüfung verwertet werden. Diese IT-Sachverständigen übernehmen hier die Fachkompetenz der Prüfung und sind somit auch zu informieren. Doch zurück zum Informationsaustausch. Um konkret zu erfahren, welche Informationen die IT-Revision zur Verfügung stellen soll, schauen wir auf die Informationen, die der Prüfer für sein Vorgehen benötigt. Diese Informationen gliedern sich in fünf Teilbereiche: IT-Umfeld Grundeinstellung zum Einsatz von IT-Systemen, beispielsweise dokumentiert im IT-Sicherheitskonzept (Unternehmensleitlinien, IT-Sicherheitshandbücher u.a.).
57
3 Zusammenspiel mit externen Wirtschaftsprüfern Verbindlich niedergelegte IT-Strategie, abgeleitet aus der Unternehmensstrategie. High Level Controls. IT-Organisation Organigramme und Ablaufpläne. Verantwortlichkeiten und Kompetenzen. Regelungen und Verfahren zur Steuerung des IT-Betriebs. Maßnahmen und Regelungen für die Entwicklung, Einführung und Änderung von IT-Anwendungen. IT-Infrastruktur Hardware (Großrechner, Client-Server-Systeme, PC und PC-Netzwerke). Betriebssysteme (z.B. MVS, UNIX-Derivate, Netzwerkbetriebssysteme, PC-Systeme) sowie Middleware (z.B. Archivierungs- oder Bibliothekssysteme). Netzwerke (Local Area Network (LAN), Wide Area Network (WAN), Internet/ Intranet/Extranet). IT-Betrieb (Organisation, Systemverwaltung, Produktionsabwicklung, Ressourcen-, Change- und Problemmanagement). Sicherheitskonzept (Zugriffskontrollsysteme, Firewalls, Datensicherung). IT-Anwendungen Bezeichnung der Software, Kurzbeschreibung des Aufgabengebietes und zugrunde liegende Hardwareplattform. Klassifizierung der Software nach Dialog- und/oder Batch-Anwendung. Software-Typ (Individual-Software, Standard-Software, modifizierte Standard-Software, Hersteller und eingesetzte Version). Angaben zu den verwendeten Programmiersprachen und zur Datenhaltung (Datenbank- bzw. Dateiorganisation). IT-Geschäftsprozesse Rechnungslegungsrelevante Unternehmensabläufe anhand der funktions- oder prozessorientierten Beschreibung der Ablauforganisation. Hierfür eingesetzte IT-Infrastruktur und IT-Anwendungen sowie relevante Schnittstellen. Datenfluss (Datenherkunft, Verarbeitung, Datenübergabe). Verbindung zur Buchführung. Zu den genannten Teilbereichen kann die interne Revision Unterlagen liefern und auf diese Weise den Umfang der Arbeit der externen Prüfer minimieren. Wenn die Unterlagen den Anforderungen der Wirtschaftsprüfer entsprechen, ermöglicht dies eine schnelle Dokumentenprüfung, die dann nur noch stichprobenartig in der IT-Umgebung überprüft werden muss. Diese Vorgehensweise ist ebenfalls im IDW PS 330 beschrieben:
58
3.4 Ergebnisse der internen Revision verwenden Anhand der vorgelegten Unterlagen hat der Abschlussprüfer die Angemessenheit der Richtlinien und Verfahren im Hinblick auf Vollständigkeit, Aktualität und hinreichende Beachtung von Organisationsprinzipien (z.B. Funktionstrennung und Vertretungsregelungen) zu beurteilen …. Die Prüfung der Wirksamkeit der Maßnahmen im Bereich von IT-Umfeld und ITOrganisation wird der Abschlussprüfer anhand von Stichproben im Unternehmen durchführen. Doch welche Unterlagen sind zu den jeweiligen Bereichen zu erstellen bzw. durch die interne Revision zu prüfen? Bereits im Unternehmen existierende Dokumentationen können von der internen Revision genutzt werden. Wird die Dokumentation von Anfang an am IDW-Standard ausgerichtet, dann ist sie auch für den externen Wirtschaftsprüfer verwendbar. Die Herkunft der Dokumentation ist im Standard erwähnt: Die Aufbauprüfung des IT-Umfelds und der IT-Organisation erfolgt auf Basis des vorgelegten Sicherheitskonzeptes, der IT-Strategie, der Regelungen zur Aufbau- und Ablauforganisation (Organisationsplan, Richtlinien und Arbeitsanweisungen) sowie auf Grundlage von Prozess- und Funktionsbeschreibungen. Im Prüfungsstandard wird unter den geforderten Dokumenten auch ein Sicherheitskonzept aufgeführt. In einer Verlautbarung des IDW wird das Vorgehen nach ISO 27001 auf Basis von IT-Grundschutz als probates Mittel anerkannt, um die Anforderungen der Wirtschaftsprüfung in diesem Bereich zu erfüllen. Sollte das geprüfte Unternehmen sogar eine Zertifizierung vorweisen, so kann eine etwaige Prüfung in einem Minimalumfang erfolgen. Diese Informationen stellen für den Wirtschaftprüfer eine enorme Hilfestellung und Erleichterung dar.
59
4 4 Relevante Prüfungsgrundlagen Dieses Kapitel soll Ihnen einen Überblick über die für Sie als IT-Revisor wichtigen Prüfungsgrundlagen geben, zu denen Gesetze, Richtlinien und Branchenvorschriften zählen. Als Prüfungsgrundlagen stellen diese Vorschriften Anforderungen an Ihre tägliche Arbeit, die sich im zweiten Teil dieses Handbuches, den GoIT, wiederfinden.
4.1
Prüfungsgrundlagen für die IT-Revision Um eine zielgerichtete Prüfung durchzuführen, so wie sie in Kapitel 2 beschrieben wird, müssen Sie zunächst Ihr Prüfobjekt bestimmen und dann feststellen, welche internen und externen Anforderungen es dafür gibt. Anforderungen an Ihr Prüfungsobjekt können aus Gesetzen, Richtlinien, und Branchenvorschriften entstehen (siehe Abbildung 4.1 auf der nächsten Seite): Gesetze: Ein Gesetz ist eine Sammlung von allgemein verbindlichen Rechtsnormen, die in einem förmlichen Verfahren von dem dazu ermächtigten staatlichen Organ, dem Gesetzgeber, erlassen worden ist. Richtlinien: Eine Richtlinie ist eine Handlungsvorschrift mit bindendem Charakter, aber nicht gesetzlicher Natur. Eine Richtlinie wird von einer Organisation ausgegeben, ist daher gesetzlich ermächtigt und hat so einen Geltungsbereich, der z.B. arbeitsrechtlich auch sanktionierbar ist. (Branchen-)Vorschrift: Eine (Branchen-)Vorschrift ist eine verbindliche Anweisung, Anordnung bzw. Verfügung, die durch bestimmte Organisationen innerhalb der Branchen definiert worden ist (z.B. Dachverband). Anforderungen, die sich aus diesen Quellen ergeben, sind die Prüfungsgrundlage. Um den Aufwand einer Prüfung in einem praktikablen Umfang zu halten, gilt der Grundsatz: Ich kann nur das prüfen, was vorgeschrieben ist! Doch wie unterscheiden sich die Begriffliche „Anforderung“ und „Prüfungsgrundlage“?
61
4 Relevante Prüfungsgrundlagen Prüfungsgrundlagen werden aus den Vorschriften extrahiert, indem Sie die für Ihr Unternehmen relevanten Teilbereiche herausgreifen. Dies gilt sowohl für externe Prüfungsgrundlagen als auch für interne. Anforderungen sind einzelne Bestimmungen innerhalb einer Prüfungsgrundlage, diese lassen Sie in die Prüfungsvorbereitung mit einfließen. Beispiel
Sie sollen eine Prüfung eines IT-Systems durchführen, auf dem personenbezogene Daten verarbeitet werden. Welche Prüfungsgrundlage gibt es? Welche Anforderungen erwachsen daraus? Die Prüfungsgrundlage ist das Bundesdatenschutzgesetz (BDSG) mit den entsprechenden Paragraphen. Die Anforderungen sind in den Paragraphen enthalten (z.B. Anforderungen an die Zutrittskontrolle).
Vorschriften
Prüfungsgrundlage
Anforderungen
• Gesetze • Richtlinien • Branchenvorschriften
• Für das Prüfungsobjekt festgestellte Vorschriften
• In den Prüfungsgrundlagen enthaltene Anforderungen an die IT Abbildung 4.1 Relevante Prüfungsgrundlagen
Abbildung 4.1 zeigt den allgemeinen Weg, wie Sie von den Vorschriften über die Prüfungsgrundlagen zu den Anforderungen kommen. In diesem Kapitel werden die wichtigsten Vorschriften vorgestellt, die in den meisten Unternehmen Anwendung finden. Im Einzelfall können diese Vorschriften nicht ausreichen, um eine für Ihr Unternehmen rechtlich konforme Betrachtung durchzuführen. Sollten Sie besonderen Vorschriften unterliegen, so müssen Sie natürlich auch diese beachten und die Anforderungen daraus nach dem oben beschriebenen Vorgehen extrahieren.
4.2
Gesetze Es gibt eine Reihe von Gesetzen, die für die IT-Revision von erheblicher Bedeutung sind. Damit Sie feststellen können, welche der Gesetze als Anforderung in die Vorbereitung und später auch in die Prüfung einfließen, finden Sie hier die wichtigsten Gesetze:
62
4.2 Gesetze Handelsgesetzbuch (HGB) Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) Bundesdatenschutzgesetz (BDSG) GmbH Gesetz (GmbHG) Aktiengesetz (AktG) Sarbanes-Oxley Act (SOX) Telemediengesetz (TMG) Bevor wir uns damit beschäftigen, wie aus diesen Gesetzen die Anforderungen für die Prüfung extrahiert werden, werden sie nach folgendem Aufbau kurz beleuchtet: Allgemeine Beschreibung: Es wird eine kurze Erläuterung des Gesetzes gegeben. Relevante Inhalte für die IT-Revision: Da es sich bei den Gesetzen um allgemeine Anforderungen handelt, werden hier die für Ihre Arbeit relevanten Teile erwähnt. Anforderungen: Hier werden die Anforderungen beschrieben, die sich aus den relevanten Teilen ergeben, und zwar kategorisiert nach: Verfügbarkeit Integrität Vertraulichkeit Verbindlichkeit Verweise auf andere Gesetze: Viele Gesetze korrespondieren miteinander, d h. Anforderungen ergeben sich aus den einzelnen Gesetzen und können dann in anderen Gesetzen konkretisiert werden. In diesem Punkt wird der Zusammenhang bzw. die Abhängigkeit zwischen den Gesetzen erläutert. Dazu zwei Beispiele: KonTraG ist ein Artikelgesetz, das auf die jeweiligen Paragraphen im AktG verweist. Die Anforderungen des HGB werden in den „Grundsätze ordnungsmäßiger Buchführung (GoB)“ bzw. „Grundsätze ordnungsmäßiger Buchführungs-Systeme (GoBS)“ konkretisiert.
4.2.1
Handelsgesetzbuch (HGB)
4.2.1.1
Beschreibung
Das Handelsgesetzbuch ist die zentrale Vorschrift für das Handelsrecht in Deutschland. Es enthält sowohl Regelungen für Gesellschaftsformen als auch für Handelsgeschäfte und die Führung der relevanten Handelsbücher. 4.2.1.2
Relevante Inhalte für die IT-Revision
§ 239 Führung der Handelsbücher (1) Bei der Führung der Handelsbücher und bei den sonst erforderlichen Aufzeichnungen hat sich der Kaufmann einer lebenden Sprache zu bedienen. Werden Abkürzungen,
63
4 Relevante Prüfungsgrundlagen Ziffern, Buchstaben oder Symbole verwendet, muss im Einzelfall deren Bedeutung eindeutig feststehen. (2) Die Eintragungen in Büchern und die sonst erforderlichen Aufzeichnungen müssen vollständig, richtig, zeitgerecht und geordnet vorgenommen werden. (3) Eine Eintragung oder eine Aufzeichnung darf nicht in einer Weise verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist. Auch solche Veränderungen dürfen nicht vorgenommen werden, deren Beschaffenheit es ungewiss lässt, ob sie ursprünglich oder erst später gemacht worden sind. (4) Die Handelsbücher und die sonst erforderlichen Aufzeichnungen können auch in der geordneten Ablage von Belegen bestehen oder auf Datenträgern geführt werden, soweit diese Formen der Buchführung einschließlich des dabei angewandten Verfahrens den Grundsätzen ordnungsmäßiger Buchführung entsprechen. Bei der Führung der Handelsbücher und der sonst erforderlichen Aufzeichnungen auf Datenträgern muss insbesondere sichergestellt sein, dass die Daten während der Dauer der Aufbewahrungsfrist verfügbar sind und jederzeit innerhalb angemessener Frist lesbar gemacht werden können. Absätze 1 bis 3 gelten sinngemäß. 4.2.1.3
Anforderungen
In § 239 HGB sind Anforderungen definiert, die sich auf drei Teilbereiche eingrenzen lassen: Verfügbarkeit, Integrität und Ordnungsmäßigkeit (siehe Abbildung 4.2)
Verfügbarkeit § 239 Abs. 4
§ 239 HGB Integrität § 239 Abs. 3
Ordnungsmäßigkeit § 239 Abs. 2
Abbildung 4.2 Anforderungen des §239 HGB
Verfügbarkeit Die Verfügbarkeit der geführten Handelsbücher und der geschäftlichen Unterlagen muss sichergestellt sein. Dies hat mittlerweile auch Auswirkungen auf den ganzen Bereich der E-Mail-Archivierung. Bei einer Prüfung durch die Finanzbehörden sind die Daten in angemessener Zeit wieder herzustellen. Dies sollten Sie bei der Prüfung der Sicherungsverfahren beachten.
64
4.2 Gesetze Praxistipp
Ein Großteil der geschäftlichen Unterlagen wird mittlerweile elektronisch in Dokumentenmanagementsystemen und anderen IT-Systemen geführt. Sofern ein Notfallkonzept für diese Systeme existiert, lassen sich die Daten über die mögliche Wiederherstellungszeit in der Regel diesem Konzept entnehmen.
Integrität So wie man in der „alten“ Buchhaltung keine Veränderung der Buchungen vornehmen durfte, die nicht nachvollziehbar war, so gilt dies auch für Buchhaltungssysteme und Daten von heute. Auch die gespeicherten oder archivierten Daten dürfen nicht verändert werden. Hierzu müssen geeignete Prozesse etabliert sein. Verbindlichkeit „Die Eintragungen in Büchern und die sonst erforderlichen Aufzeichnungen müssen vollständig, richtig, zeitgerecht und geordnet vorgenommen werden.“ Die Eintragungen müssen demnach verbindlich die in der Realität angefallenen Geschäftsvorfälle abbilden. Praxistipp
Unabhängig von der Größe des Unternehmens sind heute für die Buchführung ITgestützte Buchhaltungssysteme im Einsatz. In Bezug auf die Verbindlichkeit ist im verwendeten Buchhaltungssystem die geordnete Abfolge von Geschäftsvorfällen zu überprüfen. In enger Verbindung damit steht die Authentizität, für die die Überprüfung der Benutzerrechte wichtig ist.
Besondere Anforderung Innerhalb einer Buchhaltung müssen Abkürzungen und Symbole eindeutig festgelegt werden. Dazu existiert meist ein Glossar, in dem alle Begriffe, Abkürzungen und Symbole definiert werden, die nicht selbsterklärend sind bzw. deren Bedeutung von einem fachkundigen Dritten nicht ohne Weiteres erschlossen werden kann. 4.2.1.4
Verweis auf andere Gesetze, Bestimmungen, Richtlinien, Branchenvorschriften
Das HGB bestimmt (als Gesetz) einen Teil der Grundsätze ordnungsmäßiger Buchführung und damit auch die Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS) (siehe Abbildung 4.3).
HGB
Grundsätze ordnungsmäßiger Buchführung GoB Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme GoBS
Abbildung 4.3 Verweise des HGB
65
4 Relevante Prüfungsgrundlagen
4.2.2
Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG)
4.2.2.1
Beschreibung
Das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) wurde am 5. März 1998 vom Deutschen Bundestag verabschiedet und trat am 1. Mai 1998 in Kraft. Das Gesetz beschreibt Änderungen und Ergänzungen des Handelsgesetzbuches (HGB) und des Aktiengesetzes (AktG), durch die die Corporate Governance in deutschen Unternehmen erhöht werden sollte. Diese „gute Führung“ (Governance) wird durch die Forderung nach einem unternehmensweitem Risikofrüherkennungs- und Überwachungssystem gewährleistet. Ebenfalls müssen Aussagen zu potenziellen Risiken und Aussagen zur Risikostruktur des Unternehmens im Lagebericht des Jahresabschlusses präsentiert werden (vgl. [Nörr2005], S. 5). 4.2.2.2
Relevant für die IT-Revision
Der §91 AktG wurde im KonTraG um den folgenden Absatz 2 erweitert, der für die ITRevision relevant ist: „Der Vorstand hat geeignete Maßnahmen zu treffen, insbesondere ein Überwachungssystem einzurichten, damit den Fortbestand der Gesellschaft gefährdende Entwicklungen früh erkannt werden.“ 4.2.2.3
Anforderungen
Durch die Implementierung eines Risikofrüherkennungs- und -überwachungssystem (RfÜ) ergeben sich für die Revision zwei Ansätze: 1. Prüfung des RfÜ-Systems, wenn es durch IT-Anwendungen unterstützt wird. Häufig werden für die Organisation und die Berichtserstellung des RfÜ-Systems Anwendungen als Unterstützung implementiert. Hier ist insbesondere auf die Integrität der Anwendungen und die Eignung zur Abbildung des RfÜ sowie auf das Rechte- und Rollenkonzept zu achten. 2. IT-Revision als Teil des RfÜ-Systems Durch ihre Arbeit kann die IT-Revision mögliche Risiken für den Unternehmensfortbestand schon einer ersten Beurteilung unterziehen. Damit kann die IT-Revision als eine sehr qualifizierte Grundlage für das geforderte Risikofrüherkennungssystem1 gesehen werden.
1
66
Hier ist System nicht als IT-System zu verstehen, sondern als Prozess.
4.2 Gesetze 4.2.2.4
Verweis auf andere Gesetze, Bestimmungen, Richtlinien, Branchenvorschriften
Das KonTraG ist ein Artikelgesetz und damit eine Änderung und Ergänzung mehrerer vorhandener Gesetze. Es hat bei seiner Verabschiedung auf andere Gesetze Einfluss genommen (siehe Abbildung 4.4).
KonTraG
HGB
AktG Abbildung 4.4 Verweise des KonTraG
4.2.3
Bundesdatenschutzgesetz BDSG
4.2.3.1
Beschreibung
Das Bundesdatenschutzgesetz (BDSG) trat am 1. Januar 1978 in Kraft. Das Gesetz wird ständig aktualisiert. Unter anderem wurden Regelungen, die die automatisierte Verarbeitung von personenbezogenen Daten berücksichtigen, in das Gesetz integriert. 4.2.3.2
Relevante Inhalte für die IT-Revision
Das BDSG definiert als Ziel in §1 Abs. 1: „Zweck dieses Gesetzes ist es, den Einzelnen davor zu schützen, dass er durch den Umgang mit seinen personenbezogenen Daten in seinem Persönlichkeitsrecht beeinträchtigt wird.“ ([BDSG]) Dieses Ziel wird im § 9 durch die im Unternehmen umzusetzenden Maßnahmen erreicht. Diese stellen direkte Anforderungen z.B. an die Informationstechnik und deren Organisation. 4.2.3.3
Anforderungen
Die Anforderungen an eine Prüfung der Konformität mit dem Bundesdatenschutzgesetz finden sich im §9 des BDSG. Danach sind bei der Verarbeitung von personenbezogenen Daten folgende Kontrollen umzusetzen: Zutritts- und Zugangskontrollen Sicherstellen, dass nur befugte Personen Zutritt zu Gebäuden, Räumen und IT-Systemen mit personenbezogenen Daten erhalten. Datenschutzrelevante IT-Systeme dürfen nur befugten Personen zugänglich sein und nur von ihnen genutzt werden können. Datenträgerkontrollen Überwachung des Lebenszyklus von Datenträgern, d h. ob die Anforderungen an die Speicherung von personenbezogenen Daten bei der Initialisierung, der Aufbewahrung, der Verwendung und der Entsorgung der Datenträger erfüllt werden.
67
4 Relevante Prüfungsgrundlagen Speicherkontrollen Sicherstellen, dass nur für den Geschäftszweck benötigte personenbezogene Daten gespeichert werden (Prinzip der Datenminimierung), dass die Daten korrekt gespeichert werden (Prinzip der Datenrichtigkeit und Datenkonsistenz) und erforderliche Auskünfte zu den Daten zeitnah erteilt werden können (Prinzip der Datentransparenz2). Gespeicherte personenbezogene Daten dürfen nicht zufällig gelöscht werden und müssen vor Verlust (z.B. aufgrund von technischen Defekten) geschützt werden. Zugriffskontrollen Beschränkung des Zugriffs in datenschutzrelevanten IT-Systemen, sodass Personen nur auf die Daten zugreifen können, für die sie berechtigt wurden. Weitergabekontrollen Es muss nachvollziehbar sein, an welche Stellen welche Daten weitergegeben wurden bzw. falls noch keine Daten weitergegeben wurden, an welche Stellen eine Weitergabe vorgesehen ist. Übermittlungs- bzw. Transportkontrollen Übermittelte bzw. transportierte3 personenbezogene Daten dürfen während der Übermittlung oder des Transports nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können. Benutzer- und Organisationskontrollen Es muss eindeutig nachvollziehbar sein, von wem welche personenbezogenen Daten eingegeben, geändert oder gelöscht wurden. Werden personenbezogene Daten im Auftrag einer anderen Stelle verarbeitet, so muss gewährleistet sein, dass die Benutzer die Daten nicht anders als beauftragt verarbeiten können. 4.2.3.4
Verweis auf andere Gesetze, Bestimmungen, Richtlinien, Branchenvorschriften
Das Bundesdatenschutzgesetz verweist auf keine weiteren Gesetze, jedoch sind die Anforderungen des §9 BDSG durch den Bundesbeauftragten für den Datenschutz konkretisiert worden. Dies ist im Baustein 1.5 der IT-Grundschutz-Kataloge4 des Bundesamtes für Sicherheit in der Informationstechnik erfolgt.
68
2
Beispielsweise muss ohne größeren Aufwand eindeutig abrufbar sein, welcher Identität welche Daten zugeordnet sind.
3
Hier wird zwischen Übermittlung und Transport unterschieden. Bei einer Übermittlung oder Übertragung werden die Daten direkt über IT-Netzwerke versendet, bei einem Transport werden die Daten offline auf einem Datenträger transportiert.
4
Die IT-Grundschutz-Kataloge können Sie kostenfrei auf den Seiten des Bundesamts für Sicherheit in der Informationstechnik unter www.bsi.bund.de/ herunterladen.
4.2 Gesetze
4.2.4
Telemediengesetz (TMG)
4.2.4.1
Beschreibung
Das Telemediengesetz (TMG) hat die drei Regelwerke Teledienstgesetz (TDG), Teledienstdatenschutzgesetz (TDDSG) und Mediendienste-Staatsvertrag (MdStV) weitgehend zusammengefasst und diese Regelwerke mit dem Inkrafttreten am 1. März 2007 abgelöst. Die bis dahin geltenden Vorschriften sind nahezu gleich geblieben und gelten für alle elektronischen Informations- und Kommunikationsdienste. 4.2.4.2
Relevante Inhalte für die IT-Revision
Insbesondere TMG §7 weist auf die Verpflichtungen des Dienstanbieters (also die natürliche oder juristische Person, die den Zugang zur Nutzung vermittelt) hin, „die von ihnen übermittelten oder gespeicherten Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tat hinweisen“ ([TMG]). Das TMG unterscheidet explizit zwischen Nutzungs- und Bestandsdaten. Als Nutzungsdaten werden die personenbezogenen Daten eines Nutzers bezeichnet, die erforderlich sind, „um die Inanspruchnahme von Telemedien zu ermöglichen und abzurechnen“ ([TMG]), während die Bestandsdaten die personenbezogenen Daten sind, die „für die Begründung, inhaltliche Ausgestaltung oder Änderung eines Vertragsverhältnisses zwischen dem Diensteanbieter und Nutzer über die Nutzung von Telemedien erforderlich sind“ ([TMG]). Diese Bestandsdaten könnten im Sinne einer Rechtsverfolgung durch die zuständigen Behörden angefordert werden. Abrechnungsdaten, d h. Daten, die erhoben werden, um die Abrechnung mit dem Nutzer durchführen zu können, dürfen „höchstens bis zum Ablauf des sechsten Monats nach Versendung der Rechnung“ ([TMG]) gespeichert werden. Nur in Sonderfällen (der Benutzer zahlt nicht für die in Anspruch genommenen Dienste oder gerät ins Visier einer Rechtsverfolgung) dürfen diese Daten länger gespeichert werden. Das TMG legt in §16 fest, wann sich der Diensteanbieter ordnungswidrig verhält. Die Erhebung personenbezogener Daten wird ausschließlich im Sinne der oben definierten Nutzungs- und Bestandsdaten erlaubt. Werden diese nicht rechtzeitig gelöscht oder zu einem anderen Zweck erhoben, führt dies zu ordnungswidrigem Verhalten und kann mit einer Geldbuße von bis zu 50.000 € geahndet werden.
69
4 Relevante Prüfungsgrundlagen 4.2.4.3
Anforderungen
Das TMG beschreibt einige Anforderungen, die für die IT-Revision von Bedeutung sind: Beweissicherung, Überprüfungsaufgaben und Meldepflichten. Eine besondere Anforderung, die durch das TMG gefordert wird, sind die maximalen Aufbewahrungsfristen. Somit sind innerhalb der Organisation des Diensteanbieters auch Prozesse zu prüfen, die eine Vernichtung von Daten ab einem bestimmten Datum vornehmen. 4.2.4.4
Verweis auf andere Gesetze, Bestimmungen, Richtlinien, Branchenvorschriften
Es gibt keinen prüfungsrelevanten Verweis auf Gesetze, Bestimmungen, Richtlinien oder Branchenvorschriften.
4.2.5
SOX
4.2.5.1
Beschreibung
Dieses US-Bundesgesetz wurde als Reaktion auf die Bilanzskandale von US-amerikanischen Firmen wie Enron und Microwave Communications, Inc. (MCI) Worldcom verabschiedet. Das Ziel war die Verbesserung der Berichterstattung von Unternehmen, die an den nationalen Kapitalmärkten gehandelt werden. Dieses Gesetz gilt auch für ausländische Unternehmen, die an der US-Börse notiert und ausländische Tochtergesellschaften amerikanischer Unternehmen sind. 4.2.5.2
Relevante Inhalte für die IT-Revision
Relevant ist die Section 4045 von SOX. Sie beschreibt die Implementierung eines internen Kontrollsystems (IKS). 4.2.5.3
Anforderungen
Ähnlich wie bei KonTraG entstehen hier zwei Ansätze für die IT-Revision: 1. Prüfung des IKS, wenn es durch IT-Anwendungen unterstützt wird. Häufig werden für die Organisation und die Berichtserstellung Anwendungen als Unterstützung implementiert. Hier ist insbesondere auf die Integrität der Anwendungen und die Eignung als IKS und auf das Rechte- und Rollenkonzept zu achten. Insbesondere muss der Teil des sog. Whistleblowings (Meldemöglichkeiten bei Unstimmigkeiten) betrachtet werden.
5
70
Das Gesetz ist unter http://www.sec.gov/about/laws/soa2002.pdf frei erhältlich.
4.3 Richtlinien für die IT-Revision 2. IT-Revision als Teil des IKS Die Ergebnisse einer risikoorientierten IT-Revision können als eine sehr qualifizierte Grundlage für das geforderte IKS gesehen werden. Die Ergebnisse, z.B. bei der Überprüfung der Benutzerrechtevergabe eines ERP6-Systems, können Hinweise auf Betrug liefern. 4.2.5.4
Verweis auf andere Gesetze, Bestimmungen, Richtlinien, Branchenvorschriften
Es gibt keinen prüfungsrelevanten Verweis auf Gesetze, Bestimmungen, Richtlinien oder Branchenvorschriften.
4.3
Richtlinien für die IT-Revision 4.3.1
Allgemein
Richtlinien sind Handlungsvorschriften mit bindendem Charakter, die im Gegensatz zu Gesetzen nicht vom Staat, sondern von einer Organisation (Verbänden, EU etc.) ausgegeben werden. Sie besitzen einen Geltungsbereich und sind sanktionierbar, sobald sie veröffentlicht sind. Dies bedeutet, dass bei einem Verstoß gegen eine Richtlinie mit Sanktionen zu rechnen ist. Ein Beispiel: Verstößt ein Mitarbeiter gegen eine Konzernrichtlinie, kann dies arbeitsrechtliche Folgen nach sich ziehen. Im Folgenden beschreiben wir einige Richtlinien, die für die IT-Revision generell relevant sind. Die Beschreibung folgt diesem Schema: Allgemeine Beschreibung: Es wird eine kurze Erläuterung der Richtlinien gegeben. Relevante Inhalte für die IT-Revision: Da es sich bei den Richtlinien um allgemeine Anforderungen handelt, sind hier die für Ihre Arbeit relevanten Teile erwähnt. Anforderungen: Hier werden die Anforderungen beschrieben, die sich aus den relevanten Teilen ergeben, und zwar kategorisiert nach: Verfügbarkeit Integrität Vertraulichkeit Verbindlichkeit
6
Enterprise Resource Planning
71
4 Relevante Prüfungsgrundlagen
4.3.2
Verlautbarungen des IDW
4.3.2.1
Beschreibung
Der größte Teil aller mit der Wirtschaftsprüfung betrauten Personen und Gesellschaften hat sich im Institut für Wirtschaftsprüfer in Deutschland e.V. (IDW) zusammengeschlossen. Das IDW veröffentlicht Richtlinien über seinen eigenen Verlag. Über dessen Webshop7 können Sie die aktuellen Richtlinien und Verlautbarungen zum Thema IT-Revision beziehen. Die Verlautbarungen des IDW stellen die Richtlinien der Wirtschaftsprüfer dar. Diese sind wie folgt strukturiert: IDW Prüfungsstandards (IDW PS) IDW Stellungnahmen zur Rechnungslegung (IDW RS) IDW Standards (IDW S) IDW Prüfungshinweise (IDW PH) IDW Rechnungslegungshinweise (IDW RH) IDW Verlautbarungen bis 1998 Gemeinsame Stellungnahmen mit der WPK Sonstige Verlautbarungen/Eingaben Mit den Verlautbarungen sollen die Wirtschaftsprüfer in die Lage versetzt werden, unbeschadet ihrer Eigenverantwortlichkeit (WPO8) ihrer Tätigkeit nachzugehen. Viele der Verlautbarungen behandeln die Prüfung der Abschlüsse von Wirtschaftsunternehmen. Einige sind jedoch relevant für die IT. Hierbei sind insbesondere die Buchungs- und Rechnungslegungssysteme gemeint. Der Bereich der Dokumentenarchivierung wird in Kapitel 6 ausführlicher behandelt. 4.3.2.2
Relevant für die IT-Revision
Das IDW hat für den Bereich der IT-Prüfung mehrere Verlautbarungen veröffentlicht. Diese Veröffentlichungen gliedern sich in drei Gruppen: Stellungnahmen zur Rechnungslegung Grundsätze ordnungsmäßiger Buchführung bei Einsatz von Informationstechnologie (IDW RS FAIT1) Grundsätze ordnungsmäßiger Buchführung bei Einsatz von Electronic Commerce (IDW RS FAIT 2) Grundsätze ordnungsmäßiger Buchführung beim Einsatz elektronischer Archivierungsverfahren (IDW RS FAIT 3)
7 8
72
http://shop.idw-verlag.de/welcome.idw WPO ist die Wirtschaftsprüfungsordnung, die die Arbeit der Wirtschaftsprüfer regelt. Auf sie wird in Kapitel 3 näher eingegangen.
4.3 Richtlinien für die IT-Revision Prüfungsstandards Abschlussprüfung bei Einsatz von Informationstechnologie (IDW PS 330) Projektbegleitende Prüfung bei Einsatz von Informationstechnologie (IDW PS 850) Erteilung und Verwendung von Software-Bescheinigungen (IDW PS 880) Prüfungshinweise Checkliste zur Abschlussprüfung bei Einsatz von Informationstechnologie (IDW PH9.330.1) 4.3.2.3
Anforderungen
Alle Anforderungen an die IT-Revision hier aufzuführen, würde den Rahmen des Kapitels sprengen. Darauf wird in Kapitel 3 und 6 ausführlicher eingegangen. Zusammenfassend ist zu erklären: „Die Beurteilung der Ordnungsmäßigkeit der Rechnungslegung im Rahmen der Abschlussprüfung schließt eine Beurteilung des IT-gestützten Rechnungslegungssystems ein.“ 9
4.3.3
GDPdU
4.3.3.1
Beschreibung
Die „Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen“ (GDPdU() sind Verwaltungsanweisungen innerhalb des Steuerrechts, die die Aufbewahrung digitaler Unterlagen und die Mitwirkungspflicht der Steuerpflichtigen bei Betriebsprüfungen regeln. 4.3.3.2
Relevant für die IT-Revision
Insbesondere fordern die GDPdU die qualifizierte elektronische Signatur bei Rechnungen, eine Speicherung der Rechnungen auf Datenträgern, die eine nachträgliche Änderung verhindern, sowie eine Protokollierung des Vorgangs. Des Weiteren ist die Verfügbarkeit der Protokolldaten sowie der Originaldaten zu gewährleisten. Somit sind alle Daten und Prozesse, die digitale Unterlagen der Rechungslegung erstellen, relevant für die IT-Revision. Dazu gehören insbesondere Archivsysteme. Diese werden in Kapitel 6 vorgestellt. 4.3.3.3
Anforderungen
Die Anforderungen der GDPdU an die Aufbewahrung von Rechnungen im Sinne des UStG („elektronische Abrechnungen“) sind unter anderem: Die Rechnung muss eine qualifizierte elektronische Signatur tragen (Faksimileunterschriften reichen nicht aus).
9
aus einer Präsentation des IDW.
73
4 Relevante Prüfungsgrundlagen Der Empfänger muss die Signatur im Hinblick auf die Integrität der Daten und die Signaturberechtigung prüfen und das Ergebnis dokumentieren. Der Empfänger muss die Rechnung auf einem Datenträger speichern, der Änderungen nicht mehr zulässt. Der Empfänger muss den Eingang der Rechnung, ihre Konvertierung sowie die weitere Verarbeitung und Archivierung protokollieren. Der Empfänger muss sicherstellen, dass die Übertragungs-, Archivierungs- und Konvertierungssysteme den GoBS entsprechen. Ähnliche Anforderungen gelten für die Aufbewahrung sonstiger aufbewahrungspflichtiger digitaler Unterlagen.
4.3.4
GoBS
4.3.4.1
Beschreibung
Eng verknüpft mit den GDPdU sind die GoBS (Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme) zu sehen. Das Bundesministerium der Finanzen hat dieses Schreiben an die obersten Finanzbehörden der Länder am 7. November 1995 veröffentlicht. Die GDPdU berufen sich auf die GoBS, die Vorschriften zur ordnungsgemäßen Behandlung elektronischer Dokumente beinhalten. 4.3.4.2
Relevante Inhalte für die IT-Revision
Generell stellen die GoBS die gleichen Prinzipien an die DV-gestützte Buchführung, wie sie für eine manuell erstellte Buchführung gelten. Es erfolgt eine Präzisierung der allgemeinen Prinzipien für den Bereich der DV-gestützten Buchführung. Somit sind die GoBS als Gesamtheit relevant für die Arbeit des IT-Revisors. 4.3.4.3
Anforderungen
Anforderungen im Bereich der GoBS sind in die folgenden Gruppen unterteilt: Beleg-, Journal- und Kontenfunktionen Buchungen Internes Kontrollsystem Datensicherheit Dokumentation und Prüfbarkeit Aufbewahrungsfristen Wiedergabe der auf Datenträgern geführten Unterlagen Eine Hauptanforderung ist es, die digitalen Unterlagen so zu verarbeiten und aufzubewahren, dass sie retrograden und progressiven Prüfungen standhalten. Innerhalb der Prüfungsmethoden werden nach dem Kriterium „Richtung des Vorgehens“ (Prüfungsrichtung) retrograde und progressive Prüfungen unterschieden.
74
4.3 Richtlinien für die IT-Revision Retrograde Prüfung Schritt
Beispiel
GuV Bilanz
Elektronischer Abschluss auf Datenträger
Konten
Konten innerhalb des Buchführungssystems
Grundaufzeichunng
Einkaufsbeleg
Phase
Urbeleg
Kassenbuch
Abbildung 4.5 Retrograde Prüfung
Progressive Prüfung Schritt
Beispiel
Urbeleg
Einkaufsbeleg
Grundaufzeichnung
Konten
Phase
Bilanz GuV
Kassenbuch
Konten innerhalb des Buchführungssystems Elektronischer Abschluss auf Datenträger
Abbildung 4.6 Progressive Prüfung
Bei der retrograden Prüfung (siehe Abbildung 4.5) wird ein Vorgang in der entgegengesetzten Reihenfolge seines chronologischen Ablaufs, d. h. rückwärtsschreitend von seiner Erfassung im Rechnungswesen bis zum wirtschaftlichen Tatbestand geprüft (Bilanz oder GuV > Hauptbuch > Grundbuch > Beleg > Wareneingang). Voraussetzung für die Anwen-
75
4 Relevante Prüfungsgrundlagen dung der retrograden Prüfung ist die Verkettung von Vorgängen. Die Urteilsbildung erfolgt, indem von einem Teilurteil auf ein anderes Teilurteil geschlossen wird. Bei der progressiven Methode (siehe Abbildung 4.6) wird ein Vorgang dagegen in der Reihenfolge seines chronologischen Ablaufs geprüft, d h. fortschreitend vom wirtschaftlichen Tatbestand bis zum zahlenmäßigen Erfassen im Rechnungswesen (Wareneingang > Beleg > Grundbuch > Hauptbuch > Bilanz oder GuV).
4.4
Branchenvorschriften Die vorherigen Abschnitte haben einen Überblick über die relevanten Gesetze und allgemeine Richtlinien gegeben. In einigen Branchen gelten zusätzliche Vorschriften, um deren erhöhten Anforderungen an die Sicherheit gerecht zu werden. Als Beispiel sind hier direkte oder indirekte Gefahren für Leib und Leben von Menschen zu nennen10. Tabelle 4.1 zeigt beispielhaft einige solcher Branchenvorschriften. Tabelle 4.1 Branchenvorschriften Branche
Vorschrift
Banken, Versicherungen
Basel II, MaRisk Solvency II
Automotive
ISO/TS 16949
Pharmazie, Chemie Lebensmittel
GMP, GAMP 4
Von den in Tabelle 4.1 genannten Branchenvorschriften soll auf Basel II, MaRisk und Solvency II etwas näher eingegangen werden, denn eine Bewertung der Banken von Krediten nach Basel II nimmt direkten Einfluss auf die Vergabe von Krediten an Unternehmen. Man muss diese Äußerung jedoch zurzeit mit Vorsicht genießen, denn besonders Banken im Mittelstand nehmen die IT als operationelles Risiko kaum wahr. Als operationelles Risiko werden eher nicht vorhandene Notfallpläne für das Ausscheiden von Managern oder nicht umgesetzte Maßnahmen zur Nachfolgesicherung gesehen. Dies soll aber nicht heißen, dass in naher Zukunft eine Betrachtung der IT-Risiken nicht doch noch Folgen für die Bewertung von Unternehmen hat.
4.4.1
Basel II
4.4.1.1
Beschreibung
Basel II umfasst eine neue Regelung des Bankaufsichtsrechts mit dem sekundären Ziel, Insolvenzen durch Kreditausfälle zu verhindern, um primär das internationale Finanzsystem zu sichern. In einer im Jahr 2006 durchgeführten Studie wurde festgestellt, dass für
10
76
Häufig findet sich bei Gefahren für Leib und Leben nicht der Begriff Security, sondern Safety, um deutlich zu machen, dass es sich um Gefährdungen von Personen handelt.
4.4 Branchenvorschriften über 45 % der deutschen Unternehmen die Regelungen von Basel II relevant sind11. Aus Sicht der IT-Sicherheit ist die Evaluierung des Kreditnehmers von Bedeutung, denn neben Kredit- und Marktrisiko wird mit der Einführung von Basel II das operationelle Risiko geschätzt. Operationelles Risiko
Das operationelle Risiko wird als Obermenge aller Risiken gesehen, die einem Unternehmen im betrieblichen Ablauf schaden können.
4.4.1.2
Relevante Inhalte für die IT-Revision
Da Basel II auch Schwachstellen der IT zu den operationellen Risiken zählt, sind diesen mit geeigneten Maßnahmen zu begegnen. Somit sind alle Belange der betrieblichen IT relevant für die IT-Revision im Sinne von Basel II. 4.4.1.3
Anforderungen
Aus dieser Vorschrift ergibt sich an die IT die simple Anforderung der Risikobehandlung. Diese so „simple“ Anforderung stellt sich in der Umsetzung der resultierenden Maßnahmen als immens umfangreich dar. So ist ein geeignetes Risikomanagement einzuführen, das im IT-Bereich in der Implementierung eines sogenannten ISMS (Information Security Management System) bestehen kann. Grundlage für das ISMS können nationale und internationale Standards wie die ISO 2700x-Reihe oder das Vorgehen des Bundesamtes für Sicherheit in der Informationstechnik (ISO 27001 auf Basis von IT-Grundschutz) ein. Die Prüfung eines ISMS am Beispiel des Vorgehens des Bundesamtes für Sicherheit in der Informationstechnik wird in Kapitel 6 näher erläutert.
4.4.2
MaRisk (Mindestanforderungen an das Risikomanagement)
4.4.2.1
Beschreibung
Die MaRisk12 werden von der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) für die Ausgestaltung des Risikomanagements in deutschen Kreditinstituten vorgegeben und wurden am 20. Dezember 2005 in Kraft gesetzt. Eine Aktualisierung der Anforderungen erfolgte mit der Einführung von Basel II. 4.4.2.2
Relevante Inhalte für die IT-Revision
MaRisk ist modular aufgebaut, der allgemeine Teil (AT) befasst sich mit grundlegenden Prinzipien, der besondere Teil (BT) formuliert spezifische Anforderungen.
11 12
Vgl.
/Microsoft (2006b), S. 13. http://www.bundesbank.de/download/bankenaufsicht/pdf/marisk/090814_rs.pdf
77
4 Relevante Prüfungsgrundlagen 4.4.2.3
Anforderungen
Im MaRisk-Modul AT7 werden konkrete Anforderungen an die technisch-organisatorische Ausstattung und an die Notfallvorsorge formuliert, die sich an gängigen Standards wie ITGrundschutz oder International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 27002:2005 orientieren sollen.
4.4.3
Solvency II
Ähnlich wie Basel II für Banken hat die Europäische Kommission für Versicherungen Richtlinien festgelegt. Die Versicherungsgesellschaften sind gehalten, ab dem 1.1.2010 diese Richtlinien umzusetzen. Darin werden die Versicherungsunternehmen dazu verpflichtet, Solvenzkapital in ausreichendem Maße bereitzuhalten. Im Rahmen von Solvency II ist dieses Solvenzkapital „an die vom Versicherer getragenen Risiken anzupassen. Dessen Risikobewertung erfolgt wiederum in Bezug auf das zu versichernde Unternehmen, bei dem – etwa bei den ITVersicherungen, aber gerade auch den Betriebsunterbrechungs- oder Betriebshaftpflichtversicherungen – die operationellen (IT-)Risiken von großer Bedeutung sind.“13 Der Versicherungsbetrag wird insofern an eine vom Versicherungsnehmer vorzuweisende Risikoanalyse und so an die damit verbundenen Maßnahmen angepasst. Auf eine weitere Ausführung wird hier verzichtet, da die Anforderungen für die IT-Revision genauso zu behandeln sind wie die MaRisk-Anforderungen.
13
78
Haar/Schädler (2004): Verbaselt, IT-Sicherheit zukünftig relevant für Kreditvergabe und -rückzahlung. In: iX Heft 12, 2004, S. 99.
5 5 Prüfung von IT-Verfahren Die Prüfung von IT-Verfahren nimmt naturgemäß in der IT-Revision einen großen Raum ein, und obwohl dieses ganze Kapitel diesem Thema gewidmet ist, können hier nur einige Bereiche beleuchtet werden. Die Ausführungen in den folgenden Abschnitten orientieren sich an fachbezogenen ITVerfahren, d h. solchen Verfahren, die die Fachbereiche in ihren fachlichen Aufgaben unterstützen. Gleichwohl unterscheidet sich die Prüfung nicht sonderlich von der Prüfung von IT-Basisverfahren, d h. IT-Verfahren, die die IT-Architektur und IT-Dienste erstellen und betreiben. Als Maßstab für die in diesem Kapitel aufgeführten Prüfungsfragen dienen Best-PracticeGrundsätze. Abhängig von den bestehenden Sollvorgaben im Unternehmen können die aufgeführten Prüfungsfragen für das eigene Unternehmen daher über- oder unterdimensioniert erscheinen. Im Gegensatz zu den Fragen, die zur Erhebung des bestehenden Zustandes gestellt werden und möglichst durchgehend offen formuliert sein sollten, finden sich hier auch geschlossene Ja/Nein-Fragen. Dies ist immer dann der Fall, wenn mit der Frage geprüft wird, ob ein geforderter Punkt erfüllt ist oder nicht. Die Prüfungsfragen sind sowohl in der Vergangenheitsform (nachbetrachtend, z.B.: „Wurden die Anforderungen berücksichtigt?“) als auch in der Gegenwartsform (methodisch, z.B.: „Werden Änderungen getestet?“) formuliert. Durch die Änderung der Zeitform können nachbetrachtende Fragen sehr einfach in methodische Fragen umformuliert werden und umgekehrt: „Werden Anforderungen berücksichtigt?“, „Wurden die Änderungen getestet?“
5.1
Das Wesen eines IT-Verfahrens Bestandteile der Geschäftstätigkeit in einem Unternehmen sind Ressourcen, Verfahren und Prozesse. Eine Ressource ist ein Objekt, das zur Durchführung der Geschäftstätigkeit benötigt wird bzw. darin eine Rolle spielt. Dies kann ein physisches Objekt wie Material, Werkzeug oder eine Rechnung sein, eine Person oder auch ein virtuelles Objekt wie elektrischer Strom).
79
5 Prüfung von IT-Verfahren Ein Verfahren ist die Art und Weise, wie ein Ergebnis erzielt wird (welche Komponenten benötigt und wie sie miteinander kombiniert werden). Ein Prozess ist der Ablauf, in dem mit den Ressourcen ein Verfahren abgewickelt wird. Beispiel: Kaffee kochen
Objekte Person, die den Kaffee kocht, Kaffeebohnen, Kaffeemühle, Filter, Tasse/Kanne, heißes Wasser. Verfahren Heißes Wasser durchläuft Kaffeepulver, nimmt die Aromastoffe des Pulvers auf und wird gefiltert. Prozess Kaffeebohnen mahlen, Pulver in einen Filter über eine Tasse/Kanne geben, Wasser erhitzen und auf das Pulver gießen.
Dem Verfahren ist es egal, wie das heiße Wasser oder das Kaffeepulver zustande kommen. Dem Prozess ist es egal, wie die Aufnahme der Aromastoffe funktioniert. Ein Fachverfahren ist ein Verfahren in einem Unternehmen, das in einem Fachbereich angewendet wird, um eine fachliche Aufgabe durchzuführen. Fachliche IT-Verfahren sind informationstechnische Verfahren im Unternehmen, die die Fachverfahren technologisch unterstützen. Hierfür findet sich auch der Begriff der IT-Lösung. IT-Lösungen bestehen aus einer Kombination von IT- und anderen Ressourcen, die mithilfe entsprechender Prozesse und Managementfunktionen IT-Leistungen bzw. IT-Dienste erbringen. Damit unterstützen sie die Fachbereiche in der Durchführung ihrer Fachaufgaben oder auch den ITBereich selbst. Beispiel
Die Sachbearbeitung einer Versicherung hat die Fachaufgabe, Kundenschreiben zu bearbeiten (Kündigungen, Vertragsänderungen usw.). Die IT stellt dazu das IT-Verfahren „Elektronische Hauspost“ zur Verfügung, bei dem die Schreiben im Posteingang eingescannt, dem Sachbearbeiter als elektronisches Abbild zugeleitet und nach der Bearbeitung archiviert werden. Die IT-Lösung besteht aus: den benötigen IT-Ressourcen (Scanner, Dokumentenserver, Archivierungssystem, IT-Netzwerk), den sonstigen Ressourcen (Platz im Gebäude für alle Ressourcen, Scanpersonal, IT-Personal für Administration usw.), den Verfahrensprozessen (Scannen, Klassifizieren, Bearbeiten, Archivieren), den IT-Prozessen (IT-Administration, IT-Wartung, IT-Support usw.), den IT-Managementfunktionen (IT-Organisation, IT-Leistungsmanagement, IT-Sicherheitsmanagement usw.).
Die IT-Verfahren im Unternehmen arbeiten nicht isoliert voneinander, vielmehr bilden sie ein Geflecht mit mehreren Ebenen, in dem umfangreiche, komplexe Verfahren andere spezialisierte Verfahren nutzen (siehe Abbildung 5.1). Die erste Ebene besteht in der technischen Infrastruktur (Hardware und Rechnerplattformen, inklusive der erforderlichen Organisation für Betrieb und Weiterentwicklung), die von allen IT-Verfahren genutzt werden kann und im IT-Bereich angesiedelt ist.
80
5.2 Fragmentierung von Verfahrensprüfungen Die nächste Ebene besteht aus IT-Basisverfahren bzw. IT-Basisdiensten, die unter Nutzung der Infrastruktur oft benötigte Funktionalitäten für andere IT-Verfahren erbringen. Die ITBasisverfahren sind vollständige IT-Verfahren, die Technologie, IT-Prozesse und Managementfunktionen enthalten. Ein Beispiel ist das IT-Basisverfahren „E-Mail-Dienst“, das eine Kommunikationsplattform zur Verfügung stellt, wobei nicht festgelegt ist, zu welchem Zweck diese genutzt wird.
IT-gestützte Lohnabrechnung
Elektronische Hauspost
Datensicherung E-Mail-Dienst
Verzeichnisdienst
Datenbank
IT-Infrastruktur (Hardware, Systemplattformen)
Abbildung 5.1 Hierarchie von IT-Verfahren im Unternehmen
Auf einer dritten Ebene schließlich existieren die fachbezogenen IT-Verfahren, so wie am Beispiel der elektronischen Hauspost gezeigt. Sie können die IT-Basisverfahren nutzen, direkt auf die IT-Infrastruktur zurückgreifen oder es werden eigene IT-Komponenten speziell für ein Verfahren erstellt. Diese können vom IT-Bereich, vom Fachbereich oder einem externen Dienstleister betrieben werden. Auf diese Weise können neue IT-Verfahren modulartig zusammengestellt werden.
5.2
Fragmentierung von Verfahrensprüfungen Ein IT-Verfahren als Ganzes innerhalb einer einzigen Prüfung untersuchen zu wollen, bedeutet einen hohen Aufwand, eine lange Prüfungsdauer und eine nicht geringe Belastung des Fach- und IT-Bereichs. Aus diesem Grund werden Verfahrensprüfungen oft Schritt für Schritt durchgeführt, d h. es wird nur ein bestimmter Teil geprüft und die Prüfung anderer Teile im Prüfungsplan auf einen späteren Zeitpunkt gelegt. Wichtig ist, neben einer zeitlichen Prüfungsplanung auch eine inhaltliche Planung zu haben, d.h. sagen zu können, welche Teile von welchen Verfahren zu welchem Zeitpunkt geprüft wurden oder geprüft werden sollen. Es gibt folgende, sinnvolle Teile für die Fragmentierung einer Verfahrensprüfung: Es werden nur bestimmte Prüfungsaspekte geprüft. In der Prüfungsplanung wird das Prüfungsthema so formuliert, dass nur ein einziger
81
5 Prüfung von IT-Verfahren Prüfungsaspekt oder zumindest nur sehr wenige Prüfungsaspekte untersucht werden. Beispiel: „Sicherheit des IT-Verfahrens ABC“. Ist dieses Fragment noch zu umfangreich, dann kann es mit anderen kombiniert werden. Möglichkeiten dazu sind beispielsweise die Kombination mit einer Lebenszyklusphase: „Sicherheit des laufenden Betriebs des IT-Verfahrens ABC“, einem IT-Prozess: „Sicherheit der Administration des IT-Verfahrens ABC“ oder einer Architekturkomponente: „Sicherheit des zentralen Servers im IT-Verfahren ABC“. Es werden geografisch nur bestimmte Architekturkomponenten geprüft. Ist das Verfahren geografisch verteilt, dann könnte sich die Prüfung auf einen geografischen Standort beschränken. Das Verfahren wird dann ganzheitlich geprüft, jedoch nur an einem Ort. Es werden technisch nur bestimmte Architekturkomponenten geprüft. Analog zur geografischen Beschränkung kann auch technisch beschränkt werden. Dies findet sich vor allem dann, wenn Mängel vermutet werden, die in bestimmten Technologien bzw. Technologiewelten zu suchen sind. In diesem Fall würden nur solche Komponenten untersucht, die Teil der entsprechenden Technologiewelt sind. Beispiel: Es werden nur Komponenten des SAP-Systems oder nur Microsoft Windows-Komponenten untersucht. Es werden nur ausgewählte IT-Prozesse geprüft. Die technische Architektur bleibt hier außen vor, die Prüfung konzentriert sich auf einen IT-Prozess. So könnte beispielsweise nur der IT-Prozess „IT-Support“ geprüft werden. Die Beschränkung ist unabhängig von der Prüfungsmethodik, d h. ob die Prüfung als klassische Revisionsprüfung oder z.B. als CobIT-Prüfung (siehe Kapitel 7) durchgeführt wird. Es werden nur einzelne IT-Managementbereiche geprüft. Vergleichbar mit der Beschränkung auf einen IT-Prozess ist die Beschränkung auf einen Managementbereich. Es wird dann lediglich das Leistungsmanagement, das Sicherheitsmanagement oder ein anderer Managementbereich geprüft. Es werden nur bestimmte Lebenszyklusphasen geprüft. Auch eine Beschränkung auf eine Lebenszyklusphase ist möglich und sinnvoll. In diesem Fall würde z.B. nur die Verfahrensplanung geprüft (siehe dazu Abschnitt 5.3). Es wird nur ein bestimmter Zuständigkeitsbereich geprüft. Das wäre der Fall, wenn nur der Teil des Verfahrens geprüft wird, der in der Verantwortung eines bestimmten Bereichs im Unternehmen liegt (z.B. Rechenzentrum, Fachabteilung, Outsourcing-Dienstleister). Welche Fragmentierung gewählt wird, wird innerhalb der Prüfungsplanung (siehe Abschnitt 2.1) entschieden.
82
5.3 Prüfung der IT-Verfahrensplanung
5.3
Prüfung der IT-Verfahrensplanung Dieser Abschnitt ist ein Beispiel für die Prüfung einer Lebenszyklusphase. Es gibt verschiedene Lebenszyklusmodelle für die IT, oft anzutreffende Phasen sind dabei:
Planung
Entwicklung
Implemenierung
Betrieb
Änderung Migration
Roll-Off (Entfernung, Entsorgung)
Abbildung 5.2 Lebenszyklusphasen von IT-Verfahren
In der Planung wird ein zukünftiges IT-Verfahren „am Reißbrett“ entworfen, dabei werden Aufbau und Eigenschaften des neuen IT-Verfahrens festgelegt.
5.3.1
Anforderungen an das neue IT-Verfahren
Um sicherzustellen, dass das neue IT-Verfahren seinen Zweck erfüllt und die Funktionalitäten bietet, die der Fachbereich zur Durchführung der Fachaufgabe benötigt, die von dem neuen IT-Verfahren unterstützt werden soll, müssen in der Planungsphase die Anforderungen an das neue IT-Verfahren formuliert werden. Hierbei gibt es mehrere Anforderungskategorien, die in der Planung berücksichtigt werden müssen: Technische Anforderungen (Plattform, Programmiersprache, Performance, Schnittstellenkompatibilität usw.) Bedienungsanforderungen (Design, Ergonomie, Barrierefreiheit, Einhalten der Bildschirmplatzverordnung usw.) Kostenanforderungen (Anschaffungskosten, Betriebskosten, Wartungskosten, maximale Kosten für eine Transaktion oder einen Zeitraum usw.) Sicherheitsanforderungen (Schutz vor Ausfall, Ausspähung oder Manipulation) Organisatorische Anforderungen (Integrierbarkeit in bestehende IT-Prozesse, Abbildung von Verantwortlichkeiten usw.) Fachliche Anforderungen (Mandantentrennung, Abbildung der fachlichen Prozesse usw.) Rechtliche Anforderungen (GoBS-Konformität bei buchführungsrelevanten Systemen, SOX-Compliance1 bei Systemen, die relevant für die Finanzberichterstattung sind) Beispielhafte Prüfungsfragen in diesem Gebiet: Wurden bei der Planung des Verfahrens Anforderungen an das Verfahren gestellt? Bei einem Nein erübrigen sich alle nachfolgenden Fragen.
1
Anforderungen des Sarbanes-Oxley Acts, sofern das Unternehmen diesen US-Bestimmungen unterliegt.
83
5 Prüfung von IT-Verfahren Wurden alle Anforderungskategorien gleichmäßig berücksichtigt? Es sollte nicht sein, dass es in einer Kategorie zehn Anforderungen gibt und in anderen Kategorien gar keine. Es sollte auch nicht sein, dass nur der IT-Bereich Anforderungen stellt und die betroffenen Fachbereiche nicht. Wurden Konflikte zwischen den Anforderungen kenntlich gemacht und entschieden? Bei der Fülle von Anforderungen gibt es praktisch immer Konflikte, z.B. zwischen fachlichen Anforderungen und den Kostenanforderungen. Es sollte nachvollziehbar sein, wie mit diesen Konflikten umgegangen wurde und wie sie entschieden wurden. Wurden die Anforderungen gewichtet bzw. priorisiert? Nicht alle Anforderungen sind gleich wichtig. Daher sollten sie in mindestens drei Klassen eingeteilt werden: MUSS: Die Anforderung muss unbedingt erfüllt werden, sonst kann das Verfahren nicht in Betrieb gehen. SOLLTE: Für einen sinnvollen Betrieb bzw. eine sinnvolle Nutzung ist die Erfüllung der Anforderung wichtig. KANN: Optionale Anforderung. Die Erfüllung ist wünschenswert, aber nicht notwendig. Wurden die Anforderungen prüfbar dokumentiert? Die Anforderungen sollten in einem Planungsdokument aufgeführt sein, das der ITRevision für die Prüfung zur Verfügung gestellt werden kann. Wurden die Anforderungen abgestimmt bzw. genehmigt? Es sollte verhindert werden, dass unrealistische, unsinnige, interessengetriebene oder irrelevante Anforderungen gestellt werden. Wie wurde die Erfüllung der Anforderungen überwacht und kontrolliert? Was geschah bei Abweichungen? Während der Entwicklung und Implementierung sollte es Prüfzeitpunkte geben, an denen der Stand der Erfüllung überprüft wird. Entspricht der Stand der Erfüllung nicht der Planung, sollte es ein geeignetes Vorgehen dafür geben.
5.3.2
Einsatzplanung
Im Rahmen der Planung werden die Ausrichtung und der Einsatz des neuen IT-Verfahrens geplant. Hier sind es besonders die Anforderungen der IT-Managementfunktionen bzw. der IT-Organisation, die beim Einsatz des Verfahrens zufriedengestellt werden müssen. Beispielhafte Prüfungsfragen in diesem Gebiet: Wo ist dokumentiert, wer für was zuständig ist? Ist die Zuordnung der Verantwortlichkeiten eindeutig? Es sollte klar festgelegt sein, welche Verantwortungsbereiche es gibt. Die Bereiche sollten keine Überschneidungen aufweisen, und es sollten nicht mehrere Organisationseinheiten für einen Bereich verantwortlich sein.
84
5.3 Prüfung der IT-Verfahrensplanung Wie wurde gewährleistet, dass das neue Verfahren der IT-Strategie entspricht? Existiert überhaupt eine IT-Strategie, an der das Verfahren ausgerichtet werden kann? Wo sind Kriterien zu finden, mit denen die Konformität zur IT-Strategie festgestellt werden kann2? Welcher Prozess oder welche Aktivität sorgt dafür, dass diese Kriterien geprüft und verfolgt werden? Wo wurde geregelt, wie die IT-Prozesse für das neue Verfahren abgewickelt werden sollen? Wer ist für welche IT-Prozesse zuständig? Welche Leistungen sollen erbracht werden? Wie wird kontrolliert, dass sie erbracht werden? Wie werden sie abgerechnet? Ist geregelt, wie Probleme und Störungen behandelt werden?
5.3.3
Einbettung in Geschäftsprozesse
Fachbezogene IT-Verfahren unterstützen direkt die Verfahren der Geschäftsprozesse. Daher ist es wichtig, die unterstützten Geschäftsprozesse und deren Ansprüche zu verstehen, adäquat bei der Planung zu berücksichtigen und das neue IT-Verfahren passgenau in die Geschäftsprozesse einzubetten. Beispielhafte Prüfungsfragen in diesem Gebiet: Mit welcher Methodik wurden die Geschäftsprozesse untersucht, um das IT-Verfahren optimal gestalten zu können? Nach welchen Kriterien wurden die Geschäftsprozesse untersucht? Wie wurden die Leistungsansprüche der Geschäftsprozesse in der Planung umgesetzt? Wurde die erwartete Performance ermittelt? Wurden durchschnittliche und Spitzenbelastungen erhoben? Wurde die Kritikalität des Geschäftsprozesses betrachtet? Welche Methodik und welches Vorgehen kamen dabei zum Einsatz? Wie wurden die Qualitätsansprüche der Geschäftsprozesse in der Planung berücksichtigt? Gibt es beispielsweise eine garantierte Dienstqualität? Wie wird sie gemessen und überwacht? Was geschieht, wenn sie nicht erfüllt wird? Auf welche Weise wird sichergestellt, dass die IT-Komponenten zur Geschäftstätigkeit passen? Welches Vorgehen existiert für die Auswahl der IT-Komponenten im Hinblick auf die zu unterstützenden Geschäftsprozesse? Sind Kosten/Nutzen-Betrachtungen Bestandteil der Verfahrensplanung? Da in vielen Fällen der Fachbereich für die laufenden Kosten aufkommt oder zumindest daran beteiligt wird, sollte eine transparente Kostenplanung erfolgen, in die der Fachbereich einbezogen wird.
2
D.h. woran kann erkannt werden, dass das neue Verfahren der IT-Strategie entspricht?
85
5 Prüfung von IT-Verfahren Welche Sicherheitsanforderungen wurden für das Verfahren ermittelt? Wie wurde der Schutzbedarf festgestellt? Wo ist er dokumentiert? Sind die Sicherheitsanforderungen im Einklang mit der bestehenden IT Security Policy? Welche Datenschutzanforderungen wurden für das Verfahren ermittelt? Sind die Anforderungen allen Beteiligten bekannt? Wurden sie zur Einhaltung verpflichtet?
5.3.4
Einbettung in die IT
So wie es erforderlich ist, das IT-Verfahren in die Geschäftsprozesse einzubetten, ist es auch notwendig, die Gegebenheiten der IT zu berücksichtigen. Insellösungen für einzelne Fachbereiche werden immer seltener, schon seit langem ist Standardisierung das Zauberwort in der IT. Das bedeutet, dass für jedes fachbezogene Verfahren zunächst geprüft wird, ob bestehende Infrastrukturdienste genutzt werden können, bevor neue entwickelt werden. Neue Verfahren werden auf diese Weise mit der IT verzahnt. IT-Infrastruktur und IT-Prozesse Die IT-Infrastruktur stellt die Hardware- und Betriebssystemplattformen für die fachbezogenen Verfahren zur Verfügung und betreibt die damit verbundenen IT-Prozesse. Praxistipp
Es ist sinnvoll, die IT-Infrastruktur und deren IT-Prozesse in einer eigenständigen Prüfung zu untersuchen und sich in den Prüfungen der fachbezogenen IT-Verfahren auf die Zusammenarbeit zwischen den Verfahren und der IT-Infrastruktur zu konzentrieren. Dabei ist die Anwendung eines Reifegradmodells auf beiden Seiten zweckmäßig, um schnell feststellen zu können, ob die Leistungen und Dienste der Infrastruktur den Anforderungen des Verfahrens gerecht werden.
Beispielhafte Prüfungsfragen in diesem Gebiet: Wurden Anforderungen vom Verfahren an die IT-Infrastruktur gestellt? Das neue IT-Verfahren kann nur so gut sein wie die Infrastruktur, die es nutzt. Daher sollte das Verfahren besonders im Hinblick auf Sicherheit und Qualität Anforderungen formulieren. Sind Schnittstellen, Übergabepunkte, Übergabeformate etc. definiert und dokumentiert? Wurden Vereinbarungen mit dem Betreiber der Infrastruktur getroffen? Gibt es garantierte Leistungen oder Parameter? Wie werden die vereinbarten Leistungen überwacht oder kontrolliert? Gibt es Regelungen/Sanktionen für Verstöße? Sind diese Bestandteil der Vereinbarungen und bereits im Vorfeld von Verstößen klar kommuniziert? In welchen Fällen werden die Vereinbarungen angepasst bzw. auf Aktualität geprüft? Auf welche Weise erfolgt eine Überprüfung/Anpassung? Besonders bei technisch detaillierten Vereinbarungen können Releasewechsel, Migra-
86
5.4 Prüfung der Verfahrensdokumentation tionen und andere IT-Änderungen Auswirkungen besitzen, die das neue IT-Verfahren berühren. Daher sollte es regelmäßige oder ereignisgetriebene Überprüfungen/Anpassungen geben. Wie stimmt die Infrastruktur Änderungen mit dem/den Verfahrensverantwortlichen ab? Gibt es eine definierte Vorgehensweise für die Information und Einbindung des/der Verfahrensverantwortlichen bei Änderungen in der Infrastruktur? Sind die Abhängigkeiten in der IT-Infrastruktur bekannt, die bei der Erbringung der Leistungen für das Verfahren bestehen? Besonders für die IT-Sicherheit ist die Kenntnis der Abhängigkeiten wichtig, um z.B. einen Schutz vor Ausfällen organisieren zu können. Wie wurde dafür gesorgt, dass die IT-Strategie und die Anforderungen des Verfahrens in Einklang gebracht werden?
5.4
Prüfung der Verfahrensdokumentation Dieser Abschnitt ist ein Beispiel für die Prüfung einer Verfahrenskomponente. Eine solche Komponente besteht aus dem auf die Verfahrenskomponente bezogenen IT-Management (z.B. Aufbau und Struktur der Dokumentation), Architekturkomponenten (hier: die Dokumente der Verfahrensdokumentation) und IT-Prozessen (hier z.B. die Sicherung und Archivierung der Dokumente). Der Vorgang der Dokumentation kann als eigenständiger Prozess aufgefasst („IT-Verfahren dokumentieren“) oder aber in andere IT-Prozesse (z.B. die Administration) integriert werden. Unabhängig davon ist die Prüfung der Dokumentation in nahezu jeder Verfahrungsprüfung ein Prüfungsbestandteil. Für buchführungsrelevante IT-Verfahren ist die Verfahrensdokumentation durch die Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS, siehe Kapitel 4) zwingend vorgeschrieben, aber auch für alle anderen IT-Verfahren ist sie sinnvoll, wenngleich sie nicht immer so umfangreich sein muss, wie es in den GoBS gefordert wird. Um allen Verfahren gerecht zu werden, wird in diesem Abschnitt die Verfahrensdokumentation nach GoBS beschrieben. Dort, wo die GoBS nicht vorgeschrieben sind, können entsprechend Abstriche gemacht werden.
5.4.1
Das Wesen der Verfahrensdokumentation
Schon Goethe wusste: „Was man schwarz auf weiß besitzt, kann man getrost nach Hause tragen.“ Solange Dinge nicht schriftlich dokumentiert sind, sind sie flüchtig, von einzelnen Personen abhängig, mehrdeutig (Stille-Post-Syndrom), für Dritte nicht auffindbar, nicht nachlesbar und nicht prüfbar. Die Dokumentation ist daher nicht nur für die IT-Revision eine wichtige Informationsquelle, sie ist auch ein wichtiges Qualitätsmerkmal für ein IT-Verfahren.
87
5 Prüfung von IT-Verfahren Die Verfahrensdokumentation besteht aus Dokumenten3, die das Verfahren beschreiben und aufzeichnen. Hier beginnt das Problem: Da die IT-Verfahren und ihr Dokumentationsbedarf sehr unterschiedlich sein können, gibt es auch sehr unterschiedliche Auffassungen über die Struktur und den Inhalt einer Verfahrensdokumentation. Auch die GoBS geben nur ein grobes Schema vor, nach dem die Verfahrensdokumentation aus fünf Teilen besteht: Beschreibung der sachlogischen Lösung Beschreibung der technischen Lösung Beschreibung der Wahrung der Programmidentität Beschreibung der Wahrung der Datenintegrität Arbeitsanweisungen für den Anwender Wie diese Teile formal und inhaltlich auszugestalten sind, wie die Dokumentation (technisch) geführt wird, welche Qualitätsmerkmale gefordert werden oder welcher Umfang als angemessen zu betrachten ist, das überlassen die GoBS dem Unternehmen, und bei der Prüfung beurteilt das jeder Prüfer anders. Das erschwert den Fachbereichen die Erstellung der Dokumentation. Wird nur eine knappe Dokumentation erstellt, läuft man Gefahr, dass die Dokumentation als unzureichend bewertet wird. Will man auf Nummer sicher gehen und erstellt eine umfangreiche Dokumentation, dann ist die Erstellung teuer, verursacht einen nicht gerade geringen Aufwand, um sie aktuell zu halten, und man läuft Gefahr, mit Kanonen auf Spatzen zu schießen. Für das Unternehmen ist es hinsichtlich der Struktur der Verfahrensdokumentation unerheblich, ob für das Verfahren ein kleines PC-Programm oder ein großes SAP-System angewendet wird, lediglich der Umfang kann variieren. Eine Powerpoint-Folie mit den Systemkomponenten oder ein dürftiges Anwenderhandbuch mit den wichtigsten Funktionalitäten der eingesetzten Software, das stolz vom Fachbereich als Verfahrensdokumentation präsentiert wird, reicht jedoch in keinem Fall aus! Bei Standard-Software-Produkten erstellen die Hersteller von Buchführungssystemen für ihr System eine Dokumentation und lassen teilweise, um die Unternehmen zu entlasten, ihr komplettes Produkt nach GoBS zertifizieren (z.B. von einer Wirtschaftsprüfungsgesellschaft). Mit einer solchen Standard-Dokumentation wird man den Ansprüchen der GoBS aber nur zum Teil gerecht, denn der Hersteller kann nicht wissen, wie sein Produkt in die Architektur und die IT-Prozesse eingebettet wird. Auch wenn die Dokumentation vom Hersteller oder einem Dritten erstellt wird: Verantwortlich dafür bleibt das Unternehmen.
3
88
Ein Dokument ist nicht nur als Papier- bzw. Office-Dokument zu verstehen, auch eine Loggingdatei oder andere automatisch erstellte Datenansammlungen sind Dokumente im Sinne der Dokumentation.
5.4 Prüfung der Verfahrensdokumentation
5.4.2
Beschreibung der sachlogischen Lösung
Einsatzzweck Der Begriff der „sachlogischen Lösung“ kann mit „Anwendung des IT-Verfahrens“ übersetzt werden. In der Verfahrensdokumentation wird beschrieben, welche fachliche Aufgabe mit dem Verfahren durchgeführt wird und auf welche Weise das geschieht. Auch eine kompakte Beschreibung der Geschäftsprozesse, die mit dem Verfahren unterstützt werden, ist Teil der sachlogischen Lösung. Für welchen Zweck wird das Verfahren im Unternehmen verwendet? In welchem (fachlichen) Gebiet wird es eingesetzt? Für was und wie wird es genutzt? Im Vordergrund stehen die Aspekte, mit denen der Benutzer konfrontiert wird. Das sind zum Beispiel die Ein- und Ausgabemasken der Software (wo wird was eingegeben?), die Fehlermeldungen und deren Behandlung, die vom Verfahren geführten Daten (eingegebene, berechnete, eingespeiste/übertragene) oder die Beschreibung des Austausches von Daten (werden sie direkt online übertragen, über einen Kommunikationsdienst übertragen, auf Datenträger gespeichert und weitergegeben?). Teilweise finden sich diese Informationen in den Handbüchern. Prozesse Wie sehen die Abläufe bei der Nutzung aus? Wie ist die Navigation in der Software aufgebaut? Welche Bedienungspfade ergeben sich? Welche Ausnahmezustände sind vorhanden? Für diese Informationen können ebenfalls die Handbücher (Benutzer-, Administrator-, Systemhandbuch) eine wertvolle Quelle sein. Internes Kontrollsystem Aus der Verfahrensdokumentation muss hervorgehen, welche Kontrollen an welchen Stellen im IT-Verfahren vorhanden sind. Werden Eingaben maschinell (Software-Funktion) oder manuell (Vier-Augen-Prinzip) überprüft? Wird vor dem Aufruf einer (eventuell kritischen) Funktion geprüft, ob alle Voraussetzungen für die Funktion erfüllt sind? Wird kontrolliert, ob der Benutzer zur Durchführung der Funktion berechtigt ist? Wird eine unvollständig durchgeführte und abgebrochene Aktion wieder in den vorherigen Ursprungszustand versetzt (Transaktionsprinzip)? Für die Gesamtheit der internen, d.h. in das Verfahren eingebauten Kontrollen hat sich der Begriff „internes Kontrollsystem“ (IKS) etabliert. Damit sind alle Maßnahmen (Kontrollen) gemeint, mit denen Kriterien wie Vollständigkeit oder Richtigkeit sichergestellt werden. Aus der Dokumentation muss ersichtlich sein, welchen Umfang dieses IKS hat und auf welche Weise es wirkt.
89
5 Prüfung von IT-Verfahren
5.4.3
Beschreibung der technischen Lösung
In der sachlogischen Lösung wurde das technische System als Black-Box gesehen. Wichtig waren die Schnittstellen zur Nutzung der Lösung und deren Anwendung in den jeweils unterstützten Prozessen. Mit der Beschreibung der technischen Lösung wird die Black-Box zur White-Box. Nun interessiert, wie die Lösung technisch aufgebaut ist, aus welchen Komponenten sie besteht und wie diese Komponenten zusammenwirken. Als Bindeglied zwischen der sachlogischen und der technischen Lösung wird in der Verfahrensdokumentation beschrieben, wie die sachlogischen Forderungen technisch umgesetzt sind. So kann beispielsweise eine IT-gestützte Zeiterfassung sehr unterschiedlich realisiert werden. Die Zeit könnte vom Mitarbeiter manuell in eine webbasierte Applikation eingetragen werden, sie könnte automatisch erfasst werden, indem eine Mitarbeiterkarte an ein Lesegerät geführt oder eingesteckt wird, oder sie könnte automatisch und berührungslos erfasst werden, wenn der Mitarbeiter eine bestimmte Stelle (z.B. die Pforte) passiert. Aus der Sicht der sachlogischen Lösung sind die Vorgänge identisch: Es wird die Zeit erfasst und maschinell verarbeitbar bereitgestellt. Aus der Sicht der technischen Lösung sind die drei Varianten komplett verschieden. Aus der Verfahrensdokumentation muss der Systemzustand hervorgehen. Sie muss vollständig (d.h. alle eingesetzten Komponenten müssen enthalten sein) und aktuell sein. Aus der Forderung nach Aktualität ergibt sich, dass Änderungen in der technischen Lösung auch in der Verfahrensdokumentation vollzogen werden müssen. Dabei muss nachvollzogen werden können, von welchem Zustand (alt) sich die Lösung zu welchem Zustand (neu) verändert hat. Auch hier gilt: Ein sachkundiger Dritter muss ausschließlich anhand der Beschreibung die technische Lösung verstehen können. Architekturübersicht Die Architekturübersicht ist der Einstieg in die Beschreibung der technischen Lösung. Hier wird (meist grafisch) dargestellt, welche IT-Systeme an der technischen Lösung beteiligt und wie sie verschaltet sind. Abbildung 5.3 zeigt ein Beispiel für eine solche Architekturübersicht. MailServer Spock
Webserver Marvin
X.500-DSA Olli X.500-Backup Stan
FW-DSF234 Switch
.37
.34
. 12 .22
Corporate Net
.14
.72 197.54.124.0
Abbildung 5.3 Beispiel für eine Architekturübersicht
90
.169
.98 .178
.57
5.4 Prüfung der Verfahrensdokumentation Solche Übersichten sind in der Praxis meist komplexer und enthalten auch physische Standorte oder Verantwortungsbereiche. Auf die Verbindungslinien zwischen IT-Systemen können auch die Datenflüsse oder Übertragungsformate geschrieben werden. Möchte man die Lösung technisch detailliert dokumentieren, dann erfordert das die Dokumentation von sieben Ebenen, wie man der nachfolgenden Aufstellung für einen Server entnehmen kann. Die Angaben in den einzelnen Ebenen sind dabei nur beispielhaft, in der Praxis werden sie je nach Bedarf definiert und haben in der Regel einen größeren Umfang. Physische Ebene Aufstellungsort (Standort, Gebäude, Raum, Rack, Position im Rack) Hardware (Geräteart, Hersteller, Typ, Seriennummer, Inventarnummer) Hardware-Eigenschaften (Prozessor, Hauptspeicher, Laufwerke, Karten) Netzwerkebene Netzwerkprotokoll (z.B. TCP/IP) Netzwerkmaske Netzwerkadresse (z.B. 197.54.124.34) Patching-Informationen (an welcher Dose/Buchse, an welchem Verteiler/Port angeschlossen) Systemebene Art des Betriebssystems Hersteller und Typ Version und Patchlevel Applikationsebene Applikationen, Dienste und Protokolle mit Name und Typ, Kurzbeschreibung und benutzte Ports Inhaltsebene Geführte Daten (Stammdaten, Bewegungsdaten, Konfigurationsdaten etc.) Personelle Ebene Technischer Verantwortlicher Fachlicher Verantwortlicher Betreiber Übergeordnete Ebene Logischer Servername Owner (Kostenstelle) Übersicht der Datenflüsse und Schnittstellen Aus dieser Übersicht lässt sich erkennen, welche Daten über welche Schnittstellen auf welche Weise in die technische Lösung einfließen, von welchen IT-Systemen dort verarbeitet und über welche Schnittstellen wieder ausgegeben bzw. an andere Stellen übergeben werden.
91
5 Prüfung von IT-Verfahren Zeiterfassung Lohnabrechnung ERP Weiterbildung Reisekosten Personalstammdaten Personalkostenplanung Stellenplanung
Übertragungszweck? Welche Formate? Wann übertragen? Welche Übertragungsart? Wie gesichert? Wie überwacht?
Personalsystem
Recruiting
Inhaltlich welche Daten?
Abbildung 5.4 Datenflussübersicht
Eine Schnittstelle ist ein Übergangspunkt. In einer Schnittstellenübersicht wird entsprechend vermerkt, welche Übergangspunkte es in der technischen Lösung gibt, von wo nach wo der Übergang erfolgt und für was die Schnittstelle genutzt wird. Abbildung 5.4 zeigt ein Personalsystem, an das mehrere Anwendungen und Systeme angegliedert sind, die Daten mit dem Personalsystem austauschen. Die Übersicht ist vor allem wichtig, wenn die Abläufe des Verfahrens (Dynamik) betrachtet werden. Dort wird beispielsweise geprüft, wie sichergestellt wird, dass übertragene Daten vom Zielsystem empfangen wurden bzw. wann und aufgrund welcher Ereignisse es bemerkt wird, dass sie nicht empfangen wurden. IT-Sicherheit und Datenschutz In modernen IT-Umgebungen ist es heutzutage üblich, bereits in der Planungs- und Entwicklungsphase ein Sicherheitskonzept für neue IT-Verfahren zu erstellen. Aus der fachlich orientierten Planung (vgl. Abschnitt 5.3.3) ergeben sich die Sicherheitsanforderungen und der Schutzbedarf des Verfahrens, der sich wiederum am Schadenspotenzial für das Unternehmen orientiert. Praxistipp
Die IT-Sicherheit ist ein wichtiger Prüfungsaspekt, der in jeder IT-Prüfung auf dem Programm stehen sollte. Lassen Sie sich vom IT-Sicherheitsmanagement die für das Verfahren definierten bzw. anzuwendenden IT-Sicherheitsanforderungen geben, damit sparen Sie in der Prüfungsvorbereitung Zeit. Die IT-Sicherheitsanforderungen selbst können Sie z.B. in der Prüfung der Verfahrensplanung untersuchen (sind sie ausreichend usw.).
Im Abschnitt IT-Sicherheit der technischen Lösung wird das Sicherheitskonzept beschrieben. Es wird kompakt dargestellt, auf welche Weise und mit welchen Sicherheitsmechanismen die erforderliche Sicherheit im Regelbetrieb technisch und organisatorisch gewährleistet und über die Zeit bewahrt wird. Bestandteil ist auch die Darstellung, wie das Verfahren in das Sicherheitsmanagement eingebunden ist. Zusätzlich sollte immer der Notfall betrachtet werden, d h. der Fall, dass der Regelbetrieb nicht aufrechterhalten werden kann. Für kritische Verfahren muss im Notfall ein Notbetrieb eingerichtet werden, der die wichtigsten Funktionen auch nach Eintritt eines Notfalls bedienen kann. In der Regel wird dazu ein Business-Continuity-Konzept erstellt, das verschiedene Notfall- und Ausfallszenarien betrachtet.
92
5.4 Prüfung der Verfahrensdokumentation Ebenso werden die datenschutzrechtlichen Implikationen des Verfahrens dargestellt und beschrieben, durch welche technischen und organisatorischen Maßnahmen der Datenschutz gewährleistet wird. Technischer Betrieb und Wartung In diesem Abschnitt wird beschrieben, wie der ordnungsmäßige Betrieb der technischen Lösung sichergestellt wird. Es werden alle Maßnahmen aufgeführt, die für einen solchen Betrieb erforderlich sind. Das beginnt mit der Darstellung, welche Betriebsvoraussetzungen bzw. Betriebsbedingungen gegeben sein müssen, damit ein ordnungsmäßiger Betrieb überhaupt stattfinden kann. Als Nächstes wird der Betrieb selbst beschrieben: Welche Betriebsprozesse und Tätigkeiten gehören dazu? Welche Arbeiten fallen zu welchen Zeitpunkten an? Wer ist verantwortlich, wer zuständig für welche Prozesse und Tätigkeiten? Wie kann festgestellt werden, ob die Tätigkeiten rechtzeitig und in ausreichender Qualität (Vollständigkeit, Korrektheit) durchgeführt wurden? Existieren hierfür Kontrollen, die im IKS beschrieben sind? Als letzter Punkt wird in ähnlicher Form die Wartung beschrieben. Welche Komponenten der technischen Lösung besitzen welchen Wartungsbedarf? Wer ist verantwortlich, wer zuständig für welche Wartungstätigkeiten? Werden Wartungsprotokolle angefertigt? Wann werden die Wartungsprotokolle durchgesehen und kontrolliert? Werden die Ergebnisse der Tätigkeiten überprüft? Gibt es Abnahme- bzw. Freigabeprozesse? Gibt es hierfür Kontrollen im IKS? Auch das Einspielen von Updates und Patches fällt unter die Wartung. Hier kommt der Aspekt des Testens hinzu. Werden bei jeder Wartungsmaßnahme, die eine Veränderung der Informationstechnik darstellt, entsprechende Test- und Abnahmeverfahren durchgeführt? Wie wird erreicht, dass die Tests zweckmäßig, angemessen, realitätsnah und aussagekräftig sind? Werden die Tests priorisiert? Ist für jeden Test festgelegt, was sich für Konsequenzen ergeben, wenn der Test nicht bestanden wird? Gibt es Abhängigkeiten zwischen den Tests, die eine Reihenfolge vorschreiben? Wie wird eine ausreichende Testabdeckung erreicht? Wo werden die Testfälle, deren Durchführung und das Testergebnis dokumentiert? Ist der Datenschutz hinsichtlich der verwendeten Testdaten gewährleistet?
5.4.4
Programmidentität
In der sachlogischen Lösung sind die Eigenschaften festgelegt, die das IT-Verfahren in seiner Anwendung besitzt. Durch diese Eigenschaften bekommt es ein bestimmtes Verhalten, eine Identität. Diese Identität sollte über die Zeit gleich bleiben, um die Geschäftsprozesse konstant in gleicher Weise zu unterstützen. Die technische Lösung wird aufgrund von Aktualisierungen (Updates), Änderungen (Changes), Migrationen usw. über die Zeit nicht konstant bleiben. Daher wird in der Verfahrensdokumentation fixiert, dass und wie die Programmidentität4 für die aktuelle technische Lösung gewahrt ist. 4
Der Name ist etwas irreführend. Es geht nicht um ein einzelnes Programm, sondern um die Gesamtheit der technischen Lösung des IT-Verfahrens.
93
5 Prüfung von IT-Verfahren Erbringt die aktuelle technische Lösung die sachlogisch geforderten Eigenschaften? Wie wurde dies durch Test- und Freigabeverfahren sichergestellt? Welche Tests wurden mit welchen Daten durchgeführt? Wer darf die technische Lösung freigeben? Nach welchen Kriterien erfolgt die Freigabe? Entsprach die Freigabe der aktuellen technischen Lösung diesen Vorgaben? Existiert eine Freigabeerklärung, aus der hervorgeht, welche Komponenten in welchen Versionen bzw. Zuständen in der aktuellen technischen Lösung eingesetzt werden? Wurden die Testdatenbestände aufbewahrt? Alle diese Fragen zielen darauf festzustellen, ob die Identität der aktuell eingesetzten technischen Lösung der ursprünglich definierten Identität entspricht.
5.4.5
Datenintegrität
Den Begriff der Integrität kann man mit dem Wort „Beibehaltung“ übersetzen. Wenn eine Person ihre ursprüngliche Meinung beibehält (auch wenn das für sie nachteilig wird), dann gilt diese Person als integer. Daten, die ihren ursprünglichen Inhalt beibehalten und nicht unbefugt verändert werden, sind ebenfalls integer. Die Integrität ist ein Sicherheitskriterium und gehört daher in den Abschnitt IT-Sicherheit. Die Datenintegrität wird jedoch als so bedeutend eingestuft, dass in der Verfahrensdokumentation nicht nur allgemein das Sicherheitskonzept beschrieben werden muss, sondern ganz konkret, welche Maßnahmen in der technischen Lösung dafür sorgen, dass in der aktuellen technischen Lösung unbefugte Veränderungen von Daten (Nutzdaten, Konfigurationsdaten usw.), Programmen (Zustand von Software) und der Architektur (z.B. Umleiten und Verändern von Datenflüssen) ausgeschlossen sind. Eine besondere Stellung nehmen dabei die Berechtigungssysteme ein, da sie die primären Schutzeinrichtungen darstellen. In der Verfahrensdokumentation wird das Berechtigungskonzept beschrieben, d.h. welche Rollen und Berechtigungen existieren und wie sie an Benutzer vergeben werden. Des Weiteren wird protokolliert, welche Rechte aktuell vorhanden sind, welche Benutzer über welche Rechte verfügen und wer wann aufgrund welcher Entscheidung diese Rechte vergeben hat. Letzteres wird in der Regel im Zuge eines Antrags- und Genehmigungsverfahrens protokolliert.
5.4.6
Arbeitsanweisungen für den Anwender
Im Verfahren muss klar sein, was die Anwender des Verfahrens zu tun haben, um der sachlogischen Lösung gerecht zu werden. Diese Klarheit wird in der Regel durch Arbeitsanweisungen hergestellt. Darin wird beschrieben, was in welcher Weise zu tun ist. Die Arbeitsanweisungen müssen schriftlich fixiert werden und sind Bestandteil der Verfahrensdokumentation. Die Anweisungen müssen so gestaltet sein, dass sie für den Anwender verständlich sind und alles enthalten, was zur sachgerechten Erledigung der Aufgaben notwendig ist. Zu den
94
5.4 Prüfung der Verfahrensdokumentation Aufgaben gehören auch die manuellen Kontrollen, die im internen Kontrollsystem festgelegt sind, sowie andere vorgesehene Abstimmungen. Häufig wird eine zentrale Standardsoftware eingesetzt, mit der das Verfahren durchgeführt wird. In diesen Fällen besteht oft die Meinung, dass das vom Hersteller mitgelieferte Benutzerhandbuch der Software eine Dokumentation im Sinne dieses Abschnitts wäre. Da in einem solchen Handbuch tatsächlich viele der geforderten Inhalte zu finden sind (z.B. Beschreibung der Durchführung einzelner Funktionen oder auch manueller Kontrollen), gilt es für den IT-Revisor zu prüfen, ob die Inhalte ausreichend sind und alle Aufgaben der Anwender umfassen.
5.4.7
Prüfen der Verfahrensdokumentation
Die Verfahrensdokumentation ist zunächst eine Dokumentation wie jede andere auch. Daher sind an die Verfahrensdokumentation jene Maßstäbe anzulegen, die auch für andere Dokumentationen gelten. Daraus ergeben sich folgende, beispielhafte Prüfungsfragen für die Dokumentation im Allgemeinen: Ist überhaupt eine Dokumentation vorhanden? Nicht selten wird gar nicht dokumentiert, besonders wenn man es mit pragmatisch arbeitenden Fachbereichen zu tun hat, bei denen das Wissen um das Verfahren im Kopf der verantwortlichen Mitarbeiter steckt. Wo wird die Dokumentation geführt und aufbewahrt? Die Dokumentation muss so aufbewahrt werden, dass sie vor Verlust geschützt ist. Dabei ist es unerheblich, ob die Dokumentation in Papierform oder elektronisch existiert. Gleichzeitig muss die Dokumentation nutzbar und deshalb zugänglich sein. Sind die Aufbewahrungsfristen für die Dokumentation bekannt? Ist die Form der Dokumentation dauerhaft, d.h. kann (besonders bei elektronischer Form) auch nach langer Zeit noch auf die Dokumentation zugegriffen werden? Wurde die Dokumentation auf 8-Zoll-Disketten gespeichert, dann wird es heute schwierig, ein passendes Laufwerk zu finden. Ist die Dokumentation vollständig und ausführlich? Enthält die Dokumentation alle Informationen, die dokumentiert werden sollen bzw. müssen? Sind die Informationen ausführlich genug dargestellt? Die Information „Die Lohnabrechnungsdaten werden vom System automatisch übertragen“ ist nicht ausreichend. Zu welchen Zeitpunkten? Von wo nach wo? In welchem Format? Als Datentransfer oder als Transaktion? Wird die Übertragung gesichert? Ist die Dokumentation angemessen und in Form und Inhalt geeignet? Eine Dokumentation kann manuell oder automatisch erstellt und elektronisch oder in Papierform geführt werden. Die Nachvollziehbarkeit kann über Änderungsmarkierungen und Versionierungen erreicht werden. Der Inhalt kann grafisch, text- oder datensatzorientiert sein. Aufgrund der Fülle der Möglichkeiten ist vom IT-Revisor zu bewerten, ob die Dokumentation angesichts des zu dokumentierenden Objekts angemessen und geeignet er-
95
5 Prüfung von IT-Verfahren scheint. Wenn sehr dynamische, sich schnell ändernde Informationen dokumentiert werden müssen, ist beispielsweise die Papierform nicht geeignet. Ist die Dokumentation eindeutig? Werden Begriffe einheitlich und konsistent benutzt? Gibt es Widersprüche? Für den Fall, dass die Dokumentation dezentral organisiert ist: Passen die einzelnen Teile der Dokumentation zusammen? Ist die Dokumentation korrekt und beweiskräftig? Werden die richtigen Begriffe verwendet? Wurden beschriebene Änderungen tatsächlich durchgeführt oder wurde Änderung und Dokumentation zeitgleich veranlasst und die Änderung danach aus irgendwelchen Gründen doch nicht vollzogen? Den Autoren ist es auch schon einmal passiert, dass Dinge dokumentiert waren, die gar nicht mehr vorhanden waren. Sind die Änderungen an der Dokumentation nachvollziehbar? Ist beispielsweise ersichtlich, wann die letzte Änderung erfolgte (z.B. durch eine Änderungshistorie) und was von welchem alten Zustand in welchen neuen Zustand geändert wurde? Ist die Dokumentation klar und verständlich? Das gilt für den Aufbau und den Inhalt der Dokumentation. Sind spezielle Begriffe erläutert? Werden aus der Dokumentation die Zusammenhänge deutlich? Wird ein für Menschen lesbares Format verwendet? Ist die Dokumentation logisch und übersichtlich strukturiert? Wird (bei Textform) auf komplizierte Schachtelsätze und umständliche oder nichtssagende Formulierungen verzichtet? Ist die Dokumentation leicht anwendbar? Ist die Dokumentation aktuell? Besonders wenn die Dokumentation manuell erstellt und gepflegt wird, ist zu prüfen, ob der bestehende Zustand des Verfahrens und der Stand der Dokumentation übereinstimmen. Wird die Übereinstimmung überprüft? Wenn ja, wann? Wie kann nachvollzogen werden, dass eine Überprüfung stattfand? Wie ist sichergestellt, dass es auffällt, wenn Abweichungen auftreten oder eine Überprüfung nicht stattgefunden hat? Weiterhin ist wichtig, wie die Dokumentation aktuell gehalten wird. Gibt es einen Aktualisierungsprozess? Wenn ja, ist er kontinuierlich und regelmäßig oder nur, wenn sich etwas ändert? Wie ist dieser gestaltet? Wie wird kontrolliert, dass der Prozess so gelebt wird, wie er definiert wurde? Was geschieht, wenn der Prozess nicht so gelebt wird? Ist die Dokumentation leicht pflegbar? Ist aufgeführt, wer für die Dokumentation verantwortlich und wer für sie zuständig ist? Der Hersteller beschreibt (im Fall von Standardsoftware) in den Software-Handbüchern die Standardfunktionalitäten der Software, die internen technischen Prozesse und weitere Informationen, jedoch nur in dem Zustand „ab Werk“, d h. ohne Customizing, spezifische Konfigurationen usw. Der Implementierer beschreibt die Einrichtung des Systems, die Anpassung an die Gegebenheiten vor Ort, die Konfiguration, die Gestaltung von Rollen und Rechten etc. Der Betreiber erstellt Arbeitsanweisungen, definiert das Vorgehen bei Test und Abnahme, beschreibt die Einbindung in die IT-Prozesse etc.
96
5.5 Berechtigungskonzept Beispielhafte Prüfungsfragen für die Verfahrensdokumentation im Speziellen: Kann ein sachverständiger Dritter nur aufgrund der Verfahrensdokumentation das ITVerfahren sachlogisch und technisch verstehen? Sind alle hierzu benötigten Informationen enthalten? Ergeben sich aus der Verfahrensdokumentation die Zusammenhänge im Verfahren? Werden die Anforderungen, die die sachlogische Lösung an das Verfahren stellt, durch die technische Lösung erfüllt? Beispiel: Wenn das sachlogische Verfahren ein internationales Callcenter ist, dann sollte die technische Lösung mehrsprachig sein. Enthält die Verfahrensdokumentation alle Informationen zu Inhalt, Aufbau und Ablauf des Verfahrens? Gibt es eine Übersicht über die Dokumente bzw. Dokumentationsteile? Ist das Verfahren mithilfe der Verfahrensdokumentation für einen sachkundigen Revisor innerhalb einer angemessenen Zeit formell und inhaltlich prüfbar? Hier geht es nicht um das Verstehen des Verfahrens, sondern um die Prüfbarkeit. Ist ersichtlich, wo sich Verfahrenskomponenten befinden? Gibt es Hinweise zu Revisionszugängen, Prüfberechtigungen o.Ä.? Ist beschrieben, wo der Revisor Kontrollen im Verfahren finden kann und wie sie wirken? Wie wird sichergestellt, dass das Verfahren so gelebt wird, wie es in der Verfahrensdokumentation beschrieben ist? Praxistipp
Erstellen Sie eine Muster-Verfahrensdokumentation, um den Fachbereichen zu zeigen, wie eine solche Dokumentation zu verstehen und aufzubauen ist. Achten Sie darauf, dass das Muster inhaltlich zu Ihrem Unternehmen passt. Erklären Sie innerhalb der Revisionsberatung den Fachbereichen, wie mit der Dokumentation umgegangen werden sollte.
5.5
Berechtigungskonzept Um die Nachvollziehbarkeit sicherzustellen, muss im IT-Verfahren bekannt sein, wer als Benutzer im Verfahren tätig wird. Auch für die Gewährleistung der Sicherheit ist dies notwendig, besonders für den Schutz vor unbefugter Veränderung und unbefugter Kenntnisnahme. Auf moderne IT-Verfahren wird deshalb über logische Identitäten (z.B. Benutzerkennungen, Accounts) zugegriffen, die realen Objekten (Personen, aber möglicherweise auch ITSysteme) zugeordnet werden. Der Identitätsnachweis erfolgt über ein Authentifizierungsverfahren (Passwort, Token, Zertifikat, Biometrie). In der Autorisierung werden den logischen Identitäten, meist über Rollen oder Gruppen, einzelne Berechtigungen oder ganze Rechteprofile zur Durchführung von Funktionen und
97
5 Prüfung von IT-Verfahren zum Zugriff auf Daten zugeordnet. Reale Benutzer, logische Identitäten und die ihnen zugeordneten Rechte werden innerhalb einer oder mehrerer Benutzer- und Rechteverwaltung(en) verwaltet. Man findet hierfür auch den Begriff des Berechtigungssystems. Auf welche Weise die oben beschriebenen Zuordnungen vorgenommen werden, wird in der Verfahrenskomponente „Berechtigungskonzept“ festgelegt. Dieses Konzept beschreibt die verwendeten Gestaltungselemente (Rolle, Gruppe, Profil, Attribut usw.) und die Berechtigungsbedingungen. Diese über logische Funktionen (UND, ODER, NICHT) verknüpften Bedingungen legen statisch oder dynamisch fest, ob ein Recht von einer bestimmten Identität in einer bestimmten Situation ausgeübt werden darf oder nicht. Abbildung 5.5 zeigt dazu ein Beispiel, wann ein Mitarbeiter berechtigt ist, einen Dienstwagen der Stufe 4 (Sportwagen) zu fahren. Rolle Außendienstmitarbeiter
UND
Berechtigung
Identität
Attribut Umsatz > 15.000 €
Dienstwagen Stufe 4
Abbildung 5.5 Beispiel für Verknüpfungen und Berechtigungsbedingungen im Berechtigungskonzept
Aufgrund der hohen Bedeutung steht die Prüfung des Berechtigungskonzeptes und der tatsächlich eingerichteten Berechtigungen in den IT-Systemen bei Revisionsprüfungen eines IT-Verfahrens weit oben auf der Prüfungsliste. Beispielhafte Prüfungsfragen für das Berechtigungskonzept: Existiert ein Rollen- bzw. Berechtigungskonzept? Enthält es Angaben darüber, … ... welche Identitäten5, Rollen und Rechte vorhanden sind? ... wie die Zuordnung der Identitäten zu den Rollen und Rechten erfolgt? ... wie eine Identität zu einer Rolle oder einem Recht kommt? ... wie die Rollen und Rechte an die Identitäten vergeben werden (Prozess)? ... welche Identitäten über welche Rollen und Rechte verfügen sollen (Soll-Zustand)? Sind im Berechtigungskonzept die Rechte fein genug definiert, um ein „Need-to-know“6Prinzip zu ermöglichen? Ist im Berechtigungskonzept verankert, dass keine anonymen Accounts vorhanden sein dürfen? 5
Man spricht hier nicht von Benutzern, sondern von Identitäten, da auch andere Objekte im Unternehmen wie Server, Programme oder sogar Fahrzeuge Rechte besitzen können. 6 Beim Need-to-know-Prinzip verfügt eine Identität nur über die Rechte, die sie tatsächlich für ihre Aufgaben benötigt.
98
5.6 Prüfung der Verfahrensdaten Um nachvollziehen zu können, welche Identität welche Aktionen im System durchgeführt hat, sollten nur personalisierte Accounts zugelassen werden, keine Gast- oder Funktions-Accounts (z.B. „admin“). Wie wird verhindert, dass fiktive Identitäten angelegt werden können? Fiktive Identitäten sind Identitäten, die in der Realität nicht existieren. Mit ihrer Hilfe können unzulässige Aktionen durchgeführt oder Zweitzugänge (Backdoor) zum System installiert werden. Gibt es eine Funktionstrennung zwischen der Vergabe der Rolle und der Zuordnung von Rechten zu der Rolle? Wie ist das Antragsverfahren gestaltet? Wer legt fest, wer was darf? Wie sind die Anträge gegen Manipulation geschützt? Wo werden die Anträge archiviert? Wie kann nachvollzogen werden, wie die Vergabe der Rechte vonstatten ging (warum das Recht von wem wann an wen vergeben wurde)? Wie kann die aktuelle Rechtesituation ermittelt werden? Kann beispielsweise eine „Identity List“, d h. eine Liste aller Identitäten mit Name, Kennung und Rechten erzeugt werden? Kann eine „Reverse Identity List“ erzeugt werden, d.h. eine Liste aller Rechte und der Identitäten, die über ein bestimmtes Recht verfügen? Wie ist sichergestellt, dass die eingerichteten Rechte in den IT-Systemen mit den beantragten und genehmigten Rechten übereinstimmen? Wird das Berechtigungskonzept auf Aktualität überprüft? (Gibt es die Identität noch? Besitzt sie noch die Aufgaben, die Grundlage für die Rechtevergabe waren?) Werden nicht mehr benötigte Rechte gänzlich entfernt?
5.6
Prüfung der Verfahrensdaten Ebenfalls eine Verfahrenskomponente stellen die Daten dar, die im IT-Verfahren verarbeitet werden. Die Prüfung der Verfahrensdaten bezieht sich einerseits auf die Daten selbst (im Sinne von Architekturkomponenten), andererseits auf den Umgang mit den Daten (im Sinne von Nutzungs- und IT-Prozessen).
5.6.1
Anforderungen an Daten in der Planungsphase
In der Planung eines neuen IT-Verfahrens wird festgelegt, welche Daten vom Verfahren in welcher Weise verarbeitet werden sollen. Beispielhafte Prüfungsfragen im Hinblick auf die Planung der Verfahrensdaten (nachbetrachtend formuliert): Wo wurde erfasst, welche Daten im Verfahren existieren werden? An welcher Stelle ist dokumentiert, wie die Daten spezifiziert sind (Formate, gültige Wertebereiche usw.)?
99
5 Prüfung von IT-Verfahren Wurden Anforderungen an die Daten aufgestellt (erforderliche Verfügbarkeit, Zugriffschutz, Datenschutz, Richtigkeit, Genauigkeit, Vertraulichkeit usw.)? Wie können die Daten den im Verfahren tätigen Personen bzw. Rollen zugeordnet werden (wichtig für das Berechtigungskonzept)? Wurden die Zugriffsmöglichkeiten auf die Daten festgelegt (über Clients, über das Internet, direkt in der Datenbank)? Wurden Import- und Exportregeln erstellt? Wurde der Lebenszyklus der Daten im Verfahren definiert? Wurde definiert, wie und in welcher Form sie in das Verfahren gelangen (Erfassung, Berechnung, Import) und es wieder verlassen (Datentransfer, Datenausgabe, Datenlöschung)?
5.6.2
Dateneingabe, -verarbeitung und -ausgabe
Beispielhafte Prüfungsfragen für die Dateneingabe: Wer darf welche Daten eingeben? (vgl. Berechtigungskonzept) Welche automatischen Eingabekontrollen gibt es (z.B. Kontrolle auf unsinnige, leere, zu lange Eingaben)? Wie wird die Erfüllung der in der Planung definierten Anforderungen an Vollständigkeit, Richtigkeit, Vertraulichkeit, Genauigkeit usw. bei der Eingabe sichergestellt? Mit welchen Maßnahmen wird der Schutz personenbezogener Daten gewährleistet (Erhebung nur für Geschäftszweck, Sicherung der Vertraulichkeit, Verpflichtung auf Datenschutz usw.)? Wie können Fehleingaben erkannt werden? Gibt es Plausibilitätsprüfungen? Beispielhafte Prüfungsfragen für die Verarbeitung der Daten: Wie wird erreicht, dass sensible Daten vor, während und nach der Verarbeitung nicht unbefugt verändert werden können? Wie wird verhindert, dass Daten bei einer Übertragung, Archivierung usw. verändert werden? Werden übertragene Daten von der empfangenden Stelle überprüft? Welche Kontrollen sind im Verfahren gegen Datenfehler und Verfälschungen eingerichtet? Wie wird die Richtigkeit berechneter Ergebnisse garantiert? (z.B. durch Prüfsummen, Gegenrechnungen, Plausibilitätsprüfungen, eingeschleuste Testfälle, fiktive Vorgänge, Ablaufprüfungen anhand der Flussdiagramme, Einsatz von Prüfprogrammen, Ergebnisprüfungen, Source Code Audits, Programmbeweise usw.) Können Daten oder Verarbeitungsvorgänge versteckt werden (damit sie in Kontrolllisten, in Ausdrucken usw. nicht auftauchen)? Werden Verarbeitungsfehler protokolliert? Wann und auf welche Weise werden die Protokolle ausgewertet? Gibt es eine Meldung bei kritischen Fehlern und wenn ja, an wen? Wann trat zuletzt ein Verarbeitungsfehler
100
5.6 Prüfung der Verfahrensdaten auf und welcher Art war er (unvollständige, falsche, verspätete, unerlaubte Verarbeitung)? Wie sind kritische Verarbeitungsvorgänge abgesichert (Vier-Augen-Prinzip, Funktionstrennung)? Beispielhafte Prüfungsfragen für die Datenausgabe: Ist auch bei der Datenausgabe für den Schutz sensibler Daten gesorgt? (Keine sensiblen Informationen in Fehlermeldungen und der Benutzerdokumentation, Gewährleistung der Vertraulichkeit bei Ausdrucken, sichere Vernichtung bei Fehlausdrucken usw.) Wie ist sichergestellt, dass die Datenausgabe alle auszugebenden Daten enthält bzw. wie kann geprüft werden, ob alle Daten ausgegeben werden? (B.B. bei ausgeblendeten oder versteckten Daten) Sind die Daten auf dem richtigen Medium (Papier, CD, Bildschirm etc.) verfügbar? Wie werden Verzögerungen und damit Wartezeiten bei der Datenausgabe verhindert?
5.6.3
Datentransfer
Beispielhafte Prüfungsfragen für den Datentransfer: Wie wird garantiert, dass die Daten bei den richtigen Empfängern ankommen? Wie wird die Vertraulichkeit von sensiblen Daten während der Übertragung gesichert (z.B. durch Verschlüsselung)? Welche Verschlüsselungsverfahren, -algorithmen, Schlüssellängen usw. werden für eine Verschlüsselung eingesetzt? Wie kann erkannt werden, ob die Daten während der Übertragung verändert wurden? Erfolgt nach Empfang eine entsprechende Prüfung der Daten? Wie können die Daten auf Vollständigkeit geprüft werden (Prüfsummen, Größenvergleiche o.Ä.)? Erfolgt nach Empfang eine entsprechende Prüfung der Daten? Kann bei unvollständiger Übertragung oder Übertragungsfehlern der vorherige Zustand wieder hergestellt werden (Rollback)? Existiert eine Übersicht, welche Daten wann auf welche Weise von wo nach wo übertragen werden? Eine solche Übersicht über die Datenflüsse ist Teil der Verfahrensdokumentation.
5.6.4
Datensicherung und Archivierung
Bestandteil der Prüfung von Daten ist auch der Schutz vor Datenverlust und die langfristige Aufbewahrung von Daten. Hier können folgende, beispielhafte Prüfungsfragen gestellt werden:
101
5 Prüfung von IT-Verfahren Existiert eine dokumentierte, zweckerfüllende und den Daten angemessene Datensicherungsstrategie? Wie wird in der Praxis dafür gesorgt, dass sie nachhaltig umgesetzt („gelebt“) wird? Wie ist sichergestellt, dass im Notfall das Backup intakt und das Personal in der Lage ist, die Daten zeitnah wiederherzustellen? Wird das Backup getestet? Wird die Wiederherstellung getestet und geübt? Werden dabei nur Teile wiederhergestellt oder realitätsnah komplette Systeme bzw. Systemverbünde? Wie wird erreicht, dass das Backup im Stör- und Notfall verfügbar ist und verwendet werden kann? (Z.B. wenn die Feuerwehr bei einem Brand großflächig absperrt) Sind die Aufbewahrungspflichten und -fristen für die Daten bekannt und dokumentiert? Wo werden Sicherungen und Archive aufbewahrt und wer hat Zugriff darauf? Ist die Vertraulichkeit von sensiblen Daten auch in der Sicherung und im Archiv gewahrt? Ist der Aufbewahrungsort von Archiven für eine längerfristige Lagerung geeignet (Umweltbedingungen, Zugangsschutz)?
5.6.5
Datenmigration
Eine der IT-Lebenszyklusphasen ist die Phase, in der Änderungen, Aktualisierungen, Anpassungen und Umstellungen (Migrationen) der Hardware- und Software-Systeme vorgenommen werden. Migriert wird aufgrund des technischen Fortschritts, der Abkündigung von Produkten, dem Verschwinden von Herstellern oder aus Kostengesichtspunkten entweder von heute auf morgen („Big Bang“) oder schrittweise mit Parallelbetrieb von Altund Neusystem. Die Herausforderung bei einer Migration sind die inhaltliche Planung der Umstellung (insbesondere die Überführung des Datenbestands und der Funktionalitäten vom Alt- in das Neusystem) sowie das Management der Risiken und der Migrationsdurchführung. Folgende beispielhaft und nachbetrachtend formulierte Prüfungsfragen können sich im Hinblick auf eine Migration ergeben: Wurde im Vorfeld der Migration eine Migrationsstrategie erstellt? Wo wurde sie dokumentiert? Wurde auch dokumentiert, warum man sich für welches Vorgehen entschieden hat? Wurden beim Projektmanagement migrationsspezifische Aspekte berücksichtigt? Ein besonders wichtiger Aspekt ist die Existenz von Alternativen in allen Projektphasen, falls die geplante Migration nicht weitergeführt werden kann. Wurde geprüft, welche Ordnungsmäßigkeitsanforderungen durch die Migration berührt werden und wie ihnen entsprochen werden soll? Wurde die Einhaltung dieser Anforderungen kontrolliert? Für diesen Punkt empfiehlt es sich, vor einer Migration die IT-Revision beratend in Anspruch zu nehmen. Wichtig ist, dass die IT-Revision in keiner Weise operativ an der
102
5.6 Prüfung der Verfahrensdaten Migration beteiligt wird. Sie darf nicht am Design oder der Umsetzung des Neusystems mitwirken, ansonsten kann sie die Migration nicht nachbetrachtend prüfen (sonst würde sie sich teilweise selbst prüfen). Wurde die Verantwortung für eventuell vorhandene Teilsysteme und deren Zusammenspiel im Gesamtsystem geklärt? Praxistipp
In größeren Systemen mit mehreren Herstellern ist es ein beliebtes Spiel der Hersteller, sich bei Fehlern und Störungen gegenseitig die Schuld zuzuschieben. Prüfen Sie daher, ob bereits bei der Planung des Neusystems geklärt wurde, wer für welche funktionalen (nicht architektonischen!) Teilbereiche verantwortlich ist. Besonders wichtig ist, ob die Schnittstellen zwischen den Verantwortungsbereichen definiert und abgestimmt wurden.
Wurden vor und während der Migration die damit verbundenen Risiken kontinuierlich identifiziert und bewertet? Wie wurden Maßnahmen zur Risikobeherrschung eingeplant und umgesetzt? Welche Risiken wurden im Vorfeld der Migration betrachtet? Wurde geprüft, ob durch die Migration existenzgefährdende Risiken entstehen können? Gab es eine Zusammenarbeit mit dem Risikomanagement auf der Unternehmensebene? Welche Maßnahmen wurden ergriffen, um die Datenkonsistenz und -kontinuität zu sichern? Wurden alle Betroffenen in die Migration eingebunden? Wie wurde die Kommunikation zwischen den Betroffenen organisiert? Gab es Eskalationsstufen und definierte Schwellenwerte dazu? Gab es Vorgaben für die Zusammenarbeit mit dem Risikomanagement des Unternehmens und der IT? Gab es Meldewege hierfür? Wie wurde dafür gesorgt, dass die für die Migration notwendigen Personalkapazitäten, Migrationskenntnisse und Supportleistungen von Herstellern und Implementierern zur Verfügung standen? Wurden neben der technischen Migration auch die kaufmännischen Aspekte der Migration in der Migrationsstrategie berücksichtigt? (Z.B. die Vertragsgestaltung für das Neusystem)? Wie wird erreicht, dass nach der Migration auf archivierte Daten des Altsystems zugegriffen werden kann?
5.6.6
Datenlöschung und -entsorgung
Auch in der letzten Lebenszyklusphase müssen die Daten den Prüfungsaspekten entsprechen. Daher sind beispielhaft folgende Prüfungsfragen bedeutungsvoll:
103
5 Prüfung von IT-Verfahren Welche Anforderungen existieren für die Datenlöschung und -entsorgung7? Wo sind sie dokumentiert? Wie wurden sie kommuniziert? Wie werden sie kontrolliert? Wie wird die Vertraulichkeit der Daten auch auf dem Weg zu und während ihrer Löschung oder Entsorgung gewahrt? Wie wird kontrolliert, dass die Daten tatsächlich gelöscht oder entsorgt wurden? Wie wird erkannt, ob es noch Datenkopien gibt und ob diese ebenfalls gelöscht oder entsorgt wurden? Wie wird verhindert, dass aufbewahrungspflichtige Daten gelöscht oder entsorgt werden? Wie ist technisch, organisatorisch und rechtlich festgelegt, wer welche Daten löschen darf? Was geschieht im Fall einer ungewollten oder unberechtigten Löschung oder Entsorgung?
7
104
Der Begriff „Löschung“ bezieht sich auf die logische oder physikalische Entfernung von Daten in einem Speichermedium, während der Begriff „Entsorgung“ sich auf die physikalische Vernichtung von Datenträgern bezieht.
6 6 Besondere Prüfungsgebiete Die Prüfungsgebiete in der IT-Revision sind durch die jeweiligen gesetzlichen Vorschriften oder aufgrund anderer Richtlinien vorgeschrieben. In der letzten Zeit sind zwei Prüfungsgebiete besonders aktuell geworden: zum einen die Prüfung nach Konformität mit dem Bundesdatenschutzgesetz und zum anderen ein rechtssicheres Dokumentenmanagement. Beide Prüfungsgebiete wollen wir in diesem Kapitel näher erläutern.
6.1
Prüfungsgebiet Bundesdatenschutzgesetz Die Anforderungen, die das Bundesdatenschutzgesetz an die IT stellt, sind in Kapitel 3 erläutert. Doch wie soll ein Unternehmen dies nachweisen bzw. wie sollen Sie die Umsetzung prüfen? Dazu gibt es eine klare Aussage des Bundesbeauftragten für den Datenschutz und die Informationsfreiheit, die die Vorgehensweise für die Umsetzung der Anforderungen des BDSG beschreibt: „Der neue Baustein 1.5 zum Datenschutz in den IT-Grundschutzkatalogen des Bundesamtes für die Sicherheit in der Informationstechnik (BSI) wurde von den Datenschutzbeauftragten des Bundes und der Länder und den Aufsichtsbehörden der Länder für den nicht-öffentlichen Bereich als gemeinsame Basis erarbeitet und verabschiedet.“1 Die Anforderungen und Maßnahmen, die der Baustein 1.5 bereitstellt, basieren auf der gesamten Vorgehensweise nach BSI Grundschutz. Zwar kann eine vollständige Erfüllung der Anforderungen des BDSG in technischer, personeller und organisatorischer Hinsicht auch ohne die gesamte Vorgehensweise nach BSI sichergestellt werden. Jedoch ist der Mehrwert eines umfassenden Informationssicherheitsmanagements nicht von der Hand zu weisen. Wie Sie auf der Basis der Vorgaben des BSI Grundschutzes ein umfassendes Informationssicherheitsmanagement etablieren, sehen wir uns nun näher an. Schon imple-
1
Zu finden unter dem folgenden Link auf der Seite des Bundesbeauftragten für den Datenschutz und die Informationsfreiheit: http://www.bfdi.bund.de/cln_136/DE/Themen/TechnologischerDatenschutz/TechnologischeOrientierungshilfen/Artikel/Baustein1.5.html?nn=409206
105
6 Besondere Prüfungsgebiete mentierte bzw. unternehmenseigene Vorgehensweisen können mit dem in diesem Kapitel beschrieben Prüfungsansatz ebenfalls überprüft werden.
6.1.1
BSI Grundschutzstandards und -kataloge
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) ist der zentrale IT-Sicherheitsdienstleister des Bundes. Mit der Gründung des BSI am 01.01.1991 wurde den wachsenden Anforderungen an eine „sichere“ Informationstechnik durch die Bundesregierung Rechnung getragen. Das BSI hat für diese Anforderung ein Vorgehen entwickelt: das IT-Grundschutzhandbuch. Im Jahr 2005 wurde das IT-Grundschutzhandbuch durch die BSI Grundschutzstandards und -kataloge ersetzt. Die BSI Grundschutzstandards geben die Vorgehensweise vor, und die IT-Grundschutz-Kataloge beschreiben die Maßnahmen und die Gefährdungen. Die Standards sind: BSI-Standard 100-1: Managementsysteme für Informationssicherheit (ISMS) BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz BSI-Standard 100-4 Notfallmanagement Da seit dem 01.01.2006 die aktuellen Standards des BSI in Verbindung mit den IT-Grundschutz-Katalogen gelten, wird in diesem Kapitel vom Vorgehen nach BSI Grundschutz gesprochen. Dieses ist in dem aktuellen Standard 100-22 beschrieben. Die IT-Grundschutz-Kataloge sind wie folgt aufgebaut: Schichten Bei der Modellierung eines IT-Verbunds ist es zweckmäßig, die Zuordnung der Bausteine (siehe unten) anhand des Schichtenmodells vorzunehmen. Die Schichten innerhalb dieses Modells sind: Übergreifende Aspekte (hierzu zählt auch der Baustein 1.5 Datenschutz) Infrastruktur IT-Systeme Netze Anwendungen Bausteine Der Begriff dient zur Strukturierung von Empfehlungen der IT-Grundschutz-Kataloge. Bausteine sind die Einheiten innerhalb einer Schicht (z.B. IT-Systeme, Netze). In jedem Baustein werden die betrachteten IT-Komponenten und die Gefährdungslage beschrieben sowie organisatorische und technische Sicherheitsmaßnahmen empfohlen. Gefährdungskataloge Gefährdungskataloge sind Teil der IT-Grundschutz-Kataloge und enthalten Beschrei2
106
https://www.bsi.bund.de/grundschutz
6.1 Prüfungsgebiet Bundesdatenschutzgesetz bungen möglicher Gefährdungen der Informationstechnik. Sie sind in die Schadensursachen höhere Gewalt, organisatorische Mängel, menschliche Fehlhandlungen, technisches Versagen und vorsätzliche Handlungen gegliedert. Maßnahmenkataloge In den IT-Grundschutz-Katalogen werden zu jedem Baustein passende Maßnahmen empfohlen. Diese sind in weiteren Katalogen zusammengefasst, den Maßnahmenkatalogen, die in Infrastruktur, Organisation, Personal, Hardware/Software, Kommunikation und Notfallvorsorge gegliedert sind.
6.1.2
Vorgehen nach BSI Grundschutz
Die Vorgehensweise nach BSI Grundschutz beschreibt Schritt für Schritt, wie Informationssicherheit im Unternehmen implementiert werden kann. Diese Vorgehensweise ist im BSI Standard 100-2 beschrieben. Im Fokus stehen hier die Aufgaben des Sicherheitsmanagements und der Aufbau von Organisationsstrukturen für Informationssicherheit. Die Vorgehensweise geht sehr ausführlich darauf ein, wie ein Sicherheitskonzept in der Praxis erstellt werden kann, wie angemessene Sicherheitsmaßnahmen ausgewählt werden können, und was bei der Umsetzung des Sicherheitskonzeptes zu beachten ist. Die gesamte Vorgehensweise ist nach dem PDCA-Modell (Plan-Do-Check-Act)3 aufgebaut. Damit werden alle Belange behandelt, auch die der Aufrechterhaltung im laufenden Betrieb und der Verbesserung. Im Zusammenspiel mit den IT-Grundschutz-Katalogen wird in der IT-Grundschutz-Vorgehensweise nicht nur erklärt, was gemacht werden sollte, sondern es werden auch konkrete Hinweise gegeben, wie die Umsetzung aussehen kann. Die grundlegende Maxime des Vorgehens nach BSI Grundschutz ist: „Durch infrastrukturelle, organisatorische, personelle und technische StandardSicherheitsmaßnahmen ein Standard-Sicherheitsniveau für IT-Systeme aufbauen, das auch für sensiblere Bereiche ausbaufähig ist.“ Abbildung 6.1 auf der nächsten Seite zeigt im Überblick das Vorgehen, nachdem ein ITVerbund definiert worden ist (dazu gleich mehr). Dieses Vorgehen wird in den folgenden Abschnitten ausführlicher beschrieben. 6.1.2.1
Abgrenzung des IT-Verbundes
Als Basis für die Strukturanalyse gilt es zunächst, einen IT-Verbund als Gesamtheit aller technischen Komponenten zur Ausführung einer Fachaufgabe festzulegen. Dabei ist eine sinnvolle Mindestgröße zu wählen. Aus Gründen der Umsetzbarkeit und Prüfbarkeit sollte
3
Kamiske, G. F.; Brauer, J.-P.: Qualitätsmanagement von A bis Z. München: Carl Hanser Verlag, 1995
107
6 Besondere Prüfungsgebiete IT-Strukturanalyse Netzplan Erhebung Systeme und Anwendungen (Analyse des Ist-Zustands)
Schutzbedarfsfeststellung arfsf
IT-Grundschutzanalyse chu Modellierung des IT-Verbundes Soll-Ist-Vergleich (Basis-Sicherheitscheck)
Normaler Schutzbedarf
EErg. Sicherheitsanalyse Si h h bei hohem Schutzbedarf
Konsolidierungg der Maßnahmen
Realisierung der Maßnahmen Abbildung 6.1 Vorgehen nach BSI 100-2 für einen bestimmten IT-Verbund [BSI 06]
der IT-Verbund, wenn möglich, nicht zu groß gewählt werden. Eine grafische Darstellung des betrachteten Verbundes ist hilfreich. Ein IT-Verbund könnte z.B. sein: Die gesamte IT einer Institution Ein einzelner Bereich (z.B. Abteilungsnetz) Gemeinsame Geschäftsprozesse bzw. IT-Anwendungen (z.B. CRM) 6.1.2.2
Strukturanalyse
In der Strukturanalyse werden alle dem IT-Verbund zugehörigen Objekte erfasst und gruppiert. Folgende Teilschritte sind hier durch die Verantwortlichen durchzuführen: Erstellung bzw. Aktualisierung eines Netzplans Erhebung der IT-Systeme Erhebung der Gebäude und Räume Komplexitätsreduktion durch Gruppenbildung Erfassung der IT-Anwendungen und der zugehörigen Informationen Die Ergebnisse der einzelnen Schritte können in Tabellen oder in Grafiken niedergelegt sein. Die Abbildungen 6.2 und 6.3 zeigen zwei mögliche Darstellungen der Ergebnisse in Tabellen. Die Abbildung 6.4 zeigt den bereinigten Netzplan als Ergebnis der Komplexitätsreduzierung.
108
6.1 Prüfungsgebiet Bundesdatenschutzgesetz Erfassung der Räume Kürzel
Name
Subtyp
Gebäude
Anzahl
R01-01
Zentraler Servrraum
Serverraum
G01-01
1
R01-02
Büroraum Typ 1
Büroraum
G01-01
2
R01-03
Lagerraum
Datenträgerarchiv
G01-01
1
R01-04
Büroraum Typ 2
Büroraum
G01-02
3
R02-01
Serverraum redundant
Serverraum
G02-01
1
R02-02
Büroraum Typ 3
Büroraum
G02-01
3
R02-03
Büroraum Typ 3
Büroraum
G02-02
2
Datenträger
Backup XY
Abbildung 6.2 Tabelle der erfassten Räume Erfassung der IT-Systeme Kürzel
Name
Subtyp
Anzahl
Raum
Status
Administrator
S01-01
Server Personalverwaltung
Server unter Windows 2000
1
R01-01
in Betrieb
Schneider
S01-02
Server Exchange Server unter 1 Windows Server 2003
R01-01
in Betrieb
Schneider
C01-01
Beratungsdienst
Gruppe von Clients unter Windows XP
4
R01-02
in Betrieb
Bergmann
C01-02
Call Center
Gruppe von Clients unter Windows XP
4
R01-04
in Betrieb
Bergmann
X01-01
Firewall
Sicherheitsgateway
1
R01-01
in Betrieb
Schneider
X01-02
Router zum Internet-Zugang
Router Switches
1
R01-01
in Betrieb
Schneider
Abbildung 6.3 Tabelle der erfassten IT-Systeme
Jedes Objekt kann nach bestimmten Anforderungen gruppiert werden. Komponenten können nur dann ein und derselben Gruppe zugeordnet werden, wenn die Komponenten alle vom gleichen Typ sind, (hier sind die Objekttypen des BSI Grundschutzes gemeint wie z.B. Client, Server, Räume) gleich oder nahezu gleich konfiguriert sind, gleich oder nahezu gleich in das Netz eingebunden sind, den gleichen administrativen und infrastrukturellen Rahmenbedingungen unterliegen und die gleichen Anwendungen bedienen, den gleichen Schutzbedarf aufweisen.
109
6 Besondere Prüfungsgebiete
Abbildung 6.4 Bereinigter und gruppierter Netzplan
Um die Komplexität zu reduzieren, müssen nicht alle Anwendungen erfasst werden. Für eine geeignete Auswahl sollten mindestens diejenigen Anwendungen aufgelistet werden, deren Daten bzw. Informationen und Programme einen hohen Bedarf an Geheimhaltung (Vertraulichkeit) besitzen, deren Daten bzw. Informationen und Programme einen hohen Bedarf an Unverfälschtheit (Integrität) besitzen, die eine kurze tolerierbare Ausfallzeit (hoher Bedarf an Verfügbarkeit) haben. Diese Anwendungen sollten in einer Tabelle erfasst werden. Abbildung 6.5 zeigt ein Beispiel. Erfassung der IT-Anwendungen Kürzel
Name
Personenbezogene Daten
IT-Systeme
A01-01
Personalverwaltung Datenbank
Subtyp
Ja
S01-01
A01-02
Kundenverwaltung
Datenbank
Nein
S01-01
A01-03
Exchange
Exchange 2000
Ja
S01-02
Abbildung 6.5 Erfassung der IT-Anwendungen
110
6.1 Prüfungsgebiet Bundesdatenschutzgesetz Es ist nicht immer ganz einfach zu unterscheiden, welche Anwendungen erfasst werden sollen und welche nicht. Ein Beispiel
Ein Unternehmen besitzt einen Webshop, in dem alle geschäftskritischen Aufgaben erfüllt werden. Dieser Webshop ist in den Augen des Unternehmens eine sehr wichtige Anwendung. Das E-Mail-System hingegen wurde ursprünglich als nicht kritisch angesehen. Dies wurde geändert, als bei einem Absturz des E-Mail-Systems keine Anfragen zu Produkten und Bezahlungen etc. mehr beantwortet werden konnten. Kurze Zeit später kursierte das Gerücht im Internet, der Webshopbesitzer sei insolvent, da keine Antworten auf Beschwerden und Nachfragen gegeben wurden.
Wie Sie sehen, kann eine auf den ersten Blick unkritische Anwendung unter bestimmten Voraussetzungen doch kritisch werden. Um hier die geeigneten Entscheidungen zu treffen und diese auch nachvollziehbar zu gestalten, wird innerhalb des Vorgehens nach BSI Grundschutz die Schutzbedarfsfeststellung durchgeführt, die an späterer Stelle in diesem Kapitel erläutert wird. Die vorherigen Beispieltabellen stellen die Ergebnisse einer Strukturanalyse dar. Um eine Zuordnung der einzelnen Objekte bzw. Gruppierungen zueinander dauerhaft sicherzustellen, bedarf es einer geeigneten Nomenklatur. Um die einzelnen Objekte des IT-Verbundes jederzeit zuordnen zu können, sollte diese Nomenklatur einem Schema entsprechen, für das Abbildung 6.6 ein Beispiel darstellt. Gegenstand
Kenner
Gebäude
G
Beispiel G01-01
Raum
R
R01-01
Router/Switches
X
X01-01
Server
S
S01-01
Virtueller Server
VS
VS01-01
Clients
C
C01-01
Laptops
L
L01-01
PDA, mobile Geräte
M
M01-01
Drucker im Netz
D
D01-01
Netze
N
N01-01
Anwendungen
A
A01-01
Abbildung 6.6 Nomenklatur für die Strukturanalyse
Die Erfahrungen der letzten Jahre haben gezeigt, dass die Auflistung und Zuordnung der Anwendungen, also die reine physikalische Erfassung (z. B. mithilfe von Inventarlisten), nicht mehr ausreichend ist. Wichtige Anwendungen werden heute zum Teil auf virtuellen Umgebungen betrieben. Die Zuordnung zu einem physikalischen System ist für eine korrekte Umsetzung der Vorgehensweise nach BSI Grundschutz aber unverzichtbar. Um dieser Anforderung gerecht zu werden, empfiehlt sich die in Abbildung 6.7 gezeigte Darstellung eines virtuellen Systems.
111
6 Besondere Prüfungsgebiete
Virtueller Server 1 VS01_01_01 Server unter Windows 2003 Anzahl: 1
Virtueller Server 2 VS01_01_02 Server unter UNIX/Linux Anzahl: 1
Virtueller Server 3 VS01_01_03 Server unter Windows 2000 Anzahl: 1
Virtualisierungsserver S01_01 Server unter UNIX/Linux Anzahl: 1
6.1.2.3
Abbildung 6.7 Darstellung virtueller Server in der Strukturanalyse
Einteilung in Schutzbedarfskategorien
Über die Schutzbedarfskategorie werden die (maximalen) Schäden ermittelt, die bei Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit entstehen können. Es gibt drei Schutzbedarfskategorien mit den folgenden Bedeutungen: Normal: Die Schadensauswirkungen sind begrenzt und überschaubar. Maßnahmen des IT-Grundschutzes reichen im Allgemeinen aus. Hoch: Die Schadensauswirkungen können beträchtlich sein. IT-Grundschutzmaßnahmen alleine sind ggf. nicht ausreichend. Weitergehende Maßnahmen sollten auf Basis einer individuellen Risikoanalyse ermittelt werden. Sehr hoch: Die Schadensauswirkungen können ein existenziell bedrohliches, katastrophales Ausmaß erreichen. IT-Grundschutzmaßnahmen alleine reichen im Allgemeinen nicht aus. Die erforderlichen Sicherheitsmaßnahmen müssen individuell auf der Grundlage einer Risikoanalyse ermittelt werden. Diese Schutzbedarfskategorien werden mit den nachfolgend aufgeführten Schadensklassen zusammengeführt und ergeben so einen an das Unternehmen angepassten Leitfaden zur Ermittlung des Schutzbedarfs. Schadensklassen stellen die möglichen Folgen eines Verlustes von Integrität, Vertraulichkeit und Verfügbarkeit dar. Die einzelnen Schadensklassen nach dem Vorgehen nach BSI Grundschutz sind:
112
6.1 Prüfungsgebiet Bundesdatenschutzgesetz Verstoß gegen Gesetze, Vorschriften, Verträge Beispiele: Interne Informationen werden an die Presse weitergeleitet. Buchhaltungsdaten werden verfälscht. Lieferfristen werden nicht eingehalten. Beeinträchtigung des informationellen Selbstbestimmungsrechts Beispiele: Logfiles werden ausgewertet, um eine Arbeitsüberwachung durchzuführen. Inhalte von Personalakten werden veröffentlicht. Beeinträchtigung der persönlichen Unversehrtheit Beispiele: Verkehrsleitsystem fällt aus. Informationen über verdeckte Ermittler werden bekannt. Beeinträchtigung der Aufgabenerfüllung Beispiele: Verspätete Lieferung aufgrund verzögerter Bearbeitung von Bestellungen. Mailsystem für Kundenrückfragen fällt aus. Negative Außenwirkung auf die Reputation Beispiele: Ansehensverlust einer Behörde bzw. eines Unternehmens bei Datenpannen. Beeinträchtigung der wirtschaftlichen Beziehungen zusammenarbeitender Unternehmen. Finanzielle Auswirkungen Die Höhe des Gesamtschadens setzt sich zusammen aus den direkt und indirekt entstandenen Kosten (Sachschaden, Schadensersatzleitungen und Kosten für zusätzlichen Aufwand, z.B. Wiederherstellung). 6.1.2.4
Schutzbedarfsfeststellung
Um die Schutzbedarfe Ihrer IT festzustellen oder deren Zuordnung zu prüfen, kann es sinnvoll sein, den Schutzbedarf aus einer ganzheitlichen Sicht der Geschäftsprozesse oder Fachaufgaben zu betrachten. Bedeutung
Geschäftsprozess bzw. Fachaufgabe
normal
... kann mit tolerierbarem Mehraufwand mit anderen Mitteln (z.B. manuell) durchgeführt werden
hoch
... kann nur mit deutlichem Mehraufwand mit anderen Mitteln durchgeführt werden
sehr hoch
... kann nicht durchgeführt werden
Abbildung 6.8 Schutzbedarfsermittlung
113
6 Besondere Prüfungsgebiete Dazu bietet es sich an, den Zweck einer IT-Anwendung in einem Geschäftsprozess oder in einer Fachaufgabe zu beschreiben und daraus wiederum deren Bedeutung abzuleiten. Wie Sie die Bedeutung beschreiben können, zeigt Abbildung 6.8. Der Schutzbedarf wird von den Anwendungen auf die Systeme und von dort auf die Räume und Gebäude vererbt. Dies geschieht nach den folgenden Prinzipien: Maximum-Prinzip: Die IT-Anwendung mit dem höchsten Schutzbedarf auf dem IT-System bestimmt den Schutzbedarf. Beachtung von Abhängigkeiten: Wenn IT-Anwendungen Arbeitsergebnisse anderer IT-Anwendungen als Input nutzen, muss der Schutzbedarf eventuell angepasst werden. Kumulationseffekt: Mehrere kleine Anwendungen auf einem IT-System können zu einem hohen Schutzbedarf führen, wenn die Schäden der Einzelanwendungen zusammengenommen einen hohen Schaden verursachen. Verteilungseffekt: Läuft die Anwendung auf mehreren IT-Systemen (meist Verfügbarkeit), so erben alle Teilsysteme den Schutzbedarf der gesamten Anwendung. Bei den Kommunikationsverbindungen sieht dies etwas anders aus. Der Schutzbedarf wird nur für kritische Verbindungen festgestellt, um die Komplexität zu reduzieren. Kritische Kommunikationsverbindungen sind: Außenverbindungen Verbindungen, über die hochschutzbedürftige Informationen übertragen werden müssen Verbindungen, über die hochschutzbedürftige Informationen keinesfalls übertragen werden dürfen 6.1.2.5
Modellierung
In der Modellierung werden die ermittelten Objekte den Bausteinen der IT-GrundschutzKataloge zugeordnet. Dies erfolgt auf eine durch das BSI festgelegte Weise. Erheblich vereinfachen lässt sich dieses Verfahren durch die Verwendung geeigneter Software, wie z.B. das GSTOOL. Durch dieses vom BSI vertriebene Werkzeug lässt sich der IT-Sicherheitsprozess sehr gut begleiten. Die Zuordnung der Bausteine eines IT-Verbundes wird anhand der Tabellen in den Abbildungen 6.9 bis 6.11 vorgenommen.
114
6.1 Prüfungsgebiet Bundesdatenschutzgesetz 1.0
IT-Sicherheitsmanagement
1.1
Organisation
mindestens einmal für den IT-Verbund
einmal für den IT-Verbund
1.2
Personal
mindestens einmal für den IT-Verbund
1.4
Datensicherungskonzept
einmal für den IT-Verbund
1.6
Computer-Virenschutzkonzept
1.9
Hard- und Software-Management
mindestens einmal für den IT-Verbund
einmal für den IT-Verbund
1.10
Standardsoftware
mindestens einmal für den IT-Verbund
1.13
IT-Sicherheitssens bilisierung und -schulung
einmal für den IT-Verbund
2.1
Gebäude
einmal für den IT-Verbund
2.2
Verkabelung
einmal für den IT-Verbund
Abbildung 6.9 Immer anzuwendende Bausteine 1.3
Notfallvorsorge-Konzept
1.7
Kryptokonzept
Verfügbarkeit (sehr) hoch Vertraulichkeit/Verfügbarkeit (sehr) hoch
1.8
Behandlung von Sicherheitsvorfällen
1.11
Outsourcing
Externer Dienstleister wird eingesetzt
ein Grundwert (sehr) hoch
1.12
Archivierung
Langzeitarchivierung erforderlich
Abbildung 6.10 Bedingt anzuwendende Bausteine der übergreifenden Aspekte 2.3
Büroraum
Für jeden Raum mit IT, falls kein folgender Raum herangezogen wird
2.4
Serverraum
Für jeden Raum mit Servern oder TK-Anlagen
2.5
Datenträgerarchiv
Für jeden Raum mit Datenträgern
2.6
Raum für technische Infrastruktur
Für jeden Raum, in dem technische Geräte betrieben werden, die keine oder nur wenig Bedienung erfordern (Verteilerschrank)
2.7
Schutzschränke
2.8
Häuslicher Arbeitsplatz
2.9
Rechenzentrum
Für jedes RZ (B 2.4 muss nicht angewendet werden)
2.10
Mobiler Arbeitsplatz
Bei wechselnden Arbeitsplätzen
2.11
Besprechungs-, Veranstaltungsund Schulungsräume
Abbildung 6.11 Bedingt anzuwendende Bausteine der Infrastrukturschicht
6.1.2.6
Basis-Sicherheitscheck (BSC)
Die modellierten Bausteine geben die Maßnahmen vor, die bei einem Soll/Ist-Vergleich den schon realisierten Maßnahmen gegenübergestellt werden. Die Bewertung des Umsetzungsgrades stellt sich wie folgt dar:
115
6 Besondere Prüfungsgebiete Ja: Die Maßnahme ist vollständig und wirksam umgesetzt. Entbehrlich: Es gibt andere adäquate Maßnahmen oder die zu schützende Funktionalität ist nicht vorhanden. Teilweise: Die Maßnahme ist teilweise umgesetzt. Nein: Die Maßnahme ist nicht umgesetzt. Der BSC folgt wie die gesamte Vorgehensweise dem PDCA-Modell (siehe Abbildung 6.12). Ermitteln der notwendigen Maßnahmen
Erarbeiten der Interviewfragebögen
Befragung der Verantwortlichen
Ermitteln der Verantwortlichen
Abbildung 6.12 PDCA-Zyklus der Befragung
Um den Ist-Stand zu ermitteln, ist eine Befragung der verantwortlichen Personen notwendig. Dies kann, wie in Abbildung 6.12 beschrieben, mithilfe eines Interviewbogens erfolgen. Die relevanten Fragen sind durch das Bundesamt für Sicherheit in der Informationstechnik4 beschrieben worden. 6.1.2.7
Ergänzende Sicherheitsanalyse
Wenn alle Maßnahmen der Grundschutz-Kataloge durchgeführt wurden, stellt sich noch folgende Frage: Was geschieht mit den Objekten (Anwendungen, Systeme, etc.), für die ein hoher oder sehr hoher Schutzbedarf festgestellt worden ist, für die es keinen Baustein gibt (z. B. J2EE Application Server), die in Einsatzszenarien (Umgebung, Anwendungen) betrieben werden, die im Rahmen des IT-Grundschutzes nicht vorgesehen sind (z. B. Online-Banking-Angebot eines Finanzdienstleisters) oder IT-Systeme mit speziellen Echtzeitbetriebssystemen (Marathon)? Für diese Objekte muss eine ergänzende Sicherheitsanalyse durchgeführt werden. In einem Management-Report ist für jedes Zielobjekt, das eine oder mehrere der gerade genannten 4
116
https://www.bsi.bund.de
6.1 Prüfungsgebiet Bundesdatenschutzgesetz Eigenschaften hat, stichhaltig zu begründen, ob eine weitere Risikobetrachtung erforderlich ist oder nicht. Sollte diese Frage mit Nein beantwortet werden, so reichen die getroffenen Maßnahmen der Grundschutz-Kataloge aus. Sollte jedoch eine Risikoanalyse notwendig sein, sollte sie nach dem BSI Grundschutzstandard 100-3 durchgeführt werden. Dieser beschreibt folgende Aufgaben: Ermitteln Sie zusätzliche Risiken. Bewerten Sie diese Risiken. Erstellen Sie einen Plan zum Umgang mit den Risiken.
6.1.3
Umsetzung der Vorgaben anhand eines Sicherheitsrahmenkonzeptes
Das Vorgehen nach BSI Grundschutz hat einen großen Haken. Bei größeren IT-Verbünden ist es kaum oder nur mit erheblichem Aufwand umzusetzen. Bei größeren Unternehmen bietet es sich deshalb an, ein Sicherheitsrahmenkonzept zu entwickeln, wie es im Folgenden beschrieben wird. 6.1.3.1
Das Sicherheitsrahmenkonzept
Das Sicherheitsrahmenkonzept besteht aus zwei Teilen: Sicherheitsrahmenkonzeptdokument: Dieses Dokument beinhaltet alle nur einmal zu betrachtenden Objekte (übergreifende Aspekte) sowie üblicherweise Gebäude, Räume und Netze. Konzepte für Fachverfahren Dieses Konzept beinhaltet alle verfahrensspezifischen Komponenten (IT-Systeme, Anwendungen, eventuell Netze). übergreifende Aspekte Gebäude Räume Netze
SRK
Sicherheitsrahmenkonzept
Fachverfahren
IT-Systeme evtl. Netze Anwendungen Mitarbeiter
A
B IT-Systeme evtl. Netze Anwendungen Mitarbeiter
C IT-Systeme evtl. Netze Anwendungen Mitarbeiter
Abbildung 6.13 Sicherheitsrahmenkonzept, allgemeine Struktur
117
6 Besondere Prüfungsgebiete Gebäude, Räume und Netze werden mit den Objekten verknüpft, die im Sicherheitsrahmenkonzept abgebildet und für das Fachverfahren relevant sind. Abbildung 6.13 veranschaulicht den Aufbau eines Sicherheitsrahmenkonzepts. Die Abbildung der BSI Grundschutzvorgehensweise mit einem Sicherheitsrahmenkonzept ist nicht nur ab einer bestimmten Unternehmensgröße sinnvoll, sondern auch dann, wenn einzelne Verfahren auditiert oder geprüft werden sollen (z.B. Rechnungslegung nach GdPdU) oder falls mehrere Standorte betrachtet werden sollen. 6.1.3.2
Pro und Contra
Der Aufwand für die Umsetzung eines Sicherheitsrahmenkonzepts ist nicht zu unterschätzen, auch wenn er nur einmalig bei der Implementierung anfällt. Dem stehen die folgenden Vorteile gegenüber, die den Aufwand rechtfertigen könnten: Ein Sicherheitsrahmenkonzept mit seinen gegliederten Fachverfahren ist übersichtlicher als ein großer IT-Verbund. Das Unternehmen kann die Prüfung einzelner Verfahren oder Geschäftsprozesse vornehmen, sodass gezielt gearbeitet werden kann. Das Anfügen neuer Anwendungen (Verfahren/Geschäftsprozesse) ist ohne große Änderungen möglich. Durch Mehrfachnutzung entstehen Synergieeffekte. Beim Abbilden eines Sicherheitsrahmenkonzeptes sollten Sie Folgendes beachten: Wichtig!
Das Rahmenkonzept muss als eigener IT-Verbund abgebildet werden. Jedes zu betrachtende Fachverfahren muss ebenfalls als eigener IT-Verbund abgebildet werden.
6.1.4
Audit eines Informationssicherheitsmanagementsystems (ISMS) nach BSI Grundschutz
6.1.4.1
Allgemeines
Für die IT eines Unternehmens ist es von Vorteil, diese BSI Grundschutzvorgehensweise einzuführen. Doch wie können Sie als Prüfer diesen Prozess überprüfen? Da es sich bei dem Vorgehen nach BSI Grundschutz um einen standardisierten Prozess handelt, wurde ein Audit-Schema für eine etwaige Zertifizierung vorgegeben. Es enthält die Vorgaben für die lizenzierten Auditoren des BSI. Diese Vorgaben können Sie aber ebenfalls nutzen. Praxistipp
Es hat sich in der Praxis bewährt, für die definierten IT-Verbünde ein sogenanntes Pre-Audit durchzuführen. Dies kann, wenn es nach dem Schema durchgeführt wird, zu einer erheblichen Zeitersparnis beim „richtigen“ Audit führen, da etwaige Defizite schon behandelt werden können.
118
6.1 Prüfungsgebiet Bundesdatenschutzgesetz Falls ein Unternehmen sich nicht zertifizieren lassen will, sollte jedoch zur Prüfung des Vorgehens ein internes Audit auf Basis des Audit-Schemas erfolgen. Nur solche Audits verhindern eine „Feigenblatt-Politik“, in der die erstellten Dokumente und Maßnahmen nur als Alibi fungieren. Mit einer stetigen Verbesserung hat dies dann nichts mehr zu tun. 6.1.4.2
Durchführung
Die Durchführung des Audits besteht aus zwei Phasen: zum einen aus der Dokumentensichtung, zum anderen aus der Stichprobenprüfung. Die Dokumentensichtung kann durch den Auditor/Revisor im Vorfeld einer Stichprobenprüfung durchgeführt werden, da Fehler in der Dokumentation zuerst behoben werden sollten. Dies spart Zeit und Ressourcen bei den zu prüfenden Unternehmensbereichen. Eine Stichprobenprüfung sollte dann vor Ort durchgeführt werden. Die Entscheidung, welche Stichproben genommen werden, sollte unbedingt im Prüfungsplan dokumentiert werden. Die folgenden Punkte sind durch den Auditor/Revisor zu prüfen: Überprüfung der IT-Strukturanalyse Nachvollziehbarkeit der Abgrenzung des IT-Verbunds (Dokumentensichtung) Aktualität der Version des IT-Grundschutzhandbuchs (Dokumentensichtung) Identifizierbarkeit der Komponenten im bereinigten Netzplan (Stichprobenprüfung) Umfang der Liste der IT-Systeme (Dokumentensichtung, Stichprobenprüfung) Konformität der Liste der IT-Systeme mit dem Netzplan (Stichprobenprüfung) Umfang der Liste der IT-Anwendungen (Dokumentensichtung, Stichprobenprüfung) Überprüfung der Schutzbedarfsfeststellung Plausibilität der Definition der Schutzbedarfskategorien (Dokumentensichtung) Vollständigkeit der Schutzbedarfsfeststellung der IT-Anwendungen (Dokumentensichtung, Stichprobenprüfung) Vollständigkeit der Schutzbedarfsfeststellung der IT-Systeme (Dokumentensichtung, Stichprobenprüfung) Plausibilität der Schutzbedarfsfeststellung der IT-Systeme (Dokumentensichtung) Kritikalität der Kommunikationsverbindungen (Dokumentensichtung) Überprüfung der Modellierung des IT-Verbundes Nachvollziehbarkeit der Modellierung (Dokumentensichtung) Anwendbarkeit des IT-Grundschutzhandbuchs. Der überwiegende Teil des IT-Verbunds muss direkt durch entsprechende Bausteine des IT-Grundschutzhandbuchs modelliert sein (Dokumentensichtung, Stichprobenprüfung). Korrektheit der Gruppenbildung (Dokumentensichtung, Stichprobenprüfung) Überprüfung der IT-Grundschutzerhebung Konformität zur Modellierung (Dokumentensichtung, Stichprobenprüfung) Transparenz der Interviewpartner (Stichprobenprüfung) Umsetzungsgrad der IT-Grundschutzmaßnahmen (Stichprobenprüfung)
119
6 Besondere Prüfungsgebiete Überprüfung der ergänzenden Sicherheits- und Risikoanalyse Vollständigkeit und Plausibilität der ergänzenden Sicherheitsanalyse (Dokumentensichtung) Vollständigkeit und Plausibilität der ergänzenden Risikoanalyse (Dokumentensichtung) Umsetzungsgrad aller Maßnahmen (Stichprobenprüfung) Inspektion vor Ort Verifikation des Netzplans (Stichprobenprüfung) Verifikation der Liste der IT-Systeme (Stichprobenprüfung) Verifikation des Basis-Sicherheitschecks (Stichprobenprüfung) Verifikation der Umsetzung der zusätzlichen Maßnahmen aus der ergänzenden Risikoanalyse (Stichprobenprüfung) Zu guter Letzt werden die Ergebnisse der Dokumentensichtung und der Stichprobenprüfung dokumentiert und in den Audit-Bericht aufgenommen. Bei der Planung von Prüfungen nach BSI Grundschutz bietet es sich an, sich im Vorfeld die aktuellste Version des Audit-Schemas zu holen. Dieses Schema und alle Informationen finden Sie auf der Website des BSI: https://www.bsi.bund.de/. Mit diesen Hinweisen können Sie sowohl in Ihrem Unternehmen ein ISMS nach BSI Grundschutzvorgehen implementieren als auch dessen Umsetzung überprüfen. Dieses Thema ist so umfangreich, dass man ein ganzes Buch dazu schreiben könnte. Hier haben wir uns auf die Elemente beschränkt, die auch langfristig gelten und nicht bei Erscheinen des Buches schon überholt sind. Die beschriebenen Punkte sollten Ihnen jedoch ausreichend Hilfestellung für den Einstieg in das Thema geben.
6.2
Prüfungsgebiet Dokumentenmanagement Mit dem Schlagwort „papierloses Büro“ wird den Unternehmen schon länger Einsparungspotenzial versprochen. Die damit zusammenhängenden gesetzlichen Anforderungen sind aber bisher wie bei allen „Hype-Themen“ kaum beachtet worden. Der Gesetzgeber hat hier einige Anforderungen definiert, deren Erfüllung Sie prüfen müssen. In diesem Abschnitt möchten wir Ihnen eine Vorgehensweise zur Prüfung von Dokumentenmanagementsystemen (DMS) erläutern.
6.2.1
Welche Rahmenbedingungen gibt es?
Welche allgemeinen Rahmenbedingungen des Gesetzgebers es für die IT gibt, haben wir in Kapitel 3 beschrieben. Die allgemeinen Anforderungen aufgreifend, konkretisieren sich die gesetzlichen Anforderungen an Dokumentenmanagementsysteme vor allem im Bereich der Aufbewahrungspflicht von Unterlagen. Die Aufbewahrungspflicht findet sich in den Bereichen Handelsrecht und Steuerrecht wieder. Abbildung 6.14 soll dies verdeutlichen.
120
6.2 Prüfungsgebiet Dokumentenmanagement
Aufbewahrungspflicht Handelsrechtlich § 257 HGB: Freie Wahl, ob papierbasiert oder ausschließlich digitale Aufbewahrung, wenn GoB/GoBS erfüllt sind.
Steuerrechtlich AO/UStG/GDPdU Aufbewahrung von Unterlagen, die für die Besteuerung von Bedeutung sind.
GoBS: Das Verfahren der DV-Buchführung muss durch eine Verfahrensdokumentation, …, verständlich und nachvollziehbar gemacht werden.
GDPdU verweisen auf HGB und GoBS
Abbildung 6.14 Gesetzliche Anforderungen an DMS
Dass es eine Aufbewahrungspflicht gibt, ist also klar. Doch welchen Ausprägungen, welchen Kernkriterien soll diese Pflicht gerecht werden? Der Gesetzgeber nennt hier fünf Kernkriterien: Ordnungsmäßigkeit Erfüllung rechtlicher Rahmenbedingungen Eindeutige Indexierung, zeitliche und sachliche Einordnung Bildliche Übereinstimmung/inhaltliche Übereinstimmung Vollständigkeit Lückenlose Erfassung und Aufbewahrung Verlustfreie Reproduktion während der Aufbewahrungsfristen Verfügbarkeit Jederzeit Lesbarkeit von Dokumenten Einhaltung der gesetzlichen Aufbewahrungsfristen Nachvollziehbarkeit Sachverständige Dritte müssen das Verfahren in angemessener Zeit nachvollziehen können (Verfahrensdokumentation) Systemprotokollierung (Wer? Was? Wann? Warum?) Unveränderbarkeit Sicherstellung der Integrität der Dokumente Versionierung, d h. Nachvollziehbarkeit des ursprünglichen Zustands und der zeitlichen Abfolge der Änderungen Wie soll der Revisor die Einhaltung dieser Kernkriterien nun überprüfen? Die Verfahrensdokumentation ist hier der Schlüssel. Denn diese stellt den Soll-Zustand für das DMS dar und die letztendliche Lösung den Ist-Zustand. Die Verfahrensdokumentation kann also
121
6 Besondere Prüfungsgebiete innerhalb einer Prüfung bewertet werden. Doch wie? Im weiteren Verlauf stellen wir Ihnen Bewertungsbereiche vor, die eine Prüfung und Bewertung der vorhandenen Verfahrensdokumentation ermöglichen. Die folgenden Bewertungsbereiche sind Teil der „Prüfkriterien für Dokumentenmanagement- und Enterprise Content Management-Lösungen“ (PKDML)5, die durch den Verband Organisations- und Informationssysteme e.V. (VOI)6 unter Mitwirkung der TÜV Informationstechnik GmbH erstellt wurden.
6.2.2
Bewertungsbereiche
Der Überblick über die Bewertungsbereiche soll Ihnen einen Anhaltspunkt geben, die Prüfung der Verfahrensdokumentation zu planen. Die konkreten Bewertungskriterien können in den PK-DML nachgeschlagen werden. Die Bewertungskriterien umfassen die Mindestanforderungen einer Zertifizierung. Diese sind als Positivaussagen formuliert und stellen also „K.O.-Kriterien“ dar. Allgemeine Beschreibung des Einsatzgebietes Sachlogische Systemlösung Technische Systemlösung und Migration IT-Sicherheit Technischer Betrieb Prozesse Mitarbeiterqualifikation Test Outsourcing Internes Kontrollsystem (IKS)
6.2.3
Prüfung und Zertifizierung
Durch die Definition der PK-DML steht den Revisoren ein Prüfungskatalog zur Verfügung, der die höchstmögliche Sicherheit für den Betrieb eines DMS gewährleistet. Doch wie kann so eine Prüfung in der Praxis aussehen? 6.2.3.1
Prüfobjekte
Die Prüfung einer DMS-Lösung sollte in zwei Schritten erfolgen. Das erste Prüfobjekt ist die Verfahrensdokumentation. Der Revisor muss bei der Prüfung der Verfahrensdokumentation die Abläufe, den Aufbau der Lösung, die formgerechte Durchführung der Tests, die Vollständigkeit und die Konsistenz untersuchen. Danach wird die vorliegende Verfahrens-
5
Prüfkriterien für Dokumentenmanagement- und Enterprise Content Management-Lösungen PK-DML ISBN 978-3-932898-17-4 6 http://www.voi.de
122
6.2 Prüfungsgebiet Dokumentenmanagement dokumentation anhand der Prüfkriterien bewertet. Wie schon erwähnt sind die Prüfkriterien als Positivaussage formuliert, sodass eine geschlossene Frage als die wohl einfachste Prüfungsdurchführung erscheint. Der Nachteil dabei ist jedoch, dass so wie in allen Audits nur unscharfe Ergebnisse erzielt werden. Deshalb sollten Sie nach dem in Kapitel 2 beschriebenen Vorgehen befragen. Die gewonnenen Aussagen können Sie danach mit dem Optimum der PK-DML vergleichen und daraus Vorschläge zu Verbesserungsmaßnahmen definieren. Der zweite Teil der Prüfung nimmt sich die technische Lösung vor und vergleicht die implementierte Lösung mit der Soll-Anforderung (der Verfahrensdokumentation). Dieser Schritt ist natürlich nur dann von Nutzen, wenn eine korrekte Verfahrensdokumentation vorliegt. Sollte dies der Fall sein, werden durch Stichprobentests die Erfassung, Indexierung, Recherche und Reproduktion von Dokumenten innerhalb der technischen Lösung geprüft. Die Ergebnisse aus diesen Stichproben müssen immer konsistent, vollständig und korrekt sein. Auch die unberechtigte Veränderung, Verfälschung und Fehlbedienung müssen ausgeschlossen werden. Dies kann durch Penetrationstests der technischen Lösung überprüft werden. Die Einsatzumgebung (z.B. Rechenzentrum oder Serverraum) ist zusammen mit den Einsatzbedingungen (z.B. Stromversorgung, Klimatisierung) ebenfalls zu prüfen. Dies kann durch Sichtungstermine erfolgen. Nach der Prüfung erstellen Sie wie gewohnt einen Prüfungsbericht. Dieser kann ggf. auch der Zertifizierungsstelle der TÜViT vorgelegt werden, um eine Zertifizierung durch den TÜV zu erlangen. Ebenso können die Unterlagen durch einen Wirtschaftsprüfer gesichtet werden, der die DMS-Lösung dann testieren kann.
123
7 7 CobIT-Prüfungen Eine spezielle Art von IT-Revisionsprüfungen stellen Prüfungen nach den Control Objectives for Information and related Technology1 dar. Hierbei handelt es sich um einen von der ISACA2 herausgegebenen Auditierungsstandard für die Informationstechnologie. Dieses Kapitel setzt Grundkenntnisse über CobIT voraus. Wenn Sie mit dem Aufbau und dem Inhalt von CobIT noch nicht vertraut sind, finden Sie in den Literaturhinweisen oder direkt bei der ISACA (www.isaca.org) genügend Hinweise auf Informationsmaterial. Das vorliegende Kapitel ist chronologisch gegliedert, d h. die Abschnitte folgen dem Verlauf von typischen CobIT-Prüfungen. In CobIT-Prüfungen geht es nicht darum, einzelne Mängel in ihren konkreten Unternehmensausprägungen aufzudecken, sondern darum, inwieweit der bestehende Zustand dem im CobIT-Framework beschriebenen Soll-Zustand entspricht.
7.1
Bestimmung des Prüfungsziels Im Grunde genommen wurde das globale Prüfungsziel bereits im vorherigen Absatz erwähnt: die Feststellung, dass das Prüfobjekt dem CobIT-Framework entspricht. Doch so einfach ist es nicht, denn es bedeutet in der Praxis einen hohen Aufwand, das gesamte Framework zugrunde zu legen. Daher ist eine 100 %ige CobIT-Compliance in den Unternehmen eher selten anzutreffen. Dies haben auch die CobIT-Autoren erkannt und dem Framework ein Reifegradmodell zur Seite gestellt. Es orientiert sich am Capability Maturity Model (CMM), das 1991 von der Carnegie Mellon University in Pittsburgh für die Prozessreife in der Software-Entwicklung herausgegeben wurde. Dieses fünfstufige Modell wurde um eine Stufe Null erweitert und
1 2
CobIT-Framework oder wie im Folgenden kurz CobIT genannt. International System Audit and Control Association, ein weltweiter Zusammenschluss von Wirtschaftsprüfungsgesellschaften.
125
7 CobIT-Prüfungen umfasst damit die Reifegradstufen Non-existent (0), Initial/Ad Hoc (1), Repeatable/but Intuitive (2), Defined Process (3), Managed and Measurable (4), Optimized (5). Festlegung des angestrebten Reifegrades In einem ersten Schritt muss die Reifegradstufe festgelegt werden, die als Messlatte dienen soll. So könnte sich das Prüfobjekt (sofern es ein Managementbereich ist oder einen Prozess darstellt) beispielsweise die Reifegradstufe 4 auf die Fahnen schreiben. Die IT-Revision würde nun beginnend bei der Reifegradstufe 1 prüfen, inwieweit das Prüfobjekt die Bedingungen der Reifegradstufen 1 bis 4 erfüllt3. Die Reifegradstufen bauen aufeinander auf, d h. die Stufe 4 kann nur erreicht werden, wenn die darunter liegenden Stufen 1 bis 3 erreicht sind. Festlegung der relevanten CobIT-Prozesse Das CobIT-Framework ist in vier Domänen4 („Domains“) gegliedert, die Lebenszyklusphasen entsprechen. In jeder Lebenszyklusphase sind mehrere CobIT-Prozesse definiert. In jedem CobIT-Prozess gibt es eine Beschreibung des Prozesses, die Kontrollziele5 im Sinne von Forderungen, Management-Richtlinien und das Reifegradmodell. Wichtig für die Prüfung sind: Die Kontrollziele Sie sind als Maßnahmen formuliert, was leicht verwirren kann, da Ziele normalerweise als Zielzustand formuliert werden. Beispiel DS5.10 (Netzwerksicherheit): „Stelle sicher, dass technische Sicherheitsmaßnahmen (...) (z.B. Firewall (...)) verwendet werden (...)“6. Wenn es Kontrollziele gibt, muss es auch Kontrollen zu diesen Zielen geben. Das sind die Methoden, Verfahren, Arbeitsabläufe und Organisationsstrukturen, die angemessen sicherstellen, dass das Kontrollziel (eines oder auch mehrere) erreicht wird. In der Prüfung wird untersucht, ob diese Methoden usw. existieren und funktionieren. In dem Beispiel würde also untersucht, ob und wie im Unternehmen sichergestellt wird, dass im Bereich der IT-Sicherheit bzw. Netzwerksicherheit technische Sicherheitsmaßnahmen wie Firewalls verwendet werden. Das Reifegradmodell Im Reifegradmodell wird (nach Reifegradstufen gruppiert) aufgeführt, welcher Zustand gegeben ist, wenn sich der Prozess auf der jeweiligen Reifegradstufe befindet. Beispiel DS8 Stufe 1: „Es gibt keinen Eskalationsprozess.“ So kann der bestehende Zustand des
126
3
Die Reifegradstufe 0 stellt keine Forderungen.
4
Im Folgenden wird der Begriff Lebenszyklusphasen benutzt, da er zutreffender ist.
5
Für die Kontrollziele wird im Folgenden auch der Begriff Forderungen benutzt, da er im Text manchmal leichter verständlich ist.
6
Als Zielzustand lautete dies: „Es ist sichergestellt, dass technische Sicherheitsmaßnahmen verwendet werden“.
7.2 Aufnahme der bestehenden Situation Prüfobjekts mit den Reifekriterien (das sind die Aussagen in den Stufen des Reifegradmodells) verglichen und entsprechend eingeordnet werden. Ein Manko von CobIT ist, dass die Kontrollziele nicht mit den Reifekriterien verbunden sind. Das führt in der Praxis dazu, dass man in der Prüfung sowohl die Kontrollziele als auch die Reifekriterien untersuchen muss, um zum einen die CobIT-Compliance festzustellen und zum anderen die Reifegradeinstufung vorzunehmen. Für das Prüfobjekt werden nun die Prüfungsgebiete festgelegt, d h. worauf das Prüfobjekt untersucht werden soll. Das Prüfobjekt könnte z.B. die Software-Entwicklung im ITBereich sein, Prüfungsgebiete wären beispielsweise das Anforderungsmanagement sowie Qualität und Sicherheit. Relevant wären für das Anforderungsmanagement AI1 und DS1, für Qualität und Sicherheit PO8 und DS5. Bei der Festlegung der relevanten CobIT-Prozesse kann auch eine Einschätzung des zu prüfenden Bereichs eingeholt werden, damit es in der Prüfung zu keinen größeren Unstimmigkeiten über die anzuwendenden Forderungen gibt. Praxistipp Es gibt öfters Diskussionen mit den Fachbereichen, ob die eine oder andere Forderung von CobIT zweckmäßig und angebracht ist. Es sollte deshalb in der Prüfungsankündigung bzw. dem Kick-Off-Meeting darauf hingewiesen werden, dass es für die Prüfung nicht zur Debatte steht, ob die CobIT-Forderungen allgemein oder im Hinblick auf das Unternehmen und das Prüfobjekt sinnvoll erscheinen. Eine CobIT-Prüfung ist eine standardisierte Prüfungsform mit einem feststehenden Forderungskatalog, der nicht in Frage gestellt wird. Wenn eine Forderung relevant ist, dann ist sie auch zu erfüllen, ansonsten können bestimmte Reifegrade nicht erreicht werden.
7.2
Aufnahme der bestehenden Situation Wichtig ist, dass die CobIT-Prozesse bei der Aufnahme der bestehenden Situation nur innerhalb der Grenzen des Prüfobjektes betrachtet werden, denn die CobIT-Prozesse sind unternehmensweit definiert. Es gibt häufiger die Situation, dass bei der Prüfung behauptet wird, ein Kontrollziel sei erfüllt, und dann stellt man fest, dass dies irgendwo außerhalb des Prüfobjekts der Fall ist. Beispiel Probleme bei der Nutzung eines Softwaresystems werden vom Sachbearbeiter bemerkt und an den IT-Verantwortlichen des Fachbereichs gemeldet. Der IT-Verantwortliche analysiert das Problem und überlegt, was zur Lösung des Problems getan werden muss. Liegt die Ursache beim Sachbearbeiter oder im Fachbereich, dann wird das Problem intern gelöst. Ansonsten wird der IT-Administration gemeldet, was zur Lösung des Problems getan werden muss.
In der CobIT-Prüfung wird das Reifekriterium 4 von DS13 Stufe 5 geprüft: „Alle Probleme und Fehler werden analysiert (...)“. Ob dies im Beispiel erfüllt ist oder nicht, hängt
127
7 CobIT-Prüfungen entscheidend davon ab, wie das Prüfobjekt gefasst ist. Ist das Prüfobjekt das Unternehmen als Ganzes, dann ist es erfüllt. Ist das Prüfobjekt die IT-Administration, dann ist es nicht erfüllt. Die Prüfung der CobIT-Konformität des Prüfobjekts sollte ohne Beschränkung der Ausgangslage erfolgen. Das bedeutet, dass alle CobIT-Forderungen geprüft werden, die aus Sicht von CobIT für den Bereich relevant sind. Analog zu mängelorientierten Revisionsprüfungen nimmt der IT-Revisor für jeden relevanten CobIT-Prozess die bestehende Situation der zugehörigen CobIT-Forderungen in den Grenzen des Prüfobjekts durch Dokumentenanalysen, Interviews usw. auf. Prüfungsfragen können aus den Kontrollzielen und den Reifekriterien abgeleitet werden, dabei sind die Hinweise aus Kapitel 2 zu beachten (z.B. sollten Fragen nie so gestellt werden, dass man als Befragter erahnen kann, welche Antwort negativ gewertet werden würde). Anschließend erfolgt die Dokumentation und das Einholen der Bestätigung durch den geprüften Bereich.
7.3
Feststellung der CobIT-Erfüllung Für jeden relevanten CobIT-Prozess wird nun geprüft, welche der darin aufgeführten CobIT-Forderungen durch die bestehende Situation erfüllt werden und welche Abweichungen zu CobIT bestehen.
7.4
Ermittlung des Reifegrades Die Ergebnislage der Ist-Aufnahme wird auf das CobIT-Reifegradmodell (Maturity Levels) des jeweiligen CobIT-Prozesses angewendet, um die erreichte Reifegradstufe und den aktuellen Reifegrad zu ermitteln. Dazu wird beginnend mit der Reifegradstufe 1 untersucht, in welchem Umfang die Reifekriterien der einzelnen Stufen zutreffen. Dabei gibt es nicht nur schwarz und weiß, d.h. „trifft zu“ oder „trifft nicht zu“, sondern vier Stufen:
128
Zutreffen des Kriteriums
Wert
Das Reifekriterium trifft überhaupt nicht zu (nicht erfüllt).
0%
Das Reifekriterium trifft zu einem kleinen Teil zu (teilweise erfüllt).
33 %
Das Reifekriterium trifft zu einem großen Teil zu (teilweise erfüllt).
66 %
Das Reifekriterium trifft vollständig zu (erfüllt).
100 %
7.4 Ermittlung des Reifegrades Eine betrachtete Reifegradstufe gilt nur dann als erreicht, wenn der Erfüllungsgrad der Stufe 100 % beträgt (d h. wenn alle Reifekriterien mit 100 % bewertet wurden) und alle darunter liegenden Stufen ebenfalls zu 100 % erfüllt sind. Die erreichte Reifegradstufe ist die höchste Stufe, in der alle Reifekriterien vollständig zutreffen. In den Stufen darunter treffen ebenfalls alle Reifekriterien zu, in der Stufe darüber (sofern es nicht Stufe 5 ist) existiert mindestens ein Reifekriterium, das nicht oder nur zu einem Teil zutrifft. Zur Feststellung des aktuellen Reifegrades wird der Erfüllungsgrad der Stufe ermittelt, die über der erreichten Reifegradstufe liegt. Trifft in dieser Stufe kein einziges Kriterium zu (auch nicht zu einem Teil), dann ist der aktuelle Reifegrad gleich der erreichten Reifegradstufe. Ansonsten liegt der aktuelle Reifegrad zwischen der erreichten Reifegradstufe und dieser nächsthöheren Stufe. Der Erfüllungsgrad dieser Stufe wird nach der folgenden Formel berechnet: i AnzKrit
Erfüllungsgrad der Stufe =
§ Egradi ¨ © 100 1 AnzKrit
¦ i
· ¸ ¹
100
Darin gibt i die laufende Nummer des aktuell betrachteten Reifekriteriums an, AnzKrit steht für die Anzahl der Reifekriterien und Egradi für den Erfüllungsgrad des aktuell betrachteten Reifekriteriums in Prozent (0 %, 33 %, 66 % oder 100 %). Der absolute Wert des aktuellen Reifegrades ergibt sich aus der Formel: § Egrad n · ¸ (n 1) © 100 ¹
Aktueller Reifegrad des CobIT-Prozesses = ¨
Darin steht n für die aktuell betrachtete, nur partiell erfüllte Stufe, n-1 für die vorherige, höchste vollständig erfüllte Stufe und Egradn für den nach der ersten Formel berechneten Erfüllungsgrad der Stufe. Beispiel Auf der Stufe 1 existieren zwei Kriterien mit den Erfüllungsgraden 100 % und 100 %. Auf der Stufe 2 existieren drei Kriterien mit den Erfüllungsgraden 100 %, 100 % und 100 %. Auf der Stufe 3 existieren fünf Kriterien mit den Erfüllungsgraden 100 %, 100 %, 0 %, 100 %, 66 %. Die erreichte Reifegradstufe ist die höchste Stufe, bei der alle Kriterien 100 % erfüllt sind, also hier: Stufe 2. Der Erfüllungsgrad der nächsthöheren Stufe (Stufe 3) beträgt:
129
7 CobIT-Prüfungen Der aktuelle Reifegrad beträgt (n=Ziffer der nur partiell erfüllten Reifegradstufe, hier: Stufe 3):
73, 2 Erfüllungsgradn (n 1) 2 2,73 100 100
Für jeden relevanten CobIT-Prozess wird der Wert des aktuellen Reifegrades ermittelt. Die gewonnenen Werte können am übersichtlichsten in Form einer Grafik dargestellt werden. Ein Beispiel zeigt Abbildung 7.1. 1
0
2
3
4
5
PO3 PO8 AI1 AI2 AI3 AI5 DS1 DS2 DS3 DS4 DS6 DS7 DS9 ME1 ME2 ME3 ME4
Abbildung 7.1 Grafische Übersicht der Reifegrade
Um noch praxisgerechter zu werden, können die Werte zusätzlich gewichtet werden, d h. die Bedeutung einzelner CobIT-Prozesse oder einzelner Prüfungsgebiete kann durch die Multiplikation mit einem Faktor erhöht oder vermindert werden. Das vergrößert natürlich auch den Aufwand für die CobIT-Prüfung und setzt voraus, dass es objektive und anerkannte Gewichtungsfaktoren gibt. Mit statistischen Methoden (z.B. arithmetische Mittelwertbildung) kann die Menge der Werte pro Prüfungsgebiet oder global verdichtet werden. Globale Gesamtwerte eignen sich besonders gut, um einen managementkonformen Report des Prüfungsergebnisses zu erstellen. Auf einen Blick ist damit erkennbar, wie es um die Reife des Prüfobjekts bestellt ist, wie Abbildung 7.2 zeigt: Akt. Erreichte Reifegrad Reifegradstufe
2,51
0
1
2
3
4
5
Abbildung 7.2 Grafische Angabe der Gesamtwerte
Für jedes Prüfungsgebiet wird eine Tabelle aufgenommen, in der die einzelnen Reifekriterien mit dem Prozentwert ihrer Erfüllung aufgeführt werden. Da in manchen CobIT-Prozessen viele Reifekriterien enthalten sind, werden aus Platzgründen in der Tabelle oft nur die Werte derjenigen Kriterien angegeben, die nicht vollständig erfüllt sind.
130
7.5 Prüfung des Ziel- und Kontrollsystems
Aktueller Reifegrad
6
Max. partiell erfülltes Kriterium auf der nächsten Stufe
Erfüllung
2
Nr. Kriterium7
Anzahl Kriterien nächste Stufe
PO2
Erreichte RG-Stufe
Prozess
Beispiel für eine solche Tabelle:
1
Verantwortung für Datenarchitektur ist zugeordnet.
66
2,33
2
Verfahren der Datenarchitektur sind standardisiert.
0
3
Grundlegende Richtlinien zur Datenarchitektur sind entwickelt.
66
4
Datenadministrator für die Datenarchitektur ist vorhanden.
33
5
Einsatz automatisierter Werkzeuge entwickelt sich.
33
6
Formelle Fortbildungsveranstaltungen werden durchgeführt.
0
Mit der Tabelle wird im Prüfungsbericht nachvollziehbar gemacht, wie sich die Werte für die CobIT-Prozesse ergaben, was dem Transparenzgebot entspricht.
7.5
Prüfung des Ziel- und Kontrollsystems Zielsystem Unternehmen, die sich umfänglich an CobIT ausrichten wollen, können das in CobIT enthaltene Ziel- und Kontrollsystem nutzen. Das Zielsystem arbeitet top-down, d h. aus den Unternehmenszielen werden die globalen IT-Ziele abgeleitet und aus ihnen wiederum ITProzessziele. Die unterste Ebene bilden die Aktivitätsziele. Die Ziele stehen in einer 1:nBeziehung, d h. ein Ziel hat mehrere Ziele in der darunter liegenden Ebene. Beispiel: Zielebene
Zielinhalt
Unternehmensziel
Beherrschung von Risiken, die den Bestand des Unternehmens gefährden (existenzielle Risiken)
globales IT-Ziel
Früherkennung von schwerwiegenden IT-Risiken
IT-Prozessziel
Erkennung von Angriffen auf die IT-Netzwerke
Aktivitätsziel
Einsatz eines Intrusion Detection Systems (IDS)
7 Die Kriterien sind in den Maturity Levels in Textform beschrieben. Die Nummer entspricht der Nummer des Satzes, wenn die Sätze laufend durchnummeriert werden.
131
7 CobIT-Prüfungen In der Prüfung werden die vier Ebenen beleuchtet und abgefragt, ob und wenn ja welche Ziele auf der jeweiligen Ebene definiert sind und ob die Ziele der Ebenen miteinander in Zusammenhang stehen, sich also die untergeordneten Ziele aus den übergeordneten Zielen ableiten. Ergebniskennzahlen Mithilfe eines Maßstabs für das Ergebnis (Ergebniskennzahl) einer Aktivität, eines Prozesses usw. („Outcome Measure“, in früheren CobIT-Versionen „Key Goal Indicator“) wird gemessen, inwieweit das Ziel auf der jeweiligen Ebene erreicht ist und zur Erreichung des Ziels auf der nächsthöheren Ebene beiträgt. Für das gezeigte Beispiel könnte es folgende Ergebniskennzahlen geben: Ziel
Ergebniskennzahl (Outcome Measure)
Beherrschung von Risiken, die den Bestand des Unternehmens gefährden (existenzielle Risiken)
Existenz und Effektivität eines Ris komanagements
Früherkennung von schwerwiegenden IT-Ris ken
Erkennungszeitpunkt bei erkannten, schwerwiegenden Ris ken
Kenntnis hinsichtlich solcher Risiken
Anzahl nicht erkannter schwerwiegender Risiken Erkennung von Angriffen auf die IT-Netzwerke
Anzahl von gemeldeten Angriffen Anteil von echten Angriffen Erkennungsrate von simulierten Angriffen
Einsatz eines Intrusion Detection Systems (IDS)
Existenz und Funktionstüchtigkeit des IDS
In der Prüfung werden die Existenz, die Zweckmäßigkeit und die Ausprägung der Ergebniskennzahlen untersucht. Sind sie geeignet, um festzustellen, ob ein Ziel erreicht wurde? Sind sie vollständig genug, um die Zielerreichung definitiv beurteilen zu können? Werden sie in der Praxis verfolgt bzw. ausgewertet? Welche Folgen ergeben sich aus der Nichterfüllung? Leistungskennzahlen Die Ergebniskennzahlen sind eine Nachbetrachtung des Ergebnisses. Sie sagen nichts darüber aus, wie die Entstehung dieses Ergebnisses zu bewerten ist. Aus diesem Grund existieren Leistungskennzahlen (in CobIT: „Performance Indicators“, in früheren CobIT-Versionen „Key Performance Indicators“). Sie geben an, wie wahrscheinlich es ist, dass die Aktivität, der Prozess usw. in der Lage ist, das Ziel zu erreichen, und es demnach wahrscheinlich erscheint, dass das Ziel erreicht wird. Je mehr Ziele auf einer Ebene erfüllt sind (gemessen durch die Ergebniskennzahlen), desto wahrscheinlicher wird es, dass das Ziel auf der nächsthöheren Ebene erreicht werden kann. Damit werden die Ergebniskennzahlen einer Ebene zu Leistungskennzahlen auf der nächs-
132
7.5 Prüfung des Ziel- und Kontrollsystems ten Ebene. In der Prüfung wird mit den Leistungskennzahlen ähnlich verfahren wie mit den Ergebniskennzahlen. Kontrollsystem
le n Zie iere fin de
Ve au r b e sr ss ich er te n, n
Das Kontrollsystem, das im Sinne eines internen Kontrollsystems (IKS) arbeitet, ist als Kontrollkreislauf gestaltet (siehe Abbildung 7.3)
ce an n rm lle rfo tste Pe fes
g un ch sen i re s Er m e
Abbildung 7.3 CobIT-Kontrollkreislauf
Der Kontrollkreislauf gilt auf allen vier Ebenen, wobei die oberste Ebene außerhalb des IT-Bereichs angesiedelt ist. Hier zeigt sich der Charakter von CobIT als Framework an der Grenze zwischen Management und IT. In der Prüfung des Kontrollkreislaufs wird untersucht, ob und wie der Kontrollkreislauf definiert, dokumentiert und kommuniziert ist. Bei der Dokumentation reicht ein Verweis auf die CobIT-Dokumentation nicht aus, da der Kreislauf auf das eigene Unternehmen übertragen werden muss. Sind alle IT-Bereiche informiert, dass es diesen Kreislauf gibt und wie er nachhaltig umzusetzen ist? Ist der Kreislauf in den IT-Bereichen lebbar? In einem weiteren Prüfungsschritt ist zu kontrollieren, ob der Kreislauf auch in der Weise gelebt wird, in der er definiert wurde. Gibt es Dokumente, an denen sich nachvollziehen lässt, ob und wie die einzelnen Phasen durchlaufen wurden? Wo finden sich die Inhalte der Ergebnis- und Leistungskennzahlen? Gibt es ein Reporting darüber, in welchem Zustand sich der Kreislauf in einzelnen IT-Bereichen befindet? Gibt es eine kontinuierliche Weiterentwicklung des Kreislaufs und einen Austausch zwischen den IT-Bereichen? Dies sind einige Punkte, die in einer solchen Prüfung kontrolliert werden können.
133
8 8 Tools zur Prüfungsunterstützung Wie eine Prüfung vorgenommen wird, haben Sie schon erfahren. Und auch, welche Anforderungen an die IT aus Gesetzen und Verordnungen erwachsen und wie Sie als Revisor mit externen Wirtschaftsprüfern zusammen arbeiten. Dieses Kapitel stellt Ihnen nun die Werkzeuge vor, die einem Revisor zur Verfügung stehen, und erklärt, warum Sie diese nutzen sollten.
8.1
Wie alles begann Viele Werkzeuge führen zum Ziel, doch welches ist das richtige Werkzeug für Sie und die Aufgabe, die Sie damit bewältigen wollen? Um diese Frage besser beantworten zu können, ist es wichtig, einen Blick darauf zu werfen, wie die Revision ablief, als es diese Tools noch nicht gab. Hatte früher ein Revisor die Aufgabe, ein Buchungssystem auf die korrekte Verarbeitung von Buchungen zu kontrollieren, so konnte er dies durch Probebuchungen tun. Da alle Revisionen auch dem Faktor Zeit Rechnung tragen müssen, wurde die Prüfungsmenge sehr gering gehalten. Somit wurden maximal 50-60 Buchungen durchgeführt. Doch statistische Auswertungen mit solch geringer Grundmenge waren kaum aussagekräftig. Deshalb gingen die Bestrebungen dahin, dieses Dilemma zu beseitigen. Die ersten Ansätze einer Tool-Unterstützung waren selbstgeschriebene Skripte, mit denen die statistische Grundmenge erhöht werden sollte. Auf diese Weise konnten Tausende Buchungen in kürzester Zeit durchgeführt werden, um etwaige Fehler in der Verarbeitung zu erkennen. Mittlerweile können auch Auswertungswerkzeuge wie Crystal Reports etc. zur Unterstützung herangezogen werden, mit denen die Erstellung und Verarbeitung von Datenbankabfragen deutlich vereinfacht und standardisiert wurde.
135
8 Tools zur Prüfungsunterstützung
8.2
Warum überhaupt Tools? Nicht nur die interne Revision an sich profitiert davon, die Systeme und Daten mit Werkzeugen zu testen, insbesondere die IT-Revision kann durch eine gezielte Verwendung von Werkzeugen deutlich vereinfacht werden. Dies zeigt sich z.B. in der besseren Handhabung von Ergebnisdokumenten, bei der Zusammenstellung von Auswertungen oder bei der Prüfung komplexer Systeme. Für Sie als Revisor bestimmt das Budget den Umfang einer Prüfung. Kostenersparnis und Effizienzsteigerung sind bei den Auftraggebern gern genannte Schlagwörter. Um diesen Anforderungen gerecht zu werden, ist heute eine Revision ohne Hilfswerkzeuge kaum noch durchzuführen. Vorsicht ist jedoch geboten, wenn Revisoren die Werkzeuge ohne ein überlegtes, strukturiertes Vorgehen benutzen. Wenn Sie sich einzig und allein auf die Werkzeuge verlassen, ohne Ihre Erfahrung und die in den vorangegangenen Kapiteln beschriebenen systematische Vorgehensweise einzusetzen, sind auch die besten Hilfsmittel nur bedingt von Nutzen. Denn ein Werkzeug ist nur so gut wie derjenige, der es benutzt. Dieser Spruch gilt immer noch:
„A fool with a tool is still a fool.“
8.3
Welche Werkzeugarten gibt es? Betrachtet man die Werkzeuge für die IT-Revision und ihre Art, wie sie den Revisionsprozess unterstützen, so ergeben sich zwei Gruppen, die sich ergänzen und zwei unterschiedliche Teilbereiche des Revisionsprozesses abdecken: prüfungsbegleitende Werkzeuge und prüfende Werkzeuge (siehe Abbildung 8.1). Prüfungsbegleitende Werkzeuge: Diese Werkzeuge begleiten den Prozessablauf einer Prüfung. Sie unterstützen den Revisor bei der gesamten Prüfungsarbeit, insbesondere bei der Zusammenstellung der Prüfungsunterlagen und der anschließenden Dokumentation. Prüfende Werkzeuge: Diese Werkzeuge stellen dem Revisor Möglichkeiten zur Überprüfung von Daten oder Systemen zur Verfügung. Hierzu zählen auch Werkzeuge, die bestimmte Datenmengen überprüfen. Werkzeuge in der IT-Revision
Prüfungsbegleitende Werkzeuge
136
Prüfende Werkzeuge
Abbildung 8.1 Arten von Revisionswerkzeugen
8.4 Prüfungsbegleitende Werkzeuge
8.4
Prüfungsbegleitende Werkzeuge Viele der großen Wirtschaftsprüfungsgesellschaften haben in den letzten Jahren ihre eigenen, meist auf Dokumentenmanagementsystemen aufbauenden Werkzeuge erstellt. Dies wurde aufgrund der Menge und der Komplexität der Revisionsdokumente notwendig. So nutzt Ernst and Young ein System auf Basis des Microsoft-Werkzeugs Groove®. Die Kollegen von Price Waterhouse und Coopers nutzen Lotus Notes® als Basis für ihre Eigenentwicklung. Zu diesen Eigenentwicklungen gesellt sich noch Software von Drittanbietern. Die zwei bekanntesten sind CCH® TeamMate1 und audimex2. Wenn Sie ein Werkzeug zur Unterstützung Ihrer Revisionsprüfung nutzen möchten, sollten Sie darauf achten, dass es die folgenden Merkmale besitzt: Intuitive Bedienung: Die Bedienung des Werkzeuges muss innerhalb kurzer Zeit erlernbar sein. Die normalen Abläufe eines Audits müssen sich wiederfinden lassen. Die Symbole sollten denen eines normalen Programms entsprechen, damit die Eingewöhnungsphase kurz ausfällt. Mehrsprachigkeit: Um die Anforderungen zu erfüllen, die durch englischsprachige Autoritäten gestellt werden, sollte das Werkzeug diese Sprache unterstützen. Dies trägt zur Vermeidung von Fehlern bei, da die Ergebnisse nicht noch übersetzt werden müssen und der Auditprozess auch für englischsprachige Revisoren nachvollziehbar ist. Unterstützung der Ressourcenplanung: Bei größeren Audit-Teams ist es von großem Vorteil, Ressourcen planen zu können. So werden Überlastungen und dadurch entstehende Engpässe früh erkannt, und die Terminplanung des Audits wird nicht gefährdet. Unterstützung bei der Interviewplanung: Das Werkzeug sollte die personellen Ressourcen den angedachten Interviewterminen zuordnen können. Eine Schnittstelle zu OfficeWerkzeugen sollte vorhanden sein. Diese Unterstützung hält auch den Aufwand für die Interviewpartner in Grenzen. Praxistipp
Eine gute Interviewplanung schafft eine hohe Akzeptanz beim jeweiligen Interviewpartner und hilft Ihnen so dabei, aussagekräftige Ergebnisse zu erhalten.
Dokumentenverwaltung (Versionierung etc.): Die innerhalb des Auditprozess erstellten Dokumente (Fragebögen, Protokolle etc.) sollten mit einer Versionierung versehen werden. Im Rahmen der Dokumentenverwaltung sollten Daten wie Ersteller, Version, Datum der letzten Änderung und Freigabeverweise erfasst werden können.
1
http://tax.cchgroup.com/default
2
http://www.stb-ag.com/index.php?id=2
137
8 Tools zur Prüfungsunterstützung
8.4.1
Ablauf einer tool-unterstützten Prüfung
Anhand eines beispielhaften Prüfungsablaufs wollen wir Ihnen zeigen, wo ein Tool Sie unterstützen kann. Diese Beschreibung können Sie nutzen, um eine Anforderungsliste zu erstellen und am Markt befindliche Tools miteinander zu vergleichen und zu prüfen, ob sie Ihren Wünschen entsprechen. Um das Beispiel plastischer zu gestalten, werden die einzelnen Phasen mit Screenshots des Tools audimex unterstützt. Abbildung 8.2 zeigt einleitend die vier groben Phasen der Prüfung. Planung des Audits
8.4.1.1
Durchführung
Berichterstellungg
Nachbearbeitung
Abbildung 8.2 Schematische Darstellung der Prüfung
Planung des Audits
Die Planung des Audits beginnt nach der Definition des Prüfungsbereichs mit der Aufnahme der Prüfungsobjekte in das Werkzeug. Des Weiteren sind die Ressourcen, die für die Durchführung benötigt werden, zu definieren und zu organisieren. Dabei sollte das Werkzeug folgende Bereiche abdecken: Einfache Aufnahme des Prüfungsbereiches: Das Werkzeug sollte die Möglichkeit bieten, strukturiert vorzugehen und genau zu dokumentieren, welche Aspekte geprüft werden. Besondere Bedeutung hat dies bei Pflichtprüfungen. Abbildung 8.3 zeigt das Beispiel einer Ad-hoc-Prüfung.
Abbildung 8.3 Festlegen des Prüfungsbereiches
138
8.4 Prüfungsbegleitende Werkzeuge Definition der Prüfung: Bei der Definition der Prüfung sollte die Aufnahme der wichtigsten Punkte übersichtlich und gut strukturiert sein. Um in den nachfolgenden Schritten eine ständige Wiederholung der Eingaben zu verhindern, sollten die Inhalte weiterverwendet werden können. Die wichtigsten Inhalte sind: Prüfungsnummer und -name Geplanter Beginn und geplantes Ende Status der Prüfung Standort der Prüfung Prüfungsleitung Im folgenden Screenshot (Abbildung 8.4) sind die wichtigsten Daten der Prüfung noch einmal kurz dargestellt. Dies erleichtert dem Prüfungsleiter das Management.
Abbildung 8.4 Prüfungsdefinition
139
8 Tools zur Prüfungsunterstützung Zuordnen der Prüfer: Bei der Zuweisung von Prüfern zu einer Prüfung bzw. der Zusammenstellung des Prüfungsteams muss erkennbar sein, ob ein Mitarbeiter im Prüfungszeitraum noch verfügbar ist oder bereits für andere Aufgaben verplant wurde. Dies ist bei Ad-hoc-Prüfungen wichtig, da Überschneidungen mit anderen „geplanten“ Prüfungen auftreten können. Bei unserem Beispiel in Abbildung 8.5 ist die Anzahl der geforderten Prüfer als kritisch zu betrachten.
Abbildung 8.5 Prüfer zuordnen
140
8.4 Prüfungsbegleitende Werkzeuge Erstellen eines Prüfungshandbuches: Ein Prüfungshandbuch setzt sich aus einer Reihe von Prüfungshandlungen zusammen, also Einzelfragen oder Teilaspekten, die näher untersucht werden sollen. In der Vorbereitung und Durchführung einer Prüfung sollte die Möglichkeit bestehen, dass Sie ganz oder in Auszügen auf zuvor hinterlegte Standardprüfungshandbücher zurückgreifen und diese gegebenenfalls prüfungsspezifisch ändern, ergänzen oder auch neu erstellen können. Prüfungsankündigungen sollten auf der Basis von Dokumentvorlagen, in die die relevanten Prüfungsstammdaten automatisch übernommen werden, generiert werden können. Bei unserem Beispiel (Abbildung 8.6) sind vorher eingerichtete Vorlagen eine weitere Möglichkeit, um Zeit zu sparen.
Abbildung 8.6 Erstellen eines Prüfungshandbuches
141
8 Tools zur Prüfungsunterstützung 8.4.1.2
Durchführung
Erstellen von Checklisten: Inhalt und Struktur der Prüfung sollten als Checklisten vorgegeben oder auch erst während der Prüfung definiert und strukturiert werden können. Die Ergebnisse sollten dann auf der Ebene von einzelnen Prüfungshandlungen dokumentiert und bewertet werden können (siehe Abbildung 8.7).
Abbildung 8.7 Checklistenerstellung
142
8.4 Prüfungsbegleitende Werkzeuge Feststellungen und Maßnahmen definieren: Feststellungen und Maßnahmen bzw. Empfehlungen sollten auf einer zentralen Maske erfasst werden können (siehe Abbildung 8.8). Die Möglichkeit einer „Offline“-Prüfung sollte gegeben sein; das setzt voraus, dass Daten nach der Prüfung in das Tool importiert werden können.
Abbildung 8.8 Maßnahmen- und Feststellungsdefinition
143
8 Tools zur Prüfungsunterstützung Projektcontrolling: Um beim Management einer Prüfung nicht den Überblick über das Team und die geleistete Arbeit zu verlieren, sollte eine voll integrierte Zeiterfassung mit der Möglichkeit zur prüfungsbezogenen Buchung und somit zum Abgleich mit der Planung integriert sein. Dabei sollte die Zeiterfassung durch eine Urlaubs- und Abwesenheitsverwaltung um entsprechende Kalenderansichten ergänzt werden (Abbildung 8.9).
Abbildung 8.9 Zeiterfassung
8.4.1.3
Berichterstellung
Arbeitspapiererstellung: Für die Erstellung von Arbeitspapieren oder sonstigen Informationen sollte jegliches Format (Word, Excel, PDF usw.) importiert und strukturiert ablegt werden können (Abbildung 8.10). Die Versionierung sollte automatisch erfolgen. Die umfassende Integration von Microsoft Office sollte Teil des Werkzeuges sein, damit Prüfungsberichte in MS Word generiert werden können (Abbildung 8.11), indem ausgewählte Daten oder auch bestimmte Textabschnitte (z.B. gesetzliche Grundlagen) automatisch in den Word-Bericht übernommen werden.
144
8.4 Prüfungsbegleitende Werkzeuge
Abbildung 8.10 Erstellen der Arbeitspapiere
Abbildung 8.11 Office-Integration
145
8 Tools zur Prüfungsunterstützung 8.4.1.4
Nachbearbeitung
Verfolgung der Umsetzung der Maßnahmen: Die Maßnahmenverfolgung sollte umfassend unterstützt werden (siehe Abbildung 8.12). Für die Nachverfolgung der Umsetzung von Empfehlungen bzw. Maßnahmen sowie für die Dokumentation des Erledigungsprozesses muss das Werkzeug eine Wiedervorlagefunktion anbieten. Ebenso muss es ein prüfungsübergreifendes Monitoring des Erledigungsgrades unterstützen. Der gesamte Ablauf muss zeitlich und inhaltlich nachvollziehbar dokumentiert werden, um gesetzlichen Anforderungen zu entsprechen. Hierzu zählen Erledigungsfristen, eventuelle Fristverlängerungen sowie Zeitpunkt und Inhalt von Stellungnahmen. Erledigte Maßnahmen müssen aus Gründen der geforderten Nachweisbarkeit archiviert werden können.
Abbildung 8.12 Maßnahmenverfolgung
Nun haben Sie einen Überblick über die Unterstützung gewonnen, die Ihnen ein prüfungsbegleitendes Werkzeug bieten kann. Beachten Sie:
Werkzeuge, die Sie beim Management von Revisionsprüfungen unterstützen, sollten Ihnen einen Mehrwert durch Effizienzsteigerung und Ressourcenersparnis bringen – und nicht zum (dann sehr teuren) Selbstzweck werden. Setzen Sie die Ressourcen zur Verwaltung der Prüfung mit dem Tool ein und nicht zur Verwaltung des Tools an sich.
146
8.5 Prüfende Werkzeuge
8.5
Prüfende Werkzeuge Prüfende Werkzeuge bieten Hilfen bei technischen Überprüfungen von einzelnen Prüfungsobjekten. Sie überprüfen die festgelegten Prüfungsobjekte mit verschiedenen Ansätzen. Die gesamte Werkzeugpalette vorzustellen, würde den Rahmen des Buches sprengen. Um Ihnen bei der Auswahl der geeigneten technischen Unterstützung für die einzelnen Prüfungsobjekten zu helfen, erläutern wir die Anforderungen, die an die Werkzeuge gestellt werden sollten. Ein Praxisbeispiel soll Ihnen die Anforderungen verdeutlichen. Praxisbeispiel
Ihre Geschäftsführung hat Sie mit der Prüfung des ERP-Systems beauftragt. Ihnen steht ein Team von vier Personen zur Verfügung. Die Geschäftsführung benötigt von Ihnen einen Bericht, den der zuständige Wirtschaftsprüfer angefordert hat. Sie haben sich dazu entschieden, ein Werkzeug zu nutzen, um den Auditprozess zu unterstützen.
Die einzelnen Prüfungsobjekte sind hier das Betriebssystem, die Rechtevergabe innerhalb der Anwendung an sich und die Daten, die das ERP_System erzeugt. Betriebssystemprüfung: Das Werkzeug sollte die Integrität des Systems überprüfen können. Dies kann z.B. anhand von Prüfsummen und der Zugriffsrechteverteilung auf die einzelnen Systemverzeichnisse erfolgen. Als Ausgabe sollten Protokolle erstellt werden, die im ASCII-Format vorliegen, um einen Import in die Berichtserstellung zu erleichtern. Einige Werkzeuge sind bereits in den jeweiligen Betriebssystemen enthalten. Diese können entsprechend der Dokumentation genutzt werden. Im Linux-Bereich ist dies z.B. Tripwire. Die Voraussetzung einer solchen Überprüfung der Prüfsummen ist natürlich ihre vorherige Erstellung. Datenprüfung: Ein Werkzeug, das die Datenprüfung vornimmt, sollte die folgenden Anforderungen erfüllen: Datenimport Daten aus unterschiedlichen Anwendungen und Formaten sollten importiert werden können. Dazu gehören Datenbanken ebenso wie Excel-Dateien. Schutz vor Änderungen und Beschädigungen der Daten Datenänderungen, z.B. das unbeabsichtigte Überschreiben oder Löschen von Werten, dürfen nicht möglich sein. Dadurch wird garantiert, dass das Prüfergebnis nach dem Datenimport nicht absichtlich oder unabsichtlich verändert wird. Flexible und schnelle Analyse Mehrstufige Schnellfilter und Sortierfunktionen sollten enthalten sein, um Datenbestände sehr schnell und flexibel untersuchen zu können. Die Suche nach einzelnen Datensätzen sollte auch möglich sein. Die Qualität der Werkzeuge wird hier durch die Geschwindigkeit bestimmt.
147
8 Tools zur Prüfungsunterstützung Funktionen zur Datenanalyse Vorgefertigte Mittel zu Datenanalyse sind von großem Vorteil, da mit ihrer Hilfe wichtige Tests sehr schnell durchgeführt werden können. Dazu gehören beispielsweise die Altersstruktur, Benford-Test, Verteilungsprüfung, Histogramm oder Summenstruktur. Einsatz von Skripten Das Werkzeug sollte die Einbindung von Skripten ermöglichen. Dies erlaubt es, einzelne Skript-Befehle zu verwenden, um Arbeitsschritte automatisieren. Rechte- und Rollenkonformität innerhalb von ERP-Systemen Da es sich bei diesem Beispiel um die Prüfung eines schon vorhandenen ERP-Systems handelt, liegt das Hauptprüfungsaugenmerk auf der Rechte- und Rollenkonformität. Um die Rechte- und Rollenkonformität zu prüfen, sollte das Werkzeug die folgenden Anforderungen erfüllen: Auswertungen über eine Funktionstrennungsmatrix Vollautomatisierte und scheduler-gesteuerte Prüfungen Simulation von Änderungen an Benutzern und Rollen Systemübergreifende Berechtigungsauswertungen Kurz zusammengefasst
Es gibt wesentlich mehr Prüfungswerkzeuge als Verwaltungswerkzeuge. Sie können innerhalb der zu prüfenden Systeme bereits existieren oder durch Drittanbieter geliefert werden. Die genannten Anforderungen beschreiben das Mindestmaß an Umfang.
148
II Teil II: Grundsätze einer ordnungsgemäßen Informationstechnik (GoIT)
149
Einleitung Vor der Durchführung von IT-Revisionsprüfungen liegen zwei wichtige Schritte: 1. Es muss festgelegt werden, welche Soll-Vorgaben anzuwenden sind. 2. Die Prüfungsfragen, mit deren Hilfe sich der bestehende Zustand des Prüfobjekts feststellen lässt, müssen formuliert werden. Die Soll-Vorgaben stammen dabei aus externen und internen Vorschriften und Richtlinien (Prüfungsgrundlagen). Für jede Prüfung wird ein Prüfungsthema formuliert, das den Umfang der Prüfung definiert, denn in der Regel untersucht eine Revisionsprüfung nur einen Ausschnitt aller Soll-Vorgaben. Es werden nur diejenigen Soll-Vorgaben berücksichtigt, die für die zu prüfenden Lebenszyklusphasen (Planung, Entwicklung, Implementierung, Betrieb, Änderung/Migration und Roll-Off) und für die zu betrachtenden Prüfungsaspekte (Ordnungsmäßigkeit, Sicherheit, Zweckmäßigkeit, Wirtschaftlichkeit und Kontrollierbarkeit) relevant sind. Arbeitet die Informationstechnik mit einem Reifegradmodell, dann werden auch nur die Vorgaben berücksichtigt, die für das Erreichen des Ziel-Reifegrades1 erfüllt sein müssen. Diese Zusammenhänge zeigt Abbildung 1 auf der nächsten Seite. Die Grundsätze einer ordnungsgemäßen Informationstechnik (GoIT) sind eine Hilfestellung für die Durchführung dieser zwei Schritte. Die GoIT stellen einen globalen Anforderungskatalog für die IT dar, aus dem die für die Prüfung relevanten Anforderungen nach Lebenszyklusphase, Reifegrad und Prüfungsaspekt ausgewählt und zu einem prüfungsspezifischen Anforderungskatalog zusammengestellt werden können. Sie basieren auf den wichtigsten allgemeinen Prüfungsgrundlagen für die IT, die in Teil I in Kapitel 4 zu finden sind, und füllen evtl. bestehende Lücken mit Best-Practice-Vorgaben.
1
Das ist der Reifegrad, den die IT erreichen soll. Solche Reifegrade findet man z.B. bei Standards wie COBIT (siehe Kapitel 7).
151
Einleitung Prüfungsgrundlagen
Lebenszyklusphase
Prüfobjekt (IST)
ZielReifegrad
Prüfungsaspekte
Anforderungen (SOLL)
Abbildung 1 Auswahl der Soll-Vorgaben für eine IT-Revisionsprüfung
Gliederung der IT in den GoIT Die Informationstechnik ist auf den ersten Blick ein komplexes Gebilde aus Computern, Infrastruktur (z.B. Räume), Personal, Kommunikationskomponenten (z.B. Netzwerke und Übertragungsprotokolle), Software-Komponenten, IT-Management, IT-Prozessen usw. Es ist wichtig, zunächst Ordnung in das Chaos zu bringen und die IT zu gliedern.
IT-Strukturierungsmodell Den GoIT liegt das IT-Strukturierungsmodell der Firma iNNoMeNTa® zugrunde. Nach diesem Modell besitzt jedes Objekt in der IT Aspekte in den sieben Schichten, die in Abbildung 2 gezeigt werden. Phy si k N Anw Sys etzwer alisch end t k em u Übe n P g I erso n en rgeo nen halte rdne t
Abbildung 2 Schichten des InnomentaStrukturierungsmodells
Die Schichten besitzen folgende Bedeutung: 1. Physikalisch (Schicht PHY) Die physikalische Ebene enthält alle physischen Gesichtspunkte der IT. Hier finden sich bauliche Objekte (Gelände, Gebäude, Etagen, Räume), Einrichtungen (Klimaanla-
152
Gliederung der IT in den GoIT gen, Brandschutzvorrichtungen), Netzwerkmedien oder die Hardware von IT-Komponenten. 2. Netzwerk (Schicht NET) Alle netzwerktechnischen Gesichtspunkte finden sich in der Netzwerkschicht. Dies sind z.B. Netzwerkanbindungen von Servern, Netzwerkübergänge und das Internetworking. Die Netzwerkverkabelung als physisches Medium ist dagegen der Schicht PHY zugeordnet. 3. System (Schicht SYS) Die Systemschicht betrifft Betriebssysteme und Systemsoftware von IT-Objekten. 4. Anwendungen (Schicht ANW) In dieser Schicht finden sich alle softwaretechnischen Gesichtspunkte der IT. Auch Protokolle und Dienste zählen dazu. Anwendungssoftware, Daemons, Skripte, Hilfsprogramme – alles Beispiele von Software-Komponenten, die in dieser Schicht zu finden sind. 5. Inhalte (Schicht INH) Alle Daten und Informationen gehören in diese Schicht, unabhängig davon, welche semantische Bedeutung sie besitzen und in welchem Format und welcher Form sie geführt werden. 6. Personen (Schicht PERS) Hier finden sich alle personellen Gesichtspunkte der IT. Zugeordnete Objekte sind alle Personen, die eine Funktion in der IT ausüben wie Administratoren, Benutzer, externe Mitarbeiter, IT-Manager, Wartungspersonal usw. 7. Übergeordnet (Schicht ÜBER) Dieser Schicht sind alle Themen zugeordnet, die mehrere oder alle Schichten betreffen, z.B. übergeordnete Aspekte von IT-Verfahren oder das IT-Management. Diese Schicht ist in den GoIT nicht abgebildet. Durch den Charakter eines IT-Objekts lässt sich dieses Objekt einer der genannten Schichten zuordnen. Beispiel: IT-Objekt „Serverraum“
Ein Serverraum besitzt Gesichtspunkte in verschiedenen Schichten des Strukturierungsmodells. In der Schicht PHY finden sich die physischen IT-Objekte in diesem Raum (verlegte Netzwerke, Server-Racks und Server-Hardware). In der Schicht PERS finden sich die Personen, die mit dem Raum in Beziehung stehen wie Facility-Manager oder Reinigungspersonal. Der Raum selbst ist von seinem Charakter her jedoch ein physisches Objekt und wird deshalb der Schicht PHY zugeordnet.
Durch die Zuordnung aller Objekte zu den Schichten kann die gesamte IT in dem Modell abgebildet werden. Eine Zwischenebene besteht in der Bildung von IT-Verfahren, d h. es werden alle IT-Objekte zusammengefasst, die zu einem bestimmten IT-Verfahren bzw. einer IT-Lösung gehören. Die Bildung von Verfahren ist bedeutsam für Ereignisse, die sich auf das gesamte Verfahren beziehen (z.B. die Folgen, wenn das Verfahren ausfällt).
153
Einleitung In jeder Schicht existieren drei Dimensionen: IT-Technik Das ist die Gestaltung des IT-Objekts. Im Fall des Servers wäre das die physische und logische Beschaffenheit des Servers. Welche Hardware-Plattform hat der Server und wie ist sie beschaffen (Prozessor, Speicher usw.)? Welche Netzanbindung hat der Server? Welche Software ist installiert? Welche Auslastung zeigt der Server? Wann endet die Gewährleistung für den Server? etc. IT-Prozesse Das sind die Prozesse, die im Bezug auf das Objekt ablaufen. Im Fall des Servers sind dies u.a. die Prozesse: „Server planen“, „Server inventarisieren“, „Server administrieren“ und „Änderungen durchführen“. IT-Organisation/IT-Management Das sind alle organisatorischen Planungen, Definitionen, Entscheidungen und Vorgaben für das Objekt. Im Fall des Servers wäre das die funktionale Spezifikation, das Sicherheitskonzept, das Konfigurationsmanagement usw. Um den bestehenden Zustand feststellen zu können, müssen alle drei Dimensionen mit Prüfungsfragen erschlossen werden.
Fokus Mit der Festlegung des Prüfobjekts wird der Fokus für die Prüfung definiert, d h. es wird festgelegt, auf welches Objekt sich die Aufmerksamkeit der Prüfung konzentriert. Jedes Prüfobjekt hat übergeordnete, äußere Objekte „um sich herum“ und innere Objekte „in sich“. Beispiel: Prüfobjekt Serverraum versus Prüfobjekt Server
Ein Serverraum hat als äußeres Objekt das Gebäude, in dem der Raum liegt, und als innere Objekte u.a. die Server. Ein Server hat als äußeres Objekt den Serverraum und als innere Objekte u.a. die auf diesem Server installierten Dienste.
Der Fokus bestimmt, welche Gesichtspunkte in den sieben Schichten auftauchen. Während für den Server in der Schicht SYS die Betriebssystemsicherheit auftaucht, ist dieser Gesichtspunkt für den Serverraum nicht relevant, weil es kein inneres Objekt „Betriebssystem“ gibt. Dagegen ist die Dimensionierung der Stromkreise (Absicherung, Leitungsquerschnitt usw.) für den Serverraum wichtig, aber für einen einzelnen Server nicht relevant2, da es für den Server ein äußeres Objekt ist. Damit ergibt sich für den Fokus das in Abbildung 3 dargestellte Bild.
2
154
Natürlich ist ein Server abhängig von der richtigen Dimensionierung, das Management der Energieversorgung liegt jedoch nicht im Bereich eines einzelnen Servers.
IT-Lebenszyklusphasen in den GoIT Gesamtes Unternehmen
äußere
Standort
äußere
Gebäude innere
äußere
Serverraum innere
Server
innere
Abbildung 3 Äußere und innere Objekte bei verschiedenem Fokus
Für die Revisionsprüfung ist es wichtig zu wissen, was genau im Fokus der Prüfung liegt. Wenn die Dimensionierung der Stromkreise ein wichtiger Punkt ist, der geprüft werden muss, dann muss der Fokus entsprechend in diesem Punkt auf den Serverraum gerichtet werden.
IT-Lebenszyklusphasen in den GoIT In vielen Fällen kann die Revisionsprüfung auf eine oder wenige IT-Lebenszyklusphasen beschränkt werden. Wird z.B. untersucht, ob die Planung eines neuen IT-Systems ordnungsmäßig verlief, so beschränken sich die Anforderungen auf die Planungsphase, und alle Anforderungen in den anderen Phasen sind nicht relevant, wodurch der Aufwand sinkt. Die GoIT kennen sechs IT-Lebenszyklusphasen: Planung In dieser ersten Phase wird der Einsatz des Objekts konzipiert. Das Objekt selbst ist noch nicht vorhanden. Der Bedarf für das Objekt wird erhoben, die gewünschten Ausprägungen werden festgelegt, Kostenbetrachtungen angestellt, das Einsatzszenario spezifiziert usw. Schließlich wird eine Entscheidung getroffen, ob das Objekt implementiert werden soll. Entwicklung Sofern es sich um ein unternehmensspezifisches Objekt handelt (z.B. eine spezielle Software, die es nicht zu kaufen gibt), muss das Objekt zunächst entwickelt werden. Alle zur Entwicklung gehörenden Dinge wie die Bereitstellung der benötigten Ressourcen, Entwicklungsvorgaben, ablaufende Entwicklungsprozesse und natürlich das Ergebnis der Entwicklung werden in dieser Phase behandelt. Implementierung Die Implementierungsphase beginnt bei Standardprodukten (die betriebsfertig bezogen werden können) mit der Beschaffungsplanung, in der das Objekt und ein Lieferant aus-
155
Einleitung gewählt und die Bezugskonditionen ausgehandelt werden. Nach erfolgter Beschaffung und Eingangskontrolle schließen sich Implementierungsprozesse wie Inventarisierung, Aufstellung, Anschluss, Installation und Konfiguration, Test, Inbetriebnahme und Abnahme bzw. Übergabe an den Betrieb an. Betrieb Das Objekt wird gemäß des existierenden Betriebskonzepts betrieben (Regelbetrieb). Technische Objekte werden überwacht, notwendige Wartungsmaßnahmen werden vorgenommen, Sicherheitsmaßnahmen (z.B. Datensicherungen oder Patch-Einspielungen) durchgeführt, Probleme behoben usw. Auch der Notbetrieb nach Eintritt eines Notfalls gehört zur Betriebsphase. Weiterentwicklung/Änderung/Migration Schon im laufenden Betrieb sind kleinere Änderungen an der Tagesordnung, die üblicherweise über ein Change-Mangement abgewickelt werden. Mit fortschreitender Zeit wird sich aber auch die IT-Architektur verändern und grundlegendere Änderungen an den Objekten erforderlich machen. Steigt die Nutzung, müssen Objekte erweitert oder durch weitere Objekte ergänzt werden. Durch Technologiefortschritte kann es notwendig oder sinnvoll werden, das Objekt durch ein anderes Objekt abzulösen (Migration), oder es ergibt sich eine Weiterentwicklung infolge von organisatorischen Einflüssen (z.B. durch eine Fusion). Das entsprechende Objekt kommt damit in die Phase Änderung/Migration. Bleibt das Objekt bestehen, folgt wieder eine Betriebsphase; wird es abgelöst, folgt die Roll-Off-Phase. Roll-Off Die letzte Phase eines Objekts in der IT besteht in der Ausmusterung des Objekts. Wird die Funktionalität weiterhin benötigt, dann erfolgt die Ausmusterung meist innerhalb einer Migration. Das Objekt wird außer Dienst gestellt, abgeschaltet, entfernt und (sofern nicht Archivierungsvorschriften dagegensprechen) verkauft oder entsorgt. Die hier dargestellten Phasen sind so allgemein definiert, dass andere Phasenmodelle (z.B. von COBIT) integriert werden können.
Prüfungsaspekte in den GoIT Jede Anforderung in den GoIT trägt zur Erfüllung einer oder mehrerer Prüfungsaspekte bei. Zu jeder Anforderung wird daher vermerkt, welche Prüfungsaspekte von der Anforderung berührt werden. Folgende Prüfungsaspekte werden berücksichtigt: Om: Ordnungsmäßigkeit (Rechtmäßigkeit, Zulässigkeit, Konformität) Si: Sicherheit (Verfügbarkeit, Vertraulichkeit, Integrität) Zm: Zweckmäßigkeit (Effektivität, Funktionserfüllung) Wi: Wirtschaftlichkeit/Effizienz Ko: Kontrollierbarkeit (Transparenz, Nachvollziehbarkeit)
156
Vorgehen bei der Anwendung der GoIT
Vorgehen bei der Anwendung der GoIT Dieser Abschnitt beschreibt, wie man die GoIT in der Praxis anwenden kann. Die Anwendung erfolgt in vier Schritten: Schritt 1: Lebenszyklusphasen und Prüfungsaspekte bestimmen Aus dem Prüfungsauftrag wird abgeleitet, welche Lebenszyklusphasen und Prüfungsaspekte von dem Auftrag betroffen sind. Das hilft, den Umfang der anzuwendenden Anforderungen einzugrenzen. Schritt 2: Relevante Anforderungen auswählen Auf Basis der Lebenszyklusphasen und Prüfungsaspekte werden die relevanten Anforderungen aus den GoIT ausgewählt. Schritt 3: Checkliste zusammenstellen Die Prüfungsfragen, die bei den relevanten Anforderungen aufgeführt sind, bilden die Grundlage einer Checkliste, die für die Ist-Erhebung verwendet wird. Schritt 4: Erfüllung der relevanten Anforderungen ermitteln Für jede Anforderung wird festgestellt, inwieweit sie erfüllt ist. Das kann auf zwei Arten geschehen. Bei einer Konformitätsprüfung wird die Prozentzahl der Erfüllung ermittelt, bei einer klassischen Revisionsprüfung werden die im Hinblick auf die Anforderung vorhandenen Mängel festgestellt. Als sinnvoll hat sich die Verwendung der folgenden Metrik erwiesen: Die Anforderung ist vollständig erfüllt (100 %, keine Mängel). Der Ist-Zustand weicht in geringem Maße von dem in der Anforderung geforderten Zustand ab (66 %, geringe Mängel). Der Ist-Zustand weicht in größerem Maße von dem in der Anforderung geforderten Zustand ab (33 %, erhebliche Mängel). Die Anforderung kann nicht (auch nicht zu einem Teil) als erfüllt angesehen werden (0 %, schwerwiegende Mängel). Die Metrik der Mängel (keine – geringe – erhebliche – schwerwiegende) ist in diesem Zusammenhang nicht als Höhe des Risikos für das Unternehmen zu sehen, sondern als Maß für die Abweichung vom Soll-Zustand (also der Anforderung).
157
A A Physikalische Ebene Zur physikalischen Ebene gehören: Gebäude Büroraum Serverraum Schutzschränke
159
A Physikalische Ebene
A.1
Planungsphase A.1.1
Bei der Planung einer physischen Einrichtung sind Sicherheitsmaßnahmen berücksichtigt worden.
Om
V
Si
A.1.1.1 A.1.1.2
L
Zm
Wi
Ko
Welche Maßnahmen wurden bei der Planung des Gebäudes berücksichtigt? Wie wurde die Planung durch das Sicherheitsmanagement begleitet?
Werden Sicherheitsmaßnahmen bereits bei der Planung berücksichtigt, können hohe Kosten für nachträgliche Nachbesserungen verhindert werden. Eine nicht ausreichende Berücksichtigung bei der Planung birgt das Risiko, dass sich Sicherheitsmaßnahmen nachträglich nur mit hohem Kostenaufwand oder gar nicht mehr umsetzen lassen. Letzteres minimiert die Schutzwirksamkeit der physikalischen Sicherheitsmaßnahmen.
#
Í
160
Stromkreise an die Anforderungen angepasst planen. Sicherheitszonen in der Planung definieren. Die Netzwerkverkabelung auf zukünftige Kapazitätsanforderungen hin ausrichten. Bei den Planungsgesprächen sollte das Sicherheitsmanagement involviert werden. Vergleiche: BSI GSK B 2.1
Siehe auch (in GoIT): Abschnitt A.1.2
A.1 Planungsphase
A.1
Planungsphase
A.1.2
Bei der Planung sind einschlägige Normen berücksichtigt worden.
Om
Si
Zm
Wi
Ko
V
A.1.2.1 A.1.2.2 A.1.2.3
Welche Normen sind beim Brandschutz eingehalten worden? Welche Normen sind beim Einbruchschutz eingehalten worden? Welche Normen sind bei der Verkabelung eingehalten worden?
L
Einschlägige Normen im Bereich der physischen Einrichtungen sind Richtlinien zu den Bereichen Brandschutz, Einbruchschutz, Verkabelung etc. Hier sind die VDI-Richtlinien zu nennen. Wenn die Normen nicht eingehalten werden, können erhebliche Mehrkosten durch nachträgliche Umsetzung entstehen. Außerdem ist der Schutz, den die physische Einrichtung gewährleisten soll, nicht mehr gegeben.
#
Í
Einbindung des Sicherheitsmanagements bei der Planung von Gebäuden Zertifizierungen des Planungsteams in den Bereichen der VDI-Normen Zuhilfenahme von Experten in den jeweiligen Teilbereichen Experte im Bereich Einbruchschutz ist z. B. die Kriminalpolizei. Für den Brandschutz kann z.B. die Feuerwehr als Experte hinzugezogen werden. Der Bericht der letzten Brandschutzbegehung kann z. B. darüber Aufschluss geben, ob die Richtlinien eingehalten worden sind. Vergleiche: BSI GSK B 2.1 www.vdi.de
161
A Physikalische Ebene
A.1
Planungsphase
A.1.3
Schützenswerte Gebäudeteile sind deklariert worden.
Om
Si
Zm
Wi
Ko
V
A.1.3.1 A.1.3.2
Wo befinden sich schützenswerte Räume oder Gebäudeteile? Wo befinden sich die Raumbelegungspläne?
L
Schützenswerte Gebäudeteile sind solche, die zentrale Infrastrukturkomponenten oder wichtige Systeme und Daten beherbergen. Werden schützenswerte Gebäudeteile durch die Raumdeklaration nicht definiert, so können wichtige Maßnahmen nicht zielgerichtet umgesetzt werden. Dadurch ist es Unbefugten leicht möglich, Daten zu entwenden, zu manipulieren oder zu zerstören.
#
Einbindung des Sicherheitsmanagements bei der Planung von Gebäuden Brandabschottung von Gebäudeteilen durch Brandschutzmaßnahmen Planung von Sicherheitsmaßnahmen bei besonderen Gebäudeteilen
Í
Die Definition und Planung der schützenswerten Gebäudeteile sollte schon während der Bauplanung für ein neues Gebäude oder in die Raumbelegungsplanung bei Einzug in ein bestehendes Gebäude mit einbezogen werden.
162
Vergleiche: BSI GSK B 2.1
A.1 Planungsphase
A.1
Planungsphase
A.1.4
Elektroversorgungsleitungen und Datenleitungen sind zukunftsorientiert geplant.
Om
Si
Zm
Wi
Ko
V
A.1.4.1 A.1.4.2
Welche Wachstumsraten wurden mit berücksichtigt? Welche Leitungen sind innerhalb der Leitungsplanung betrachtet worden?
L
Zukunftsorientierte Planung bedeutet, dass bei der Kapazitätsplanung die Wachstumsrate der nächsten 10 Jahre eingeplant wird. Werden Leitungen nicht zukunftsorientiert geplant, so entstehen hohe Kosten, wenn die Kapazitätsgrenzen erreicht sind.
#
Í
Analyse des Bedarfs an Leitungskapazität in der Vergangenheit. Prognose der zu versorgenden Verbraucher (Datenformate, Geräteleistungsaufnahmen, Anzahl Geräte). Kostenanalyse des heute technisch Machbaren und Gegenüberstellung zu den Kosten von Nachrüstungen. Bei der Planung der Leitungen sollten Experten hinzugezogen werden, deren Projekterfahrung eine realistische Einschätzung der in Zukunft benötigten Leitungskapazitäten sichert.
163
A Physikalische Ebene
A.1
Planungsphase
A.1.5
Versorgungsleitungen sind redundant ausgelegt.
Om
Si
Zm
Wi
Ko
V
A.1.5.1 A.1.5.2
Welche Leitungsredundanzen sind eingeplant worden? Nach welchen Vorgaben sind die Redundanzen eingeplant worden?
L
Redundante Versorgungsleitungen bieten z. B. die Stromversorgung über ein Notstromaggregat. Sind Versorgungsleitungen nicht redundant geplant, kann bei Ausfällen einzelner Leitungen der gesamte Betrieb gefährdet sein. Dies kann zu existenzgefährdenden Schäden führen.
#
Í
A.2
Stromversorgung von wichtigen physischen Einrichtungen redundant einplanen. Die Klimaversorgungsleitungen den Anforderungen entsprechend einplanen. Den Anschluss an öffentliche Versorgungsnetze durch Sicherheitsmaßnahmen vor Sabotage sichern. Ist die zu prüfende physische Einrichtung ein Rechenzentrum, so können die Maßnahmen anhand der Tier-Level-Definitionen geprüft werden. Diese sind im Internet erhältlich. Vergleiche: BSI GSK B 2.1
Entwicklungsphase Da es keine direkte Unterscheidung der Entwicklungsphase und der Implementierungsphase im Bereich der Physischen Ebene in den GoIT gibt, sind alle Anforderungen in der Implementierungsphase enthalten.
164
A.3 Implementierungsphase
A.3
Implementierungsphase A.3.1
Bei der Realisierung sind die Anforderungen der Planungsphase berücksichtigt worden.
Om
Si
Zm
Wi
Ko
V
A.3.1.1 A.3.1.2
Wo ist die Umsetzung dokumentiert? Wer war für die Erfüllung der Anforderungen zuständig?
L
Planungsanforderungen sind alle dokumentierten Ergebnisse der in der Planungsphase getroffenen Entscheidungen. Werden geplante Maßnahmen nicht umgesetzt, entfalten sie natürlich auch ihre Wirkung nicht.
#
Í
Planungsanforderungen bei der Umsetzung dokumentieren. Verantwortliche für die Umsetzung definieren. Werden Planungsmaßnahmen bewusst nicht umgesetzt, so ist zu dokumentieren, warum sie nicht beachtet wurden. Bei der Prüfung sind die Dokumente aus der Planungsphase mit der Dokumentation der Umsetzungsphase zu vergleichen. Stichproben bei einzelnen Bereichen möglich. Der beste Ansprechpartner ist hier der Projektmanager der Planungsund Umsetzungsphase. Bei vielen Vorhaben sind dies Ingenieur- oder Architekturbüros. Vergleiche: BSI GSK B 2.1
165
A Physikalische Ebene
A.3
Implementierungsphase
A.3.2
Beim Einzug in eine gemietete Einrichtung sind Sicherheitsmaßnahmen geprüft worden.
Om
V
Si
A.3.2.1 A.3.2.2 A.3.2.3
L
Zm
Wi
Ko
Welche Maßnahmen sind durch den Eigentümer getroffen worden? Welche Maßnahmen der Planungsphase sind durch bereits vorhandene Sicherheitsmaßnahmen überflüssig geworden? Welche Maßnahmen sind in Mietverträgen erwähnt?
Bei den meisten gemieteten Einrichtungen sind gewisse Maßnahmen schon durch den Besitzer umgesetzt. Bei manchen Einrichtungen mit mehreren Parteien sind Maßnahmen (z. B. Pförtnerdienst oder Wachschutz) notwendig und teilweise schon vorhanden. Wenn Sicherungsmaßnahmen nicht geprüft worden sind, können Maßnahmen doppelt getroffen oder vernachlässigt werden. Dies hat Auswirkungen sowohl auf den Schutz der physischen Einrichtung als auch auf die Investitionskosten für die Sicherungsmaßnahmen.
#
Í
166
Berücksichtigen von Sicherheitsmaßnahmen bei der Auswahl der Mieteinrichtungen. Gemietete Einrichtungen vor Bezug durch das Sicherheitsmanagement prüfen. Dokumentieren der Sicherheitsmaßnahmen. Sicherheitsmaßnahmen sind meistens in den Mietverträgen enthalten. Vergleiche: BSI GSK B 2.1
A.4 Betriebsphase
A.4
Betriebsphase A.4.1
Der Zutritt zum Gebäude wird kontrolliert.
Om
V
Si
A.4.1.1 A.4.1.2 A.4.1.3
L
Zm
Wi
Ko
Wie wird der Zutritt kontrolliert? In welcher Weise sind die Mitarbeiter über das Verhalten bei unbefugtem Zutritt informiert? Welche Regelungen gibt es zur Schlüsselverwaltung?
Das Gebäude als Teil der Physikalischen Ebene umgibt die aufgestellte Informationstechnik. Sie stellt damit den äußeren Schutz dar. Die Anforderungen ergeben sich aus diesem Grund auch nur aus Vorschriften, die einen physikalischen Schutz fordern. Wenn der Zutritt nicht kontrolliert wird, können Unbefugte in das Gebäude eindringen. Dies kann zu Diebstahl und Vandalismus führen.
#
Í
Installieren eines zentral verwaltbaren Schließsystems. Überwachung durch Sicherheitspersonal. Überwachungstechnik planen und einsetzen. Sollte ein geregelter Besucherverkehr in Ihrem Gebäude stattfinden, so können Sie die Sicherungsmaßnahmen auf die schützenswerten Räume eingrenzen. Vergleiche: BSI GSK B 2.1
Siehe auch (in GoIT): Abschnitt A.1.2
167
A Physikalische Ebene
A.4
Betriebsphase
A.4.2
Es sind Schutzmaßnahmen gegen Bedrohungen von außen und aus der Umgebung getroffen worden.
Om
V
Si
A.4.2.1 A.4.2.2 A.4.2.3 A.4.2.4
L
Zm
Wi
Ko
Welche Schutzmaßnahmen wurden gegen Umgebungsbedrohungen getroffen? Wo wurden die Maßnahmen dokumentiert? Wer war für die Planung und die Umsetzung verantwortlich? Welche der möglichen Bedrohungen wurden betrachtet?
Bedrohungen von außen und aus der Umgebung sind im Sinne der GoIT höhere Gewalt und menschliche Fehlhandlungen, die aus der Lage des Gebäudes herrühren (z.B. Autobahnen und Flughäfen). Werden gegen die Bedrohungen von außen und aus der Umgebung nicht geeignete Maßnahmen getroffen, kann das zu katastrophalen Schäden durch Feuer, Wasser, Erdbeben, Explosionen, Sabotage oder Terroranschläge führen.
#
Einbindung des Sicherheitsmanagements bei der Planung von Gebäuden. Einbruchsicherung von Fenstern und Türen im Erdgeschoss. Sicherung der Kellerräume gegen Wassereinbruch. Einrichtung einer Gefahrenmeldeanlage für alle Arten von Bedrohungen.
Í
Erste Erkenntnisse, welche Maßnahmen am effektivsten sind, liefert die Betrachtung der Umgebung des Gebäudes (im Umkreis von ca. 300-400 m). So sind die Bedrohungen einfacher einzugrenzen und deren Eintrittswahrscheinlichkeit besser zu bestimmen.
168
Vergleiche: BSI GSK B 2.1 ISO 27001 A.9.1.4
A.4 Betriebsphase
A.4
Betriebsphase
A.4.3
Öffentliche Zugänge, Anlieferungs- und Ladezonen werden kontrolliert.
Om
V
Si
A.4.3.1 A.4.3.2 A.4.3.3 A.4.3.4
L
Zm
Wi
Ko
Wie wird der Zugang kontrolliert? Wo befindet sich IT in dieser Umgebung? Welche Zutrittsbeschränkungen gibt es von öffentlichen Zugängen zu gesicherten Gebäudeteilen? Wie wird der Zutritt von Zulieferern geregelt?
Öffentliche Zugänge, Anlieferungs- und Ladezonen sind Bereiche, in denen sich nicht nur Mitarbeiter des Unternehmens aufhalten, sondern auch Zulieferer oder Besucher. Durch unkontrollierte Zugänge können sich Unbefugte Zutritt verschaffen. Dies kann zu Diebstahl und Vandalismus führen
#
Öffentliche Zugänge mit einem Pförtnerdienst versehen. In den Anlieferungs- und Ladezonen Überwachungstechnik einsetzen. Besucherlisten führen. Definieren eines Prozesses für die geregelte Anlieferung (wer liefert was, wann in welchem Auftrag?). Mitarbeiter im Umgang mit Unbefugten schulen.
Í
Werden öffentliche Zugänge mithilfe von Überwachungstechnik abgesichert, so ist deutlich sichtbar darauf hinzuweisen. Dies muss im Einklang mit den gesetzlichen Anforderungen geschehen (Datenschutz).
Vergleiche: BSI GSK B 2.1 KRITIS ISO 27001 A.9.1.6
169
A Physikalische Ebene
A.4
Betriebsphase
A.4.4
Die Arbeit in Sicherheitszonen ist geregelt.
Om
V
Si
A.4.4.1 A.4.4.2 A.4.4.3 A.4.4.4
L
Zm
Wi
Ko
Welche Regelungen existieren für die Arbeit in Sicherheitszonen? Wann sind die Mitarbeiter das letzte Mal geschult worden? Welche besonderen Anweisungen sind den Mitarbeitern im Bereich Arbeitsschutz mitgeteilt worden? Wie wird die Regelungsübergabe dokumentiert?
Sicherheitszonen sind besonders wichtige Bereiche in physischen Einrichtungen. In diesen Zonen sind besondere Maßnahmen anzuwenden. Die Arbeit in diesen Zonen kann deshalb nur von speziell ausgebildetem Personal durchgeführt werden. Diese speziellen Anforderungen müssen geregelt sein. Durch nicht geregelte Arbeit in Sicherheitszonen können bei Notfällen Schäden an Leib und Leben der dort Arbeitenden entstehen.
#
Í
170
Mitarbeiter für die Arbeit in Sicherheitszonen schulen. Hinweise und Regelungen als Teil des Arbeitsvertrages dokumentieren. Um festzustellen, ob und wann Mitarbeiter, die in Sicherheitsbereichen arbeiten, auf die Richtlinien hingewiesen wurden, kann ein Blick in den Anhang der Arbeitsverträge hilfreich sein. Vergleiche: BSI GSK B 2.1 KRITIS ISO 27001 A.9.1.6
A.4 Betriebsphase
A.4
Betriebsphase
A.4.5
Betriebsmittel sind vor unerlaubtem Zugriff physisch gesichert.
Om
V
Si
A.4.5.1 A.4.5.2 A.4.5.3
L
Zm
Wi
Ko
Welche physischen Maßnahmen sind für den Schutz von Betriebsmitteln getroffen worden? Sind die Maßnahmen mit dem Sicherheitsmanagement abgestimmt? Wie sind die Mitarbeiter auf die physischen Sicherungsmaßnahmen hingewiesen worden?
Betriebsmittel sind im Sinne der GoIT alle informationstechnischen Mittel. Dazu zählen z.B. auch USB-Speichermedien, Drucker und Faxgeräte. Sind die Betriebsmittel nicht vor unerlaubtem Zugriff physisch gesichert, kann dies zu Diebstahl und Vandalismus führen.
#
Í
Mobile Endgeräte gegen Diebstahl sichern. Bei Verlassen der Einrichtung sind die Betriebsmittel verschlossen aufzubewahren. Betriebsmittel, die nicht verschlossen aufbewahrt werden können, durch andere geeignete Maßnahmen sichern. Bei der Absicherung von mobilen Endgeräten hilft es, diese mit einem schweren Einrichtungsgegenstand zu verketten. Vergleiche: BSI GSK B 2.1 KRITIS ISO 27001 A.9.1.6
171
A Physikalische Ebene
A.4
Betriebsphase
A.4.6
Bei physischen Einrichtungen mit Publikumsverkehr sind die Informationsträger gesondert zu sichern.
Om
V
Si
A.4.6.1 A.4.6.2 A.4.6.3
L
Zm
Wi
Ko
Wie werden informationstechnische Anlagen gegen Diebstahl gesichert? Wie wird eine Manipulation der informationstechnischen Anlagen verhindert? Wie werden die Mitarbeiter über ihre Aufgaben und Pflichten informiert?
Physische Einrichtungen mit Publikumsverkehr sind in vielen Unternehmen zu finden. Informationstechnischen Anlagen in diesen Räumen sind durch gesonderte Maßnahmen zu schützen. In einem unbewachten Moment können Geräte entwendet oder manipuliert werden. Dies kann zu erheblichen Schäden und zur Behinderung der Aufgabenerfüllung sowie zum Verlust vertraulicher Informationen führen.
#
Für IT-Systeme in Büroräumen mit Publikumsverkehr Diebstahlsicherungen anschaffen und installieren. Regelungen zum Verschließen von Türen treffen. Unterlagen und Datenträger mit vertraulichem Inhalt verschlossen aufbewahren. Für den Fall eines Diebstahls geeignete Gegenmaßnahmen planen und dokumentieren. Mitarbeiter sensibilisieren.
Í
Insbesondere mobile Endgeräte und Datenträger sind gegen Diebstahl zu sichern, um den Diebstahl an sich zu verhindern. Das Verschlüsseln von Datenträgern schützt vor Missbrauch der Daten.
172
Vergleiche: BSI GSK B 3.203 BSI GSK B 3.405 ISO 27001 A.9.2.1
A.4 Betriebsphase
A.4
Betriebsphase
A.4.7
Physische Einrichtungen, in denen sich Mitarbeiter aufhalten, sind gegen unbefugten Zutritt gesichert.
Om
V
Si
A.4.7.1 A.4.7.2 A.4.7.3 A.4.7.4
L
Zm
Wi
Ko
Welche Regelungen existieren zum Schließen von Türen und Fenstern? Welche Regelungen existieren zum Abschließen der Türen? Wo befindet sich das Schlüsselverzeichnis? Wie werden die Mitarbeiter über ihre Aufgaben und Pflichten hinsichtlich des Zutrittsschutzes informiert?
Dies sind Räume, in denen Mitarbeiter ihrer Arbeit nachgehen. Dies kann mit unterschiedlichsten informationstechnischen Anlagen geschehen. Werden Zugänge nicht kontrolliert, können sich Unbefugte Zutritt verschaffen. Der Zugang zu informationstechnischen Anlagen ist damit ungehindert möglich. Dies kann zu Diebstahl und Vandalismus führen.
#
Regelungen zum Schließen/Verschließen von Türen und Fenstern treffen. Unterlagen und Datenträger mit vertraulichem Inhalt verschlossen aufbewahren. Für das Ausscheiden von Mitarbeitern einen Laufzettel führen, auf dem die Rückgabe der Zutrittsmittel vermerkt ist. Mitarbeiter sind zu sensibilisieren.
Í
Ob eine physische Einrichtung zu verschließen ist, hängt von der Tätigkeit der Mitarbeiter ab. So sind die Büroräume, in denen personenbezogene Daten verarbeitet werden, immer zu verschließen.
Vergleiche: BSI GSK B 2.3 ISO 27001 A.9.1.3
173
A Physikalische Ebene
A.4
Betriebsphase
A.4.8
Physische Sicherheitsmaßnahmen sind dokumentiert.
Om
Si
Zm
Wi
Ko
V
A.4.8.1 A.4.8.2
Wie werden physische Sicherheitsmaßnahmen dokumentiert? Wo befindet sich die Dokumentation?
L
Eine Dokumentation kann ein Sicherheitskonzept darstellen. Es ist für die Prozessverfolgung von großer Wichtigkeit zu wissen, welche Maßnahmen schon getroffen worden sind. Werden Sicherheitsmaßnahmen nicht dokumentiert, besteht die Gefahr, dass Risiken nicht behandelt oder Maßnahmen doppelt umgesetzt werden (das Rad wird immer wieder neu erfunden). Dies kann zu finanziellen Schäden führen. Das erstrebte Sicherheitsniveau wird nie erreicht.
#
Í
174
Ein geeignetes Sicherheitskonzept für die physische Sicherheit erstellen und in regelmäßigen Abständen aktualisieren. Die Dokumentation darf nur befugten Personen zugänglich gemacht werden. Die Beschränkung der Zugriffsmöglichkeiten und die kontinuierliche Aktualisierung lassen sich am ehesten mithilfe eines online-gestützten Dokumentmanagements umsetzen. Dies erleichtert auch die Revision der Dokumente. Vergleiche: BSI GSK B 2.3 ISO 27001 A.9.1.3
A.4 Betriebsphase
A.4
Betriebsphase
A.4.9
Notfallmaßnahmen für physische Einrichtungen sind definiert.
Om
Si
Zm
Wi
Ko
V
A.4.9.1 A.4.9.2 A.4.9.3
Welche Notfallmaßnahmen sind definiert worden? Wo sind diese dokumentiert? Wer sind die im Notfall Verantwortlichen?
L
Notfallmaßnahmen für physische Einrichtungen sind z.B. Richtlinien für das Verhalten im Brandfall oder bei Entdeckung eines Einbruchs. Diese sind zwar nicht im Fokus der IT-Revision, haben aber im Notfall immensen Einfluss auf die IT-Systeme. Sind Notfallmaßnahmen nicht definiert, so kann dies zu erheblichen Schäden bei Eintritt eines Notfalls nach sich ziehen, weil geeignete Maßnahmen nicht umgesetzt sind.
#
Í
Notfallmaßnahmen für physische Einrichtungen ins Notfallhandbuch aufnehmen. Die betroffenen Mitarbeiter schulen. Das Notfallhandbuch als zentrales Dokument sollte alle Notfallmaßnahmen enthalten. Die Schulungen der Mitarbeiter können anhand von Schulungsterminen der Berufsgenossenschaften nachgewiesen werden. Vergleiche: BSI GSK B 2.3 ISO 27001 A.9.1.3
175
A Physikalische Ebene
A.4
Betriebsphase
A.4.10 Notfallübungen werden durchgeführt.
Om
Si
Zm
Wi
Ko
V
A.4.10.1 A.4.10.2 A.4.10.3 A.4.10.4
Wann sind die letzten Notfallübungen durchgeführt worden? Wo sind diese dokumentiert? Wer sind die Notfallverantwortlichen? Wie wurde die Nachbereitung durchgeführt?
L
Notfallübungen im Zusammenhang mit dem Schutz physischer Einrichtungen sind z.B. Brandschutzübungen oder Übungen zum Verhalten bei Bombendrohungen. Diese sind zwar nicht im Fokus der IT-Revision, haben aber im Notfall immensen Einfluss auf die IT-Systeme. Werden Notfallübungen nicht durchgeführt, kann dies bei Eintritt eines Notfalls zu erheblichen Schäden führen, weil geeignete Maßnahmen nicht oder falsch umgesetzt werden, da den Mitarbeitern die Übung und damit die Sicherheit fehlt.
#
Í
A.5
Regelmäßig Notfallübungen durchführen. Die Ergebnisse einer Notfallübung dokumentieren. Notfallübungen sollten Sie nicht im laufenden Betrieb oder am Produktivsystem durchführen. Eine Trockenübung kann hier hilfreich sein. So können Sie z.B. Mitarbeiter mit dem Fokus auf der Eskalationsstrategie abfragen. Wenn die Voraussetzungen dafür gegeben sind, sollten die Notfalltests in einer Testumgebung durchgeführt werden. Vergleiche: BSI GSK B 2.3 ISO 27001 A.9.1.3
Migration In der Physikalischen Ebene wird die Migration nicht betrachtet. Ein Umzug wird vollzogen in den Schritten Planung und Implementierung der Zieleinrichtung und dem Auszug aus der Ursprungseinrichtung. Der Betrieb, der während einer Migration auf physikalischer Ebene erhalten werden muss, wird durch die Kontinuitätsanforderungen auf der Systemebene sichergestellt. Ein Roll-Off im Sinne der GoIT kann erst erfolgen, sobald die Betriebsphase der Zieleinrichtung erfolgreich gestartet wurde.
176
A.6 Roll-Off
A.6
Roll-Off A.6.1
Der Auszug aus physischen Einrichtungen ist geregelt.
Om
V
Si
A.6.1.1 A.6.1.2 A.6.1.3 A.6.1.4
L
Zm
Wi
Ko
Welche Regelungen existieren zu einem Auszug aus physischen Einrichtungen? Wer leitet den Umzug? Wer ist für die Einhaltung der Sicherheitsmaßnahmen verantwortlich? Wie werden die Mitarbeiter über ihre Aufgaben und Pflichten während eines Auszuges informiert?
Bei einem Auszug aus einem Gebäude sind viele Maßnahmen zu beachten. Ein Umzug sollte durch ein Projektteam geplant werden. Ist der Auszug aus physischen Einrichtungen nicht oder nur unzureichend geregelt, ergeben sich Gefahren, da der erreichte Sicherheitsstandard von physischen Einrichtungen durch Unachtsamkeit und Ad-hoc-Maßnahmen korrumpiert und gesenkt wird.
#
Í
Maßnahmen der GoIT A.4.7 umsetzen. Unterlagen und Datenträger mit vertraulichem Inhalt sind verschlossen zu transportieren. Mitarbeiter sind über die Aufgaben zu informieren, die sie während des Auszuges zu erledigen haben. Für den Auszug sollte ein Team zusammengestellt werden, das die jeweiligen Teilprozesse eines Auszuges vom Auswählen einer Transportfirma über die Bewachung der IT-Systeme bis zur geordneten Vernichtung der nicht mehr benötigten Informationstechnologie regelt. Vergleiche: BSI GSK B 2.3 ISO 27001 A.9.1.3
Siehe auch (in GoIT): Abschnitt A.4.7
177
A Physikalische Ebene
A.6
Roll-Off
A.6.2
Betriebsmittel werden ordnungsgemäß entsorgt.
Om
Si
Zm
Wi
Ko
V
A.6.2.1 A.6.2.2
Wie werden Betriebsmittel entsorgt? Wie werden die Entsorgungsnachweise geführt?
L
Bei einem Auszug aus einer physischen Einrichtung werden einige Betriebsmittel nicht mehr benötigt. Diesem „Abfall“ wird kaum Beachtung geschenkt. Dieser muss aber im Einklang mit den Gesetzen (Umweltverordnungen, Datenschutzgesetz) entsorgt werden. Wird die Betriebsmittelentsorgung nachweisbar dokumentiert, ist von einer ordnungsgemäßen Entsorgung im Sinne der GoIT zu sprechen. Auch nicht mehr benötigte Betriebsmittel können wichtige Informationen enthalten, die in unbefugte Hände gelangen können. Dies kann zu erheblichen finanziellen und Imageschäden führen.
#
Í
178
Betriebsmittel ordnungsgemäß entsorgen. Betriebsmittel mit vertraulichen Daten physikalisch vernichten. Mitarbeiter über die ordnungsgemäße Entsorgung informieren. Für den Auszug sollte ein Team zusammengestellt werden, das die jeweiligen Teilprozesse eines Auszuges vom Auswählen einer Transportfirma über die Bewachung der IT-Systeme bis zur geordneten Vernichtung der nicht mehr benötigten Informationstechnologie regelt. Vergleiche: BSI GSK B 2.3 ISO 27001 A.9.1.3
A.6 Roll-Off
A.6
Roll-Off
A.6.3
Bestandsverzeichnisse sind auf dem aktuellen Stand.
Om
Si
Zm
Wi
Ko
V
A.6.3.1 A.6.3.2 A.6.3.3
Wie werden die Bestandsverzeichnisse geführt? Wer ist für Verwaltung zuständig? Wie werden Verlust oder Diebstahl nachgehalten?
L
Bestandsverzeichnisse beinhalten den aktuellen Stand der kompletten Informationstechnologie. Sie können als Excel-Listen, in Papierform oder mithilfe einer Software-Anwendung geführt werden. Werden keine Bestandsverzeichnisse geführt, ist eine geregelte Außerbetriebnahme nicht möglich. Des Weiteren kann ein Diebstahl oder Verlust nicht nachvollzogen werden. Dies kann zu Verlust oder Missbrauch wichtiger Informationen und damit zu erheblichen finanziellen Schäden und einem enormen Imageverlust führen.
#
Í
Bestandsverzeichnisse führen. Eingänge und Ausgänge eindeutig nachvollziehbar dokumentieren. Bestandsverzeichnisse können auch in einem vielleicht schon vorhandenen ERPSystem geführt werden. Dieses ist einfacher zu prüfen, sofern die ERP-Software den gesetzlichen Anforderungen genügt. Werden Strichcodes verwendet, ist die Prüfung der Verzeichnisse stichprobenartig zu überprüfen. Vergleiche: BSI GSK B 2.3 ISO 27001 A.9.1.3
Siehe auch (in GoIT): Abschnitt A.6.2
179
B B Netzwerkebene Zu der Netzwerkebene gehören Netzgeräte wie Router Switches Bridges Netzwerkverkabelung
181
B Netzwerkebene
B.1
Planungsphase B.1.1
Eine geeignete Netzwerksegmentierung ist geplant.
Om
Si
Zm
Wi
Ko
V
B.1.1.1 B.1.1.2
Wie wurde das Netzwerk segmentiert? Welcher Fokus wurde angesetzt (Verfügbarkeit, Vertraulichkeit, Integrität)?
L
Eine Netzwerksegmentierung erleichtert die sichere Datenflusskontrolle im laufenden Betrieb. Wird sie in der Planungsphase eines Netzwerkes berücksichtigt, ist eine teure nachträgliche Segmentierung nicht mehr notwendig, insbesondere bei der Vernetzung von Standorten. Eine nicht ausreichende Berücksichtigung führt dazu, dass Maßnahmen nachträglich entweder nur mit hohen Kosten oder gar nicht mehr umgesetzt werden können.
#
Í
182
Das Netzwerk geeignet segmentieren. Die Übergänge dokumentieren. Eine geeignete Segmentierung wäre z.B., dass keine Daten zwischen der Personalabteilung und dem Rest des Netzes unbeabsichtigt übertragen werden können. Vergleiche: BSI GSK M 5.61 Geeignete physikalische Segmentierung M 5.62 Geeignete logische Segmentierung
B.1 Planungsphase
B.1
Planungsphase
B.1.2
Bei der Planung sind Sicherheitsmaßnahmen zum Schutz des Netzwerkes getroffen worden.
Om
V
Si
B.1.2.1 B.1.2.2
L
Zm
Wi
Ko
Welche Sicherheitsmaßnahmen sind für den Schutz des Netzwerkes getroffen worden? Wo sind diese Maßnahmen dokumentiert?
Sicherheitsmaßnahmen zum Schutz des Netzwerkes sind in der Planungsphase viel einfacher festzulegen als später. Dies kann insbesondere bei der Beschaffung von Netzwerkkomponenten sehr viel Kosten und Mühen sparen. Bei der Planung des Netzwerkes können die Anforderungen an die Netzwerkkomponenten definiert werden. So können Ausschreibungen besser gestaltet werden und führen somit zu besseren Ergebnissen. In der Planungsphase nicht betrachtete Sicherheitsmaßnahmen gefährden das angestrebte Sicherheitsniveau. Eine Realisierung der Maßnahmen wird dadurch kostenintensiver oder unmöglich.
#
Einbindung des Sicherheitsmanagements bei der Planung von Netzwerken. Netzübergänge besonders beachten. Anforderungen an die Hardware definieren.
Í
Für die Planungsphase und die Beschaffung kann die Erstellung eines geeigneten Netzkonzepts helfen. Eine Hilfe zur Erstellung gibt das BSI. Siehe Vergleiche
Vergleiche: BSI GSK M 2.141 Entwicklung eines Netzkonzeptes
183
B Netzwerkebene
B.1
Planungsphase
B.1.3
Das physische Netzwerk ist vor unbefugten Zugängen geschützt.
Om
V
Si
B.1.3.1 B.1.3.2
L
Zm
Wi
Ko
Welche Schutzmaßnahmen wurden für den physikalischen Schutz des Netzwerks ergriffen? Wo sind die Maßnahmen dokumentiert?
Während der Planung sollte auch der physikalische Schutz des Netzwerks eine große Rolle spielen. Zum physikalischen Netzwerk gehören Verkabelung, Kabeltrassen, Patchfelder und Dosen. Diese können durch verschiedene Maßnahmen geschützt werden. Wird die physikalische Ebene eines Netzwerks nicht geschützt, so kann menschliches Fehlverhalten (beabsichtigt oder unbeabsichtigt) zu erheblichen Ausfällen führen. Aufgrund fehlenden Zugangsschutzes könnten Dritte unbefugt an vertrauliche Informationen gelangen.
#
Einbindung des Sicherheitsmanagements bei der Planung des physischen Netzwerkes. Ausreichende Trassen-Dimensionierung. Planung von Sicherheitsmaßnahmen bei zugänglichen Bereichen.
Í
Das Netzkonzept sollte um die physische Sicherheit des Netzwerkes ergänzt werden. Wie dies zu dokumentieren ist, findet sich in der Maßnahme 2.141 der BSI-Grundschutzkataloge.
184
Vergleiche: BSI GSK M 2.141 Entwicklung eines Netzkonzeptes
B.1 Planungsphase
B.1
Planungsphase
B.1.4
Ein Netzwerkrealisierungsplan ist vorhanden.
Om
V
Si
B.1.4.1 B.1.4.2
L
Zm
Wi
Ko
Welche Anforderungen sind im Netzwerkrealisierungsplan enthalten? Wurde das Netzwerk neu geplant oder erweitert?
Der Netzwerkrealisierungsplan setzt die Anforderungen der Planungsphase (Netzkonzept) um und stellt die geeigneten Maßnahmen zur Umsetzung zur Verfügung. Der Netzwerkrealisierungsplan kann bei einer kompletten Neuerstellung eines Netzwerks oder bei der Umplanung/Erweiterung des vorhandenen Netzwerks als Dokumentation geführt werden. Werden geplante Maßnahmen nicht umgesetzt, können sie auch ihre Wirkung nicht entfalten.
#
Erstellen des Netzwerkrealisierungsplans. Dokumentieren aller Maßnahmen, die nicht umgesetzt werden können.
Í
Das Netzkonzept stellt das Soll dar und der Realisierungsplan das Statement of Applicability. Somit ist eine Dokumentation auch auf Basis der ISO 27001 verwendbar.
Vergleiche: BSI GSK M 2.142 Entwicklung eines Netz-Realisierungsplans ISO 27001 “Statement of applicability“
185
B Netzwerkebene
B.1
Planungsphase
B.1.5
Eine geeignete Netzkopplung ist eingeplant.
Om
Si
Zm
Wi
Ko
V
B.1.5.1 B.1.5.2 B.1.5.3
Welche Teilnetze werden verbunden? Welche Technologie wird für die Netzkopplung verwendet? Wo sind die Netzkopplungen eingetragen?
L
Für den Übergang zwischen einzelnen Netzsegmenten sind die Netzkopplungselemente geeignet zu planen. Sie müssen die Anforderungen an die Vertraulichkeit der Teilsegmente, die Verfügbarkeit des Netzes und die Integrität der Datenübertragung erfüllen. In der Planungsphase nicht betrachtete Sicherheitsmaßnahmen gefährden das angestrebte Sicherheitsniveau. Eine Realisierung der Maßnahmen wird sonst kostenintensiver oder unmöglich.
#
Í
B.2
Eignung der Netzkopplungsgeräte prüfen. Netzkopplungen explizit im Netzplan dokumentieren. Bei der Netzkopplung sollte man zwischen vertrauenswürdigen und nicht vertrauenswürdigen Netzen unterscheiden. So kann eine Netzkopplung zwischen vertrauenswürdigen Netzen durch einen Router oder Switch erfolgen. Bei der Verbindung in unsichere Netze sollte ein oder mehrere Application Level Gateways eingesetzt werden. Vergleiche: BSI GSK M 5.13 Geeigneter Einsatz von Elementen zur Netzkopplung
Entwicklungsphase In der Regel findet in der Netzwerkebene keine Entwicklung im Sinne eigenentwickelter Netzwerkkomponenten statt. Aus diesem Grund wurden für die Entwicklungsphase keine Anforderungen aufgenommen.
186
B.3 Implementierungsphase
B.3
Implementierungsphase B.3.1
Das Netzwerk ist auf Engpässe überprüft.
Om
Si
Zm
Wi
Ko
V
B.3.1.1 B.3.1.2
Welche Engpässe sind gefunden worden? Wie wurden diese Engpässe beseitigt?
L
Die Anforderungen an die Verfügbarkeit sind hier mit der entweder geplanten oder der vorhandenen Netzwerksituation zu vergleichen. Engpässe sind zu definieren und durch eine Segmentierung zu entschärfen. Werden Engpässe durch das Kapazitätsmanagement nicht gefunden, kann die Verfügbarkeit des Netzes nicht gewährleistet werden.
#
Das Netzwerk auf Engpässe überprüfen. Engpässe bei Netzsegmenten mit einer hohen Anforderung an die Verfügbarkeit beseitigen. Die Engpässe und die Gegenmaßnahmen dokumentieren.
Í
Bei einem bestehenden Netzwerk können die Engpässe durch Lasttests gefunden werden. Bei neuen Netzen ist dies schwieriger. Es empfiehlt sich, die Netzpläne mit den Anforderung an die Verfügbarkeit zu vergleichen und Netzkopplungselemente zwischen hochverfügbaren Netzen redundant auszulegen oder diese mit der Möglichkeit der Lastverteilung zu clustern.
Vergleiche: BSI GSK M 2.140 BSI GSK M 2.139
187
B Netzwerkebene
B.3
Implementierungsphase
B.3.2
Die Verwaltung der Netzkomponenten ist zentral gesteuert.
Om
Si
Zm
Wi
Ko
V
B.3.2.1 B.3.2.2
Wie werden die Netzkomponenten verwaltet? Wer zeichnet sich verantwortlich für die Verwaltung der Netzkomponenten?
L
Netzkomponenten sind z.B. Firewalls, Router, Switches, Managed Hubs. Eine zentrale Steuerung der Verwaltung (Netzsteuerung) ist bei großen verteilten und segmentierten Netzen sinnvoll. Auch die Verwaltung des gesamten Netzes ist zentral zu steuern. Werden die Netzkomponenten nicht zentral verwaltet, lässt sich die Umsetzung der zentral geplanten Maßnahmen kaum nachvollziehen. Dadurch ist das geplante Sicherheitsniveau nicht oder nur schwer zu erreichen.
188
#
Netzwerkkomponenten zentral verwalten. Schulen der Mitarbeiter für ihren Teilbereich. Geeignete Software für die Verwaltung beschaffen und implementieren.
Í
Eine zentrale Verwaltung der Netzkomponenten kann schon anhand einer gut geführten Bestandsliste und einem Maßnahmenkatalog verwaltet werden. Meist liefern die Hersteller der Netzelemente eine Verwaltungssoftware für die aktiven Netzkomponenten mit.
B.3 Implementierungsphase
B.3
Implementierungsphase
B.3.3
Eine vollständige Netzdokumentation ist vorhanden.
Om
Si
Zm
Wi
Ko
V
B.3.3.1 B.3.3.2 B.3.3.3
Welche Dokumente sind vorhanden? Welche Maßnahmen sind als obsolet definiert worden? Wann fand die letzte Aktualisierung der Netzdokumentation statt?
L
Vollständigkeit der Netzdokumentation bedeutet, dass sowohl Dokumente aus der Planungsphase als auch aus der Implementierung vorhanden sind. Diese Dokumente sollten aufeinander aufbauen. Folgende Dokumente sollten in aktueller Fassung vorhanden sein: Netzpläne Netzkonzept Netzrealisierungsplan Durch das Fehlen der Dokumentation können Maßnahmen nicht überprüft oder gesteuert werden. Das hat zur Folge, dass das angestrebte Sicherheitsniveau nicht erreicht werden kann.
#
Í
Die Netzsituation geeignet dokumentieren. Die Dokumente aktualisieren. Vorgaben für die Inhalte der Dokumentation können Sie den Grundschutzkatalogen des BSI entnehmen. Vergleiche: BSI GSK B 4.1
189
B Netzwerkebene
B.3
Implementierungsphase
B.3.4
Mit Netzwerkbetreibern sind geeignete Verträge abgeschlossen.
Om
V
Si
B.3.4.1 B.3.4.2 B.3.4.3
L
Zm
Wi
Ko
Welche Verträge sind mit den Netzbetreibern geschlossen worden? Wie werden die einzelnen Anforderungen der Planungsphase beachtet? Welche Gesetze sind berücksichtigt worden?
In vielen Institutionen werden Netzwerke nicht mehr durch die eigenen Mitarbeiter verwaltet, sondern sind zu Netzwerkbetreibern ausgelagert, was geeignete Netzverträge erfordert, die an die dafür geltenden gesetzlichen Grundlagen angepasst sind (§11 BDSG). Bestehen keine geeigneten Verträge mit den Netzwerkbetreibern, so kann man: unter Umständen gesetzliche Vorgaben nicht einhalten. Verantwortlichkeiten nicht eindeutig zuweisen. Sicherheitsmaßnahmen nicht vereinbaren und kontrollieren.
#
Í
190
Geeignete Verträge mit dem Netzbetreiber schließen. Die Verträge auf die Erfüllung der gesetzlichen Anforderungen prüfen. Ein Maßnahmenkatalog sollte erstellt und Teil des Vertrages werden. Im BDSG sind die im Vertrag zu regelnden Bereiche aufgeführt. Diese können als Basis für einen Vertrag verwendet werden. Bei der Vereinbarung von ServiceLeveln sollten auch die Sicherheitsmaßnahmen berücksichtigt werden. Vergleiche: BDSG § 11 Abs. 2
B.3 Implementierungsphase
B.3
Implementierungsphase
B.3.5
Netzkomponenten sind sicher zu konfigurieren.
Om
Si
Zm
Wi
Ko
V
B.3.5.1 B.3.5.2 B.3.5.3
Wie sind die Netzkomponenten konfiguriert? Welche Sicherheitsmaßnahmen sind umgesetzt worden? Welche Mitarbeiter sind informiert worden?
L
Netzkomponenten sind sicher konfiguriert, wenn ein Maßnahmenbündel umgesetzt wird, das regelt, dass z.B. voreingestellte Passwörter geändert oder Passworthinweise auf den Geräten entfernt werden müssen. Werden die Netzkomponenten nicht sicher konfiguriert, lassen sie sich sehr leicht manipulieren. Dies kann zu erheblichen Schäden führen, da vertraulich geglaubte Leitungen einfach abgehört werden können oder die Verfügbarkeit nicht mehr gewährleistet werden kann.
#
Í
Voreingestellte Passwörter ändern. Hinweise auf Passwörter von den Geräten entfernen. Auf ausreichende Komplexität der vergebenen Passwörter achten. Da Netzkomponenten sehr häufig gewechselt werden, sollten die Sicherheitsmaßnahmen in den Change-Prozess implementiert werden. Vergleiche: BSI M 4.7 BSI M 4.81
191
B Netzwerkebene
B.4
Betriebsphase B.4.1
Der Netzwerkverkehr wird protokolliert.
Om
Si
Zm
Wi
Ko
V
B.4.1.1 B.4.1.2 B.4.1.3
Welche Ereignisse werden protokolliert? In welcher Weise wird protokolliert? Wie werden die rechtlichen Rahmenbedingungen beachtet?
L
Eine Protokollierung erfolgt meistens an zentralen Punkten in einem Netzwerk. Hier werden z.B. die Performance des Netzwerkes zu bestimmten Zeiten, unerlaubte Zugriffe auf Netzkomponenten etc. mitgeschrieben (protokolliert). Dies muss immer unter Berücksichtigung geltender Gesetze geschehen. Missbrauch oder technische Fehler des Netzwerkes sind schwer zu erkennen, wenn keine Netzprotokollierung erfolgt.
#
Í
192
Aktivieren der Protokollierung an geeigneten Netzschnittstellen. Protokolle gesetzeskonform erstellen und aufbewahren. Um die große Anzahl verschiedener Protokolle zu verwalten, sollte in einem Protokollierungskonzept eine geeignete Vorgehensweise dokumentiert werden. Vergleiche: BSI GSK M 4.81
Siehe auch (in GoIT): Abschnitt C.3.2
B.4 Betriebsphase
B.4
Betriebsphase
B.4.2
Die Protokolle werden regelmäßig ausgewertet und auf Unregelmäßigkeiten geprüft.
Om
Si
Zm
Wi
Ko
V
B.4.2.1 B.4.2.2
Wie sind Unregelmäßigkeiten definiert? Welche Protokolle werden geprüft?
L
Unregelmäßigkeiten sind Ereignisse, die nicht in normalen Parametern verlaufen. Dies kann z.B. ein hoher Netzwerkverkehr außerhalb der Geschäftszeiten sein oder eine hohe Anzahl von fehlerhaften Anmeldeversuchen innerhalb sehr kurzer Zeit. Findet keine Protokollauswertung statt, dann bleiben Unregelmäßigkeiten unentdeckt. So bleiben auch Risiken und Gefährdungen bestehen und können zu erheblichen Schäden führen.
#
Unregelmäßigkeiten definieren. Wichtige Protokolle definieren. Geeignete Mitarbeiter für das Erkennen von Unregelmäßigkeiten schulen. Ein Protokollierungskonzept erstellen.
Í
Bei der Kontrolle von Protokollen auf Unregelmäßigkeiten können Ihnen moderne Intrusion-Detection-Systeme helfen. Sie prüfen Ihre definierten Protokolle nach bestimmten Mustern. Dies kann insbesondere an den Übergängen in nicht vertrauenswürdige Netze hilfreich sein.
Vergleiche: BSI GSK B 2.1 KRITIS ISO 27001 A.9.1.6
193
B Netzwerkebene
B.4
Betriebsphase
B.4.3
Ein Monitoring ist eingerichtet.
Om
V
Si
B.4.3.1 B.4.3.2 B.4.3.3
L
Zm
Wi
Ko
Wie wird eine dauerhafte Überwachung gewährleistet? Wann sind die Mitarbeiter diesbezüglich das letzte Mal geschult worden? Wie werden Zwischenfälle dokumentiert?
Während des Betriebs kann eine dauerhafte Überwachung (Monitoring) erhebliches Schadenspotenzial abfangen. Dies betrifft insbesondere die Überwachung der Netzauslastung. Fehlt das Monitoring oder wird es nicht geeignet umgesetzt, so kann es lange dauern, bis ein Fehler oder eine Manipulation auffällt. In dieser meist sehr großen Zeitspanne kann es zu Ausfällen oder anderen Schadensereignissen kommen. Diese ziehen erhebliche weitere Schäden nach sich.
#
Í
194
Monitoring einrichten. Regelungen für das Monitoring definieren. Um ein geeignetes Monitoring zu betreiben, sollten Sie die Anforderungen in einem Betriebskonzept festhalten oder ein schon vorhandenes Betriebskonzept (IT-System) um den Punkt des Netzwerk-Monitorings erweitern. Meist sind auf Systemseite schon Programme in Gebrauch, die für das Netzwerk-Monitoring auch geeignet sind. Hier bietet es sich an, sich den Bereich der IT-Systeme anzuschauen. Siehe auch (in GoIT): Abschnitt C.4.6
B.4 Betriebsphase
B.4
Betriebsphase
B.4.4
Das Verhalten bei Zwischenfällen ist definiert.
Om
Si
Zm
Wi
Ko
V
B.4.4.1 B.4.4.2 B.4.4.3
Wie sind Zwischenfälle definiert? Wie sollen sich die Mitarbeiter verhalten? Wie sind die Mitarbeiter auf das Verhalten bei Zwischenfällen hingewiesen worden?
L
Während des Betriebs eines Netzwerkes kann es zu Zwischenfällen kommen. Um diese Zwischenfälle in kürzester Zeit zu beheben, bedarf es einer Definition von Zwischenfällen und des korrekten Verhaltens während und nach dem Zwischenfall. Ist das Verhalten während eines Zwischenfalls nicht definiert, kann es zu Fehlhandlungen kommen, die direkte negative Auswirkungen auf die Verfügbarkeit, Integrität oder Vertraulichkeit haben.
#
Í
Zwischenfälle definieren. Das geeignete Verhalten bei Zwischenfällen definieren. Mitarbeiter für den Bereich Zwischenfälle schulen und sensibilisieren. Eine Definition der Zwischenfälle und des entsprechenden Verhaltens sollte Teil eines Betriebshandbuchs sein. Vergleiche: M 4.81 Audit und Protokollierung der Aktivitäten im Netz M 6.54 Verhaltensregeln nach Verlust der Netzintegrität
Siehe auch (in GoIT): Abschnitt C.4.6
195
B Netzwerkebene
B.4
Betriebsphase
B.4.5
Netzwerkadministratoren sind sorgfältig ausgewählt worden.
Om
Si
Zm
Wi
Ko
V
B.4.5.1 B.4.5.2 B.4.5.3
Wie werden Mitarbeiter ausgewählt? Wie wird die Echtheit der Angaben überprüft? Welche gesetzlichen Anforderungen werden betrachtet?
L
Eine sorgfältige Auswahl von Mitarbeitern ist nur möglich, wenn diese hinreichende und kontrollierbare Referenzen und einen aussagekräftigen und vollständigen Lebenslauf vorlegen. Dies sollte vor allem bei besonders sicherheitskritischen Aufgaben wie der Netzwerkadministration erfolgen. Eine falsche Administratorauswahl kann zu unbedachten Handlungen des Administrators führen. Diese können erhebliche Schäden anrichten.
#
Í
196
Von den Bewerbern geeignete Unterlagen einfordern Die Angaben der Referenzen gegenprüfen. Die Möglichkeiten, Personal überprüfen zu lassen, sind in Deutschland rechtlich sehr eingeschränkt. Dazu kommt, dass die Ergebnisse meist wenig aussagekräftig sind wie z. B. bei polizeilichen Führungszeugnissen. Vergleiche: M 3.33 Sicherheitsüberprüfung von Mitarbeitern
B.4 Betriebsphase
B.4
Betriebsphase
B.4.6
Netzwerkspezifische Sicherheitsmaßnahmen sind dokumentiert.
Om
V
Si
B.4.6.1 B.4.6.2
L
Zm
Wi
Ko
Wie werden Sicherheitsmaßnahmen für das Netzwerk dokumentiert? Wo befindet sich die Dokumentation?
Um die Sicherheit des Netzwerks zu gewährleisten, sollten die netzwerkspezifischen Sicherheitsmaßnahmen Teil eines Sicherheitskonzepts sein. Werden Sicherheitsmaßnahmen nicht dokumentiert, besteht die Gefahr, dass Risiken nicht behandelt oder Maßnahmen doppelt umgesetzt werden (das Rad wird immer wieder neu erfunden). Dies kann zu finanziellen Schäden führen. Das erstrebte Sicherheitsniveau wird nie erreicht.
#
Í
Ein Sicherheitskonzept für die Netzwerksicherheit erstellen und in regelmäßigen Abständen aktualisieren. Die Dokumentation nur befugten Personen zugänglich machen. Die Beschränkung des Zugriffs und eine kontinuierliche Aktualisierung lassen sich am besten mit einem online-gestütztes Dokumentenmanagement realisieren. Dies erleichtert auch eine aktuelle Revision der Dokumente. Vergleiche: BSI GSK B 2.3 ISO 27001 A.9.1.3
197
B Netzwerkebene
B.4
Betriebsphase
B.4.7
Notfallmaßnahmen für das Netzwerk sind definiert.
Om
Si
Zm
Wi
Ko
V
B.4.7.1 B.4.7.2 B.4.7.3
Welche Notfallmaßnahmen sind definiert worden? Wo sind diese dokumentiert? Wer sind die im Notfall Verantwortlichen?
L
Notfallmaßnahmen für das Netzwerk sind z.B. Umschalten auf die Ersatzleitung oder Austausch von Komponenten. Der Faktor Zeit spielt hier eine große Rolle. Je mehr Zeit zwischen Ausfall des Netzes und Wiederanlauf vergeht, desto höher sind die Ausfallkosten. Sind Notfallmaßnahmen nicht definiert, kann dies bei Eintritt eines Notfalls dazu führen, dass geeignete Maßnahmen nicht oder nur verzögert ergriffen werden. Das kann erhebliche Schäden nach sich ziehen.
#
Í
198
Notfallmaßnahmen für das Netzwerk ins Notfallhandbuch einpflegen. Die betroffenen Mitarbeiter schulen. Das Notfallhandbuch als zentrales Dokument sollte alle Notfallmaßnahmen enthalten. Hier ist besonders auf das Zusammenspiel mit externen Netzbetreibern und auf die Auflistung der Geräte zu achten. Vergleiche: BSI GSK M 6.1 ff
B.5 Migrationsphase
B.4
Betriebsphase
B.4.8
Notfallübungen werden durchgeführt.
Om
Si
Zm
Wi
Ko
V
B.4.8.1 B.4.8.2 B.4.8.3 B.4.8.4
Wann sind die letzten Notfallübungen durchgeführt worden? Wo sind diese dokumentiert? Wer sind die im Notfall Verantwortlichen? Wie wurde die Nachbereitung durchgeführt?
L
Notfallübungen für das Netzwerk sind z.B. Übungen zum Verhalten bei Verlust bestimmter Netzkomponenten. Werden Notfallübungen nicht durchgeführt, fehlt den Mitarbeitern die Übung und die Sicherheit. Bei Eintritt eines Notfalls kann das dazu führen, dass geeignete Maßnahmen nicht oder falsch ergriffen werden. Daraus können erhebliche Schäden entstehen.
#
Í
B.5
Notfallübungen regelmäßig durchführen. Die Ergebnisse einer Notfallübung dokumentieren. Notfallübungen sollten Sie nicht im laufenden Betrieb oder am Produktivsystem durchführen. Eine Trockenübung kann hier hilfreich sein. Diese kann ein einfaches Abfragen der Mitarbeiter sein mit dem Fokus auf der Eskalationsstrategie. Wenn möglich, sollten Sie die Notfalltests in einer Testumgebung durchführen. Vergleiche: BSI GSK M 6.1 ff
Migrationsphase Da eine Netzwerkmigration in der Regel auf Basis der betriebenen Netzwerkssysteme erfolgt, so sind die Anforderungen der Systemebene als adäquat anzusehen.
199
B Netzwerkebene
B.6
Roll-Off B.6.1
Inhalte auf aktiven Netzwerkkomponenten sind ordentlich gelöscht worden.
Om
V
Si
B.6.1.1 B.6.1.2
L
Zm
Wi
Ko
Welche Regelungen zum Löschen von Inhalten auf aktiven Netzwerkkomponenten existieren? Wer ist für die Löschung verantwortlich?
Aktive Netzkomponenten wie Switches, Router etc. enthalten Konfigurationen, die Rückschlüsse auf das Netzwerk zulassen. Ebenso können wichtige Protokolle oder Einstellungen auf einer Firewall enthalten sein. Nicht gelöschte Inhalte auf Netzwerkkomponenten können potenziellen Angreifern die internen Strukturen eines Netzwerkes verdeutlichen und so einen Angriff begünstigen. Dies kann erhebliche Schäden verursachen.
#
200
Aktive Komponenten der Aussonderung vollständig löschen. Die erfolgreiche Löschung dokumentieren.
Í
Bei vielen Komponenten kann eine Löschung der Daten nicht erfolgen. Hier sollte unter Abwägung der Kosten eine physikalische Zerstörung überlegt werden.
Vergleiche: BSI GSK B 2.3 ISO 27001 A.9.1.3
B.6 Roll-Off
B.6
Roll-Off
B.6.2
Protokolle werden nach gesetzlichen Vorgaben vernichtet.
Om
V
B.6.2.1 B.6.2.2
L
Si
Zm
Wi
Ko
Welche gesetzliche Grundlage bildete die Basis für die Vernichtung? Wie werden Protokolle entsorgt?
Besonders Transaktionsprotokolle müssen nach der maximalen Aufbewahrungsfrist vernichtet werden. Werden bestimmte Protokolle nicht vernichtet, so kann dies rechtliche Konsequenzen für die Verantwortlichen haben.
#
Protokolle nach gesetzlichen Vorgaben vernichten.
Í
Die Vernichtung der Protokolle sollte nach dem Vier-Augen-Prinzip erfolgen. So ist sichergestellt, dass eine Vernichtung auch nachgewiesen werden kann. Sollte dies ein Dienstleister übernehmen sind die Nachweise bei diesem einzufordern.
201
C C Systemebene In der Systemebene finden sich die grundlegenden Softwarekomponenten der IT-Systeme wie Betriebssystem-Software Hardwarebezogene Software wie z.B. Gerätetreiber Systemnahe Software wie z.B. Daemons, Agenten etc. Middleware
203
C Systemebene
C.1
Planungsphase C.1.1
Der Schutzbedarf des Systems ist ermittelt.
Om
V
Si
Wi
Ko
C.1.1.1
Wo ist der Schutzbedarf des Systems dokumentiert?
C.1.1.2
Welche potenziellen Schadensarten1 wurden bei der Ermittlung des Schutzbedarfs betrachtet? Für welche Sicherheitskriterien (Verfügbarkeit, Vertraulichkeit usw.) ist der Schutzbedarf angegeben?
C.1.1.3
L
Zm
Die Ermittlung des Schutzbedarfs ist die Voraussetzung, um die Systemsicherheit angemessen gestalten zu können. Die Systemsicherheit ist nicht ausreichend (Schutzbedarf ist höher als angenommen). Die Systemsicherheit ist unwirtschaftlich (Schutzbedarf ist geringer als angenommen).
#
1
204
Erstellen einer Schutzbedarfsklassifizierung mit sinnvollen Schutzklassen. Ermitteln von Schutzbedarfsparametern für die einzelnen Klassen, z.B. maximal tolerierbare Ausfallzeit oder benötigte Stärke von Verschlüsselungen. Vergleiche: BSI 2.316
z.B. Schaden an Leib und Leben, finanzielle Schäden, Imageschäden usw.
C.1 Planungsphase
C.1
Planungsphase
C.1.2
Die sich aus dem Schutzbedarf ableitenden Sicherheitsanforderungen und -maßnahmen sind definiert.
Om
V
Si
C.1.2.1 C.1.2.2 C.1.2.3
L
Zm
Wi
Ko
Wo ist dokumentiert, welche Sicherheitsanforderungen sich aus der Schutzbedarfsklassifizierung ergeben? Wie wird festgelegt, auf welche Weise die Sicherheitsanforderungen erfüllt werden können/sollen? Wann gelten die Anforderungen als erfüllt und wie soll das durch wen gemessen bzw. festgestellt werden?
Die Gewährleistung der Systemsicherheit sollte bereits in der Planungsphase beginnen, damit in späteren Phasen nicht aufwendige Korrekturen notwendig werden. Unklarheit über die Sicherheitserfordernisse und als Folge davon unzureichende Sicherheit. Subjektive Umsetzung von Sicherheitsmaßnahmen, fehlende Einheitlichkeit und erschwertes Sicherheitsmanagement.
#
Erstellen einer generischen Security Policy für die IT-Systemebene mit den Sicherheitsanforderungen. Einbindung der Sicherheitsplanung in die Systemplanung.
205
C Systemebene
C.1
Planungsphase
C.1.3
Leistungs- und Kapazitätsanforderungen an das System sind definiert.
Om
V
Si
C.1.3.1 C.1.3.2 C.1.3.3
L
Zm
Wi
Ko
Wie werden die Leistungsanforderungen für das System ermittelt? Auf welchen Annahmen basiert die Kapazitätsplanung für das System? Wie soll die Kapazität im Bedarfsfall angepasst werden?
Das geplante System muss über genügend Systemressourcen verfügen und in der Lage sein, die Last des laufenden Betriebs zu tragen. Leistungsengpässe bis hin zur völligen Systemblockierung.
#
206
Ermitteln von Mengengerüsten für den Systembetrieb. Ermitteln von Leistungsparametern (Komplexität, Übermittlungszeiten, Antwortzeiten usw.) Vergleiche: BSI 2.317
C.1 Planungsphase
C.1
Planungsphase
C.1.4
Die Dimensionierung des Systems entspricht der zu erbringenden Leistung.
Om
Si
Zm
Wi
Ko
V
C.1.4.1 C.1.4.2
Wo ist die geplante Systemdimensionierung dokumentiert? Wie kann in der Systemdimensionierung nachvollzogen werden, welche Leistungsanforderungen zu welcher Dimensionierung führte?
L
Eine der Aufgaben in der Systemplanung ist es, die aktuell angemessene Auslegung des Systems zu planen. Bei der Geschwindigkeit der Innovationszyklen in der IT beträgt der Planungshorizont dabei maximal 3 Jahre. Leistungsengpässe (s. E.1.3) bei zu geringer Dimensionierung. Kostenineffizienz bei zu großzügiger Dimensionierung.
#
Í
Ausrichten der Systemkomponenten (CPU, Speicher, Netzwerke) an den ermittelten Mengengerüsten und Performancevorgaben. Dokumentation der Kausalität für die geplante Systemdimensionierung. Es sollte darauf geachtet werden, dass das System skalierbar, d.h. anpassbar und erweiterbar ist, um zukünftige, höhere Leistungsanforderungen ohne kompletten Systemwechsel abdecken zu können. Siehe auch (in GoIT): Abschnitt C.1.3
207
C Systemebene
C.1
Planungsphase
C.1.5
Die Systeme folgen definierten Unternehmensstandards.
Om
V
Si
C.1.5.1 C.1.5.2
L
Zm
Wi
Ko
Welche Unternehmensstandards in Bezug auf die Systemebene sind im Unternehmen definiert? Wie wird sichergestellt, dass die einzusetzenden Systeme den Unternehmensstandards entsprechen?
Unternehmensstandards auf der Systemebene sind z.B. Standardkonfigurationen der Betriebssysteme oder festgelegte Servervarianten für die verschiedenen Einsatzszenarien. Wildwuchs der Ausprägungen von IT-Systemen und dadurch erschwertes oder verhindertes IT-Management. Unzureichende IT-Sicherheit durch fehlende Einheitlichkeit, erschwertes Sicherheitsmanagement.
#
C.2
Definieren von Systemstandards. Definieren von Standardkonfigurationen und Produktvorgaben („IT-Warenkorb“).
Entwicklungsphase In der Regel findet auf der Systemebene keine Entwicklung im Sinne von eigenentwickelten Betriebssystemen statt. Aus diesem Grund wurden für die Entwicklungsphase keine Anforderungen aufgenommen.
208
C.3 Implementierungsphase
C.3
Implementierungsphase C.3.1
Bei erhöhtem Schutzbedarf wird das System gehärtet.
Om
V
L
Si
C.3.1.1 C.3.1.2 C.3.1.3
Zm
Wi
Ko
Welche Kriterien bestimmen, ob ein System gehärtet wird? Auf welche Weise werden Systeme gehärtet? Wie wird die Härtung eines Systems auf Dauer gewährleistet?
I
B
E
M
P
R
Die Systemhärtung erhöht die Systemsicherheit, indem systematisch alle bekannten Schwachstellen eliminiert werden. Angriffsmöglichkeiten durch Schlupflöcher, Sicherheitslücken und unsichere Systemkomponenten.
#
Deaktivierung aller nicht benötigten und sicherheitsgefährdenden Dienste und Prozesse. Abschalten nicht benötigter Ports. Änderung aller Standardpasswörter. Vergleiche: BSI 4.238, 4.239
209
C Systemebene
C.3
Implementierungsphase
C.3.2
Die Erfüllung der Leistungs- und Kapazitätsanforderungen wird nachgewiesen.
Om
V
Si
C.3.2.1 C.3.2.2
L
Zm
Wi
Ko
Wie wird geprüft, ob das geplante System den Leistungsanforderungen standhalten wird? Welche Betriebssituationen werden dabei berücksichtigt?
Aufbauend auf den definierten Leistungsanforderungen muss während der Implementierung geprüft werden, ob das System in der Lage ist, die Anforderungen zu erfüllen. Leistungsengpässe bis hin zur völligen Systemblockierung.
#
210
Durchführen von Lasttests, um die Leistungsfähigkeit des Systems zu überprüfen. Testen des Performanceverhaltens in verschiedenen Betriebsszenarien. Siehe auch (in GoIT): Abschnitt C.1.3
I
B
E
M
P
R
C.3 Implementierungsphase
C.3
Implementierungsphase
C.3.3
Die Systemfunktionen und -komponenten sind ausführlich getestet.
Om
V
Si
C.3.3.1 C.3.3.2 C.3.3.3
L
Zm
Wi
Ko
Welche Tests wurden durchgeführt, um die korrekte Arbeitsweise der Systemfunktionen nachzuweisen? Welche Tests wurden durchgeführt, um die störungsfreie Koexistenz der Systemkomponenten nachzuweisen? Welche Testfälle wurden erstellt und nach welchen Kriterien wurden sie ausgewählt?
I
B
E
M
P
R
Es muss sichergestellt werden, dass die Anwendungen, Dienste, Protokolle usw., die das IT-System trägt, ihre Funktion korrekt erbringen und sich nicht gegenseitig bzw. die Betriebssystemebene beeinträchtigen. Beeinträchtigung oder Verlust von Systemfunktionen bis hin zum Ausfall des IT-Systems. Sicherheitsprobleme durch inkompatible Systemkomponenten.
#
Durchführen von Integrationstests, mit denen die Verträglichkeit der Systemfunktionen geprüft wird. Durchführen von Funktionstests, die die Abläufe und Ergebnisse der Systemfunktionen überprüfen. Vergleiche: BSI 4.65
211
C Systemebene
C.4
Betriebsphase C.4.1
Alle Lizenzvereinbarungen werden eingehalten.
Om
V
Si
C.4.1.1 C.4.1.2
C.4.1.3
L
Zm
Wi
Ko
Wie wird der Lizenzbedarf ermittelt und aktuell gehalten? Wie wird erkannt und verhindert, dass Systeme oder Systemkomponenten ohne die benötigten Lizenzen betrieben werden? Wo ist dokumentiert, welche Lizenzen aktuell vorhanden sind?
Lizenzvereinbarungen sind vertragsrechtliche Nutzungsbedingungen für das ITSystem, zu deren Einhaltung sich das Unternehmen verpflichtet. Strafrechtliche Konsequenzen und Schadenersatzansprüche.
#
212
Erwerb aller benötigten Systemlizenzen. Überwachung des Lizenzbedarfs und der installierten Systemsoftware (Inventarisierung, Lizenzmanagement). Vergleiche: Urheberrechtschutzgesetz Vertragsrecht
I
B
E
M
P
R
C.4 Betriebsphase
C.4
Betriebsphase
C.4.2
Das System ist vor zu langen Ausfällen geschützt.
Om
V
Si
C.4.2.1 C.4.2.2
C.4.2.3
L
Zm
Wi
Ko
Woraus ist die maximal tolerierbare Ausfallzeit1 des Systems ersichtlich und wie wurde sie ermittelt? Wo sind die Sicherheitsmaßnahmen beschrieben, die die Ausfallzeit im tolerierbaren Bereich halten sollen? Wie wurde die Effektivität, Angemessenheit und Wirtschaftlichkeit dieser Maßnahmen betrachtet? In welchen Intervallen wird die Wirksamkeit der Sicherheitsmaßnahmen getestet? Wann fand der letzte Test statt und wo sind die Ergebnisse dokumentiert?
I
B
E
M
P
R
Die Verfügbarkeit der Systeme ist ein wichtiges Sicherheitskriterium für die ITSysteme. Schäden (monetär, Imageverlust), wenn durch den Ausfall der Systemfunktion Geschäftsprozesse gestört bzw. blockiert werden.
#
1
Durchführen einer Schutzbedarfsanalyse. Schaffen von Redundanz, z.B. durch Hochverfügbarkeits- bzw. Clustersysteme. Vergleiche: BSI 1.3
Siehe auch (in GoIT): Abschnitt C.4.3
Die maximal tolerierbare Ausfallzeit ist der Zeitraum zwischen dem Auftreten des Ausfalls und der Wiederaufnahme des Regelbetriebs mit der vollen Systemleistung und -kapazität, so dass der Schaden infolge des Ausfalls in einem tragbaren Rahmen bleibt.
213
C Systemebene
C.4
Betriebsphase
C.4.3
Die Wiederherstellung des Systems ist in der erforderlichen Zeit möglich.
Om
V
Si
C.4.3.1 C.4.3.2 C.4.3.3
L
Zm
Wi
Ko
Wo ist das Zeitfenster für die Wiederherstellung1 dokumentiert und ist es realistisch? Wo sind die Voraussetzungen für die Wiederherstellung und der Recovery-Prozess beschrieben? Wird die Wiederherstellung getestet bzw. geübt? Wann fand der letzte Test/die letzte Übung statt und wo sind die Ergebnisse dokumentiert?
I
M
P
R
Es muss gewährleistet werden, dass ein ausgefallenes System technisch und organisatorisch (z.B. Ersatzbeschaffung) in einer vertretbaren Zeit wiederhergestellt werden kann. Schäden (monetär, Imageverlust), wenn durch den Ausfall der Systemfunktion Geschäftsprozesse gestört bzw. blockiert werden.
#
1
214
Vorhalten von Systemsicherungen (z.B. System-Images). Bevorraten von Hardwarekomponenten bzw. Sicherstellen der Ersatzbeschaffung bei Hardwareausfall. Vergleiche: BSI 100-4 BS25999
B
E
Siehe auch (in GoIT): Abschnitt C.4.2
Bei einem Ausfall vergeht zunächst eine gewisse Zeit, bis der Ausfall bemerkt wird, und eine weitere Zeit (Reaktionszeit), bis auf den Ausfall reagiert wird. Eine weitere Zeit vergeht, bis die Entscheidung zur Wiederherstellung getroffen und die Voraussetzungen dafür geschaffen werden. Erst dann beginnt das Zeitfenster für die Wiederherstellung, die mit der Wiederaufnahme des Regelbetriebs mit der vollen Systemleistung und -kapazität endet.
C.4 Betriebsphase
C.4
Betriebsphase
C.4.4
Das System wird durch Updates auf dem neuesten Stand gehalten.
Om
V
Si
C.4.4.1 C.4.4.2 C.4.4.3 C.4.4.4
L
Zm
Wi
Ko
Welche Wartungs- bzw. Update-Verträge existieren für das System? In welchen Zeitintervallen werden Updates eingespielt bzw. stehen Updates zur Verfügung? Nach welchem Prozess werden Updates in das System eingespielt? Wann wurden die letzten drei Updates eingespielt?
I
B
E
M
P
R
Mit der Aktualisierung werden in der Betriebsphase gefundene Fehler behoben (Bugfixing), neu hinzugekommene Schwachstellen eliminiert und verbesserte bzw. neue Funktionalitäten implementiert. Schäden für das System infolge neuer Schwachstellen und Bedrohungen.
#
Í
Sicherstellen, dass regelmäßige Updates für das System verfügbar sind. Testen der Updates auf Funktion und Verträglichkeit mit der aktuellen Systemkonfiguration. Je nach Inhalt des Updates können alle Prüfungsaspekte betroffen sein. Vergleiche: BSI M2.273
215
C Systemebene
C.4
Betriebsphase
C.4.5
Das System ist vor unberechtigten Zugriffen geschützt.
Om
V
Si
C.4.5.1 C.4.5.2 C.4.5.3
L
Zm
Wi
Ko
Über welche Zugriffsschutzmechanismen verfügt das System? Sind die Zugriffsschutzmechanismen so eingerichtet, dass sie korrekt arbeiten? Wo ist das Berechtigungskonzept des Systems dokumentiert (Systematik und eingerichtete Berechtigungen)?
I
M
P
R
Zugriffsschutz und Zugriffskontrolle gehören zu den wichtigsten Sicherheitsaspekten. Sie besitzen eine zentrale Bedeutung bei der Gewährleistung der Vertraulichkeit des Systems. Verstoß gegen geltende Gesetze (BDSG, GoBS) Materielle und immaterielle Schäden durch unbefugte Kenntnisnahme von vertraulichen Informationen.
#
Definieren der Vertraulichkeitsanforderungen für das System. Prüfen des Einsatzes der standardmäßig verfügbaren Zugriffsschutzmechanismen (z.B. Systemauthentifizierung per Passwort) und ggf. Implementierung stärkerer Mechanismen (z.B. biometrische Authentifizierung).
Í
Es ist zu prüfen, ob die vorhandenen Zugriffsschutzmechanismen einen ausreichenden Schutz bieten (z.B. nicht umgangen oder „gehackt“ werden können) und ob das Berechtigungskonzept im Sinne der Unternehmensanforderungen2 ausreichend ist.
2
216
B
E
Vergleiche: BDSG Anlage zu §9 Satz 1 GoBS 3.1, 4.4, 5.5.1, 6.2.4 BSI M2.8
Eine solche Anforderung könnte das „Need to know“-Prinzip sein, das fordert, dass eine Person nur über die Rechte verfügen darf, die sie für ihre Tätigkeiten benötigt.
C.4 Betriebsphase
C.4
Betriebsphase
C.4.6
Die Erfüllung der Leistungs- und Sicherheitsanforderungen wird regelmäßig analysiert und ggf. angepasst.
Om
V
Si
C.4.6.1 C.4.6.2
C.4.6.3
L
Zm
Wi
Ko
Wie wird sichergestellt, dass bei Änderungen des Systems die Systemanforderungen weiterhin erfüllt sind? Wie wird dafür gesorgt, dass bei Änderungen der Systemanforderungen das System den neuen Anforderungen gerecht wird? Wie wird die Erfüllung der Systemanforderungen im laufenden Betrieb kontrolliert bzw. überwacht (Monitoring)?
I
B
E
M
P
R
Diese Anforderung ist Aufgabe der Systemadministration und des IT-Managements, die die IT und deren Einsatz kontinuierlich überwachen. Schäden für das Unternehmen, wenn sich das IT-System bzw. dessen Einsatz ändert und dadurch die erforderliche Sicherheit oder Leistung nicht mehr gegeben ist.
#
Definieren und Verankern von Audits oder anderen Prüfungsaktivitäten, mit denen regelmäßig der Systemzustand gegen die Anforderungen geprüft wird. Dokumentieren von Änderungen und deren Prüfung auf Handlungsbedarf hinsichtlich der Systemanforderungen.
217
C Systemebene
C.4
Betriebsphase
C.4.7
Das System ist angemessen dokumentiert.
Om
V
Si
C.4.7.1 C.4.7.2 C.4.7.3 C.4.7.4
L
Zm
Wi
Ko
Wo ist die Systemdokumentation zu finden und in welcher Form/ in welchem Format liegt sie vor? Welche Struktur besitzt die Dokumentation? Wie ist der Pflegeprozess definiert und wer pflegt die Dokumentation? Sind der aktuelle Stand der Dokumentation und eine Änderungshistorie vorhanden?
Eine ausreichende und qualitativ gute Systemdokumentation ist wichtig für die das System betreffenden IT-Prozesse. Verstoß gegen Dokumentationspflichten (z.B. GoBS). Erschwertes System- und Sicherheitsmanagement sowie Gefahr von Sicherheitslücken infolge fehlender Systemtransparenz.
#
Í
218
Bestimmen des Inhalts der Dokumentation (was soll in die Dokumentation aufgenommen werden?). Definieren eines Dokumentationsstandards (Format, Ablageort, usw.) und des Pflegeprozesses. Es ist zu prüfen, ob die Systemdokumentation korrekt und aktuell, vollständig und verständlich ist. Vergleiche: GoBS 6. (Verfahrensdokumentation) BDSG §18 Satz 2 (DVA-Verzeichnis) BSI M2.315
I
B
E
M
P
R
C.5 Migrationsphase
C.5
Migrationsphase C.5.1
Die Systemfunktion bleibt zu jedem Zeitpunkt der Migration erhalten.
Om
V
Si
C.5.1.1 C.5.1.2
C.5.1.3
L
Zm
Wi
Ko
Wie wurde die neue IT-Lösung hinsichtlich der Stabilität der Systemfunktion getestet? Wie realitätsnah waren die Tests? Welche Redundanz wurde für den Fall vorgesehen, dass die Systemfunktion der neuen IT-Lösung nicht ausreichend ist oder ganz versagt? Wie wurde das Business Continuity Management und das IT Security Management in die Migration einbezogen?
I
B
E
M
P
R
Die Systemfunktion darf mit der Durchführung einer Migration nicht beeinträchtigt werden. Ausfall der Systemfunktion.
#
Í
Vorübergehender Parallelbetrieb von alter und neuer IT-Lösung. Einrichten eines nicht migrierten (Hot-)Standby-Systems. Sichern des aktuellen Systemzeitpunkts vor der Migration und Schaffen einer schnellen Möglichkeit für das System-Recovery. Die Erhaltung der Systemfunktion wird in einigen Fällen gesetzlich gefordert (z.B. bei der Forderung nach zeitgerechter bzw. lückenloser Aufzeichnung). Vergleiche: GoBS 1.2, 2.3.1, 3.1, 4.2
219
C Systemebene
C.5
Migrationsphase
C.5.2
Für einen möglichen Fehlschlag von Änderungen/Migrationen ist ein Rollback vorhanden.
Om
V
Si
C.5.2.1 C.5.2.2 C.5.2.3 C.5.2.4
L
Zm
Wi
Ko
Welche Migrationsrisiken wurden in der Migrationsplanung auf welche Weise berücksichtigt? Welche Rollback- bzw. Fallback-Möglichkeiten wurden bei der Migration eingeplant? Wo ist der Rollback-Prozess dokumentiert? Wie wurde der Rollback-Fall getestet bzw. geübt?
Im Fall eines Fehlschlags der Migration sollte das System in den Zustand direkt vor der Migration zurückversetzt werden können (Rollback). Ausfall des Systems, je nach Schwere des Problems u.U. für eine längere Zeit.
#
220
Einsatz eines Migrationstools, das ein System-Rollback durchführen kann. Sichern des Systemzustands und Rückspielen der Sicherung im Ernstfall.
I
B
E
M
P
R
C.5 Migrationsphase
C.5
Migrationsphase
C.5.3
Systemänderungen werden auf Seiteneffekte hin geprüft.
Om
V
Si
C.5.3.1
C.5.3.2
L
Zm
Wi
Ko
Welche Integrationstests werden für Systemänderungen durchgeführt (Verträglichkeit mit den Systemkomponenten, Applikationen, Diensten)? Auf welche Weise ist ersichtlich, auf welche Stellen im System sich die Änderungen auswirken?
I
B
E
M
P
R
In einigen Fällen kommt es durch Systemänderungen (z.B. Updates, Patches) zu unerwünschten Nebenwirkungen, die abgefangen werden müssen. Störung bis hin zur Blockierung der Systemfunktion. Erzeugen von Sicherheitslücken oder -problemen.
#
Ausführliche Untersuchung, welche Wirkungen die Änderungen auf das System besitzen (an welchen Stellen wird geändert und welche anderen Komponenten könnten davon betroffen sein?). Durchführen von Änderungssimulationen oder Tests in einer Testumgebung. Vergleiche: BSI M4.240
221
C Systemebene
C.5
Migrationsphase
C.5.4
Es gibt eine Übersicht, welche Systemeigenschaften des Altsystems denen des Neusystems entsprechen.
Om
V
Si
C.5.4.1 C.5.4.2
C.5.4.3
L
Zm
Wi
Ko
Wo ist dokumentiert, welche Systemeigenschaften im neuen System (wenn auch ggf. in anderer Form) abgebildet sein müssen? Wo ist dokumentiert, welche Eigenschaften des neuen Systems den unter C.5.4.1 aufgelisteten Systemeigenschaften des alten Systems entsprechen? Welche Maßnahmen wurden getroffen, damit Benutzer und Administratoren wissen, wie sie gewohnte Systemaktionen im neuen System durchführen können?
Durch eine Migration können sich trotz gleicher Systemfunktion die Systemeigenschaften, die verwendeten Systemkomponenten und die Systemadministration ändern. Fehlen von wichtigen Systemeigenschaften im neuen System (z.B. kein oder ungenügendes Logging). Erschwerte Systemadministration (zumindest kurzfristig nach der Migration).
#
222
Auflisten der relevanten Systemeigenschaften und deren Äquivalent im neuen System.
I
B
E
M
P
R
C.5 Migrationsphase
C.5
Migrationsphase
C.5.5
Änderungen und Migrationen unterliegen einem definierten und kontrollierten Change-Management-Prozess.
Om
V
Si
C.5.5.1 C.5.5.2 C.5.5.3
L
Zm
Wi
Ko
Welches Vorgehen ist für die Durchführung von Systemänderungen definiert? Wo ist dieses Vorgehen dokumentiert? Wie wird sichergestellt, dass alle Änderungen dieses Vorgehen einhalten? Wo werden die durchgeführten Änderungen und der Verlauf des Änderungsprozesses (vom Änderungsantrag bis zur durchgeführten Änderung) dokumentiert?
I
B
E
M
P
R
Ein Change-Management-Prozess sorgt für die einheitliche und sichere Bearbeitung von Systemänderungen und für die Dokumentation der durchgeführten Änderungen. Ausfall der Systemfunktion infolge unkontrollierter Änderungen. Kompromittierung der Systemsicherheit. Fehlende Systemtransparenz.
#
Definieren eines Change-Management-Prozesses, der dem aktuellen Stand der Technik entspricht. Verankern des Change-Management-Prozesses in der Unternehmens-IT.
223
C Systemebene
C.6
Roll-Off C.6.1
Alle Systemfunktionen werden nicht mehr benötigt.
Om
V
Si
C.6.1.1 C.6.1.2
C.6.1.3
L
Zm
Wi
Ko
Welche Systemfunktionen werden durch das abzuschaltende System erbracht? Wo ist nachzuvollziehen, dass die vom System erbrachten Funktionen nicht mehr benötigt werden (Umzug der Funktionen auf andere Systeme, obsolet gewordene Funktionen usw.)? Wer entscheidet auf welcher Basis über die Notwendigkeit der Funktionen?
IT-Systeme erbringen eine Vielzahl von Systemfunktionen, von denen einige sehr versteckt und unauffällig arbeiten. Mit der Außerdienststellung des Systems könnten deshalb auch wichtige Systemfunktionen für andere Systeme bzw. für die gesamte IT-Architektur abgeschaltet werden. Ausfall von benötigten Systemfunktionen, wenn das System außer Dienst gestellt wird.
#
Í
224
Auflisten aller Systemfunktionen und dedizierte Entscheidung für jede Funktion, dass sie nicht mehr benötigt wird. Bei der Entscheidung über die Notwendigkeit wird nicht die generelle Notwendigkeit der Funktion beurteilt, sondern ob die Funktion von dem System erbracht werden muss, das außer Dienst gestellt werden soll.
I
B
E
M
P
R
C.6 Roll-Off
C.6
Roll-Off
C.6.2
Alle Systemlizenzen erlöschen3.
Om
V
Si
C.6.2.1 C.6.2.2 C.6.2.3
L
Zm
Wi
Ko
Welche Lizenzen sind mit dem System verbunden? Welche Lizenzverträge sind aufgrund des Roll-Off des Systems zu beenden? Wer ist für das Beenden der Lizenzen verantwortlich und wie wird nachgewiesen bzw. wie ist nachvollziehbar, dass alle Lizenzen beendet wurden?
I
B
E
M
P
R
Mit der Außerdienststellung des Systems werden die mit dem System verbundenen Lizenzen nicht mehr benötigt. Überflüssige Kosten für unnötige Lizenzen. Fehlender Überblick über die Lizenzlage.
#
Auflisten der Lizenzen, die durch den Roll-Off des Systems berührt werden. Beenden von laufzeitgebundenen Lizenzverträgen.
Í
System- bzw. maschinenabhängige Lizenzen werden mit dem Roll-Off des Systems ungültig. Bei systemunabhängigen Lizenzen wird hier davon ausgegangen, dass diese nicht auf andere Systeme übertragen werden.
3
Beachten Sie hierzu die Hinweise zu dieser Anforderung (die Zeile mit dem Pinnnadel-Symbol).
225
C Systemebene
C.6
Roll-Off
C.6.3
Vor dem Roll-Off wird sichergestellt, dass ein zu entsorgendes, physisches System keine vertraulichen Daten mehr enthält.
Om
V
Si
C.6.3.1 C.6.3.2 C.6.3.3
L
Zm
Wi
Ko
Wie wird mit zu entsorgenden Systemen umgegangen, die lokale Datenträger enthalten? Auf welche Weise werden Datenträger vor der Entsorgung gelöscht? Wo ist der physische Roll-Off-Prozess dokumentiert?
Es kommt nicht selten vor, dass lokale Datenträger von ausrangierten IT-Systemen noch Daten oder Spuren von Daten enthalten (Pagefile, temporär im System angelegte Dateien usw.). Diese Daten können vertraulich sein (z.B. personenbezogene Daten). Verlust der Vertraulichkeit, wenn sensible Daten im System verbleiben und das System ausgemustert wird.
#
226
Sicheres Löschen der im System noch vorhandenen Daten durch vollständiges, physisches Entfernen aller Daten (z.B. auf lokalen Platten). Vergleiche: BSI M2.320, BDSG §9 Anhang Satz 1
I
B
E
M
P
R
C.6 Roll-Off
C.6
Roll-Off
C.6.4
Das physische IT-System wird de-inventarisiert und die Entsorgung protokolliert.
Om
V
Si
C.6.4.1 C.6.4.2
C.6.4.3
L
Zm
Wi
Ko
Wie wird ein System de-inventarisiert und wie wird sichergestellt, dass dies bei allen zu entsorgenden IT-Systemen geschieht? Wo ist dokumentiert, dass die Entsorgung des Systems tatsächlich stattfand und gemäß des Roll-Off-Prozesses erfolgt ist? Wer bestätigt nach dem Prozess die Entsorgung? Wie werden die Stellen, in deren Dokumentationen das System aufgeführt ist, über die Außerdienststellung informiert?
I
B
E
M
P
R
IT-Systeme werden in der Regel in vielen Übersichten, Plänen, Verzeichnissen, usw. geführt. Im Zuge des Roll-Off ist ein zu entsorgendes System daher aus der Inventarisierung herauszunehmen. Falsche Architekturpläne mit „Geistersystemen“, die in der Realität nicht mehr existieren Schäden für das Unternehmen, wenn das System nicht entsorgt und unzulässig verwendet wird.
#
Sicherstellen, dass der Roll-Off-Prozess über eine De-Inventarisierung verfügt. Sicherstellen, dass der Roll-Off-Prozess Schritte enthält, die die Entsorgung des Systems den relevanten Stellen im Unternehmen bekannt machen. Vergleiche: BSI M2.320
227
D D Applikationsebene Zu der Applikationsebene gehören Anwendungen, die von Drittanbietern stammen wie: ERP-Systeme E-Mail Datenbanken
229
D Applikationsebene
D.1
Planungsphase D.1.1
Die Ziele und Aufgaben, welche die Anwendung erfüllen soll, sind definiert worden.
Om
Si
Zm
Wi
Ko
V
D.1.1.1 D.1.1.2
Wie wurden die Ziele und Aufgaben definiert? Welche Beschäftigten haben die Anforderungen definiert?
L
Um zielgerichtet eine Applikation zu beschaffen oder zu entwickeln, ist es notwendig, vorher die Ziele und Anforderungen zu definieren. Dies sollte durch die Verantwortlichen für den Geschäftsprozess und des IT-Bereichs zusammen geschehen. Werden die Ziele und Aufgaben nicht vorher definiert, so ist eine ressourcensparende und erfolgversprechende Beschaffung oder Entwicklung nicht gegeben. Sicherheitslücken und Fehlinvestitionen bedrohen die Unternehmenswerte.
#
Í
Definition der Ziele aller Applikationen während der Planungsphase. Involvieren aller Verantwortlichen (Prozess- und IT-Verantwortliche) bei der Planung. Die Definition der Ziele und Aufgaben sollte in einigen Workshops der Planungsphase durchgeführt werden. An diesen Workshops sollten teilnehmen: Abteilungsleiter der betroffenen Abteilungen IT-Betriebsverantwortliche Vertreter der Anwender (der Beschäftigten) Optional: Datenschutzbeauftragter (für Prozesse, die personenbezogene Daten verarbeiten) Rechtsabteilung (für Prozesse, die rechtliche Auswirkungen haben)
230
D.1 Planungsphase
D.1
Planungsphase
D.1.2
Die Anforderungen sind in einem Lastenheft/Anforderungskatalog konkretisiert worden.
Om
V
Si
D.1.2.1 D.1.2.2
L
Zm
Wi
Ko
In welchen Dokumenten wurden die Zieldefinitionen festgehalten? Wer war an der Erstellung beteiligt?
Ein Lastenheft/Anforderungskatalog beschreibt die Ziele der Applikation und deren Umsetzungsempfehlung. Werden Anforderungen nicht dokumentiert, können sie im Laufe des Entwicklungs- und Beschaffungsprozesses verloren gehen. Dies kann zu einer Zielverfehlung und somit zu einer Fehlinvestition führen.
#
Dokumentieren aller Anforderungen im Lastenheft/Anforderungskatalog.
Í
Beispiele für Lastenhefte und Anforderungskataloge gibt es im VDI 2519 Blatt 1: Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheft oder in der DIN 69905
Vergleiche: DIN 69905 VDI 2519 Blatt 1
231
D Applikationsebene
D.1
Planungsphase
D.1.3
Für die Entwicklung/Implementierung werden geeignete Ressourcen bereitgestellt.
Om
Si
Zm
Wi
Ko
V
D.1.3.1 D.1.3.2
Welche Ressourcen sind bereitgestellt worden? Wer ist für die Ressourcenplanung zuständig?
L
Geeignete Ressourcen im Sinne der GoIT sind finanzielle wie auch personelle Ressourcen. Bei nicht geeigneter Ressourcenplanung sind die Investitionen und das Projektziel gefährdet.
#
Í
232
Festlegen eines Projektbudgets nach den Ergebnissen des Lastenheftes. Einteilen der Projektleitung. Eine mögliche Vorgehensweise zur Planung und Steuerung von Ressourcen innerhalb des Projektmanagements ist in der PRINCE2-Methodik zu finden. Vergleiche: http://www.prince2-deutschland.de/
D.1 Planungsphase
D.1
Planungsphase
D.1.4
Die Daten, die verarbeitet werden sollen, sind klassifiziert und definiert worden.
Om
Si
Zm
Wi
Ko
V
D.1.4.1 D.1.4.2
Welche Arten von Daten werden verarbeitet? Welche Auswirkungen haben die Daten auf das Unternehmen?
L
Datenklassifikationen sind Einteilungen der Daten nach ihrer Wichtigkeit für das Unternehmen. Wie wichtig sind die Daten z.B. in Bezug auf Verfügbarkeit, Vertraulichkeit, Integrität etc.? Werden Daten nicht klassifiziert, so kann es zu einer Nichtbeachtung wichtiger Maßnahmen führen, die Daten und somit auch das Unternehmen gefährden können.
#
Í
Festlegen der Kategorien für die Einteilung der Daten. Definition der Dateneigenschaften. Einteilen der Daten in die Kategorien. Eine gute Vorgehensweise ist die durch das Bundesamt für Sicherheit in der Informationstechnik (BSI) herausgegebene Schutzbedarfsfeststellung. Diese verbindet Daten mit den Schadenskategorien, die ein Verlust der Verfügbarkeit, der Integrität und der Vertraulichkeit haben, wie z.B. negative Außenwirkung, finanzielle Schäden etc. Vergleiche: BSI Grundschutz Standard 100-2.
233
D Applikationsebene
D.1
Planungsphase
D.1.5
Eine geeignete Infrastruktur für den Betrieb wurde ausgewählt.
Om
Si
Zm
Wi
Ko
V
D.1.5.1 D.1.5.2
Wie wurde die Infrastrukturplanung vorgenommen? Welche Anforderungen wurden ermittelt?
L
Die Anforderungen, die Anwendungen an eine Umgebung stellen, sind mannigfaltig. Eine geeignete Infrastruktur zeichnet sich durch zukunftsorientierte, sorgfältig geplante und aufeinander abgestimmte Komponenten aus. Die (geschäftlichen) Ziele, die eine Anwendung erfüllen soll, müssen durch die Infrastruktur gesichert sein. Eine nicht geeignete Infrastruktur kann zu Ausfällen und Engpässen führen. Solche Ausfälle führen zu einer Inakzeptanz bei den Anwendern und zu erheblichen ungeplanten Mehrkosten bei einer späteren Anpassung an die Anforderungen der Anwendung.
#
Í
234
Sammeln der Ergebnisse der Anwendungsplanung. Anforderungen und Ziele mit Fokus auf den Betrieb der Anwendung konkretisieren. Konkretisierte Anforderungen mit geeigneten Lasttests prüfen. Erfahrungen mit ähnlichen Anwendungen erheben und in die Planung einbeziehen. Ein Unternehmen kann natürlich bereits über eine geeignete physische Infrastruktur verfügen. Um hier Einsparpotenzial zu nutzen, kann auf eine skalierbare und flexible Technologie gesetzt werden. In der letzten Zeit wurde hier die Virtualisierung als probates Mittel angesehen. Dabei werden logische Anwendung und physikalisches System getrennt. Dadurch kann die Hardware zur Leistungsanpassung getauscht werden, ohne die Anwendung anpassen zu müssen.
D.2 Entwicklungsphase
D.2
Entwicklungsphase D.2.1
Geeignete Vorgehensweisen zur Entwicklung sind mit den Anforderungen verglichen worden.
Om
V
Si
D.2.1.1 D.2.1.2
L
Zm
Wi
Ko
Welche Varianten zur Anwendungsentwicklung wurden verglichen? Welche Anforderungen sind an die Vorgehensweisen gestellt worden?
Geeignete Vorgehensweisen im Sinne der GoIT sind standardisiert, geplant und gemanagt. Hierbei handelt es sich um etablierte Vorgehensweisen wie z.B. V-Modell o.Ä. Ungeeignete Vorgehensweisen beeinflussen die Qualität der Software. Dokumentationen können nicht oder nur schlecht geprüft werden. Teile oder die gesamte Anwendung sind nicht kontrollierbar und transparent. Fehler werden nicht gefunden und beeinflussen die Ergebnisse zum Teil erheblich.
#
Í
Dokumentieren der Ziele der Anwendung und die Anforderungen des Auftraggebers. Prüfen der etablierten Standards und Vergleichen der Anforderungen. Je nach Anforderung des Kunden kann eine unterschiedliche Vorgehensweise zielführend sein. Bei visuell geprägten Kunden empfiehlt sich eine Vorgehensweise mit Prototypenvarianten. Bei Kunden, bei denen gesetzliche Anforderungen die Entwicklung beeinflussen, ist eine genaue Dokumentation von Vorteil. Egal welche Vorgehensweise Sie wählen, dokumentieren Sie ausführlich! Vergleiche: V-Model XT® auf www.cio.bund.de
235
D Applikationsebene
D.2
Entwicklungsphase
D.2.2
Die Entwicklung wird konform zur Vorgehensweise dokumentiert.
Om
Si
Zm
Wi
Ko
V
D.2.2.1 D.2.2.2
Welche Dokumentationsart wurde ausgewählt? Wer ist für die Dokumentation verantwortlich?
L
In allen geeigneten Vorgehensweisen sind Dokumentationsrichtlinien definiert. Die Inhalte und der Umfang der Entwicklungsdokumentation sind hier gemäß den Vorgaben einzuhalten. Wird nicht nach den Vorgaben der Vorgehensweise dokumentiert, ist eine Kontrolle der Anwendung nicht mehr oder nur unter hohem Ressourceneinsatz möglich. Fehler sind nicht nachvollziehbar, reproduzierbar und damit nur sehr schwer zu beseitigen.
#
Í
236
Ermitteln der Anforderungen an die Dokumentation. Zuweisen der Verantwortlichkeiten. Beschaffen von geeigneten Dokumentationswerkzeugen. Dokumentation regelmäßig auf ihre Anwendbarkeit prüfen. Um eine Dokumentation zu vereinfachen, kann auf Werkzeuge zurückgegriffen werden. Diese können in den Entwicklungsumgebungen vorhanden sein oder extra beschafft werden. Viele Entwicklungsumgebungen erlauben eine schnelle saubere Dokumentation im Sourcecode. Werkzeuge wie „Bugtracker“ erleichtern die Fehlerverfolgung und die Dokumentation während der Entwicklung. Vergleiche: www.bugzilla.org
D.3 Implementierungsphase
D.3
Implementierungsphase D.3.1
Quellcode ist gegen unbefugte Veränderung gesichert.
Om
V
Si
D.3.1.1 D.3.1.2
L
Zm
Wi
Ko
Welche Sicherungsmaßnahmen wurden gegen eine unbefugte Veränderung getroffen? Wo wird der Quellcode aufbewahrt?
Der Quellcode ist das Herzstück der Anwendung. Er stellt den Wert der Anwendung dar und die Prüfungsgrundlage für etwaige Prüfungen der Korrektheit einer Anwendung. Existiert keine Quellcodesicherung, kann eine korrekte Verarbeitung der Daten innerhalb der Anwendung nicht mehr gewährleistet werden. Es können unbemerkt Hintertüren oder Spionageprogramme eingebaut werden. Gesetzliche Anforderungen sind damit nicht mehr erfüllt. Informationen geraten mit allen negativen Auswirkungen für das Unternehmen in Hände von Unbefugten.
#
Quellcode durch ein restriktives Zugriffskonzept während der Entwicklungsphase sichern. Schützen des Quellcodes nach der Implementierung durch vertraulichkeitsund integritätssichernde Maßnahmen.
Í
Während der Entwicklung sollte ein Zugriffsschutz auf den Quellcode durch ein Zugriffskonzept geregelt werden. Hierzu können Vergabeschemata aus dem normalen Betrieb herangezogen werden. Nach der Implementierung sind die Rechte der Programmierer in den Betrieb zu migrieren. Es ist von Vorteil, die einzelnen Versionsstände ebenfalls zu sichern, um eine Historisierung zu erreichen.
237
D Applikationsebene
D.3
Implementierungsphase
D.3.2
Applikationstests werden nach den Vorgaben der Planung umgesetzt.
Om
Si
Zm
Wi
Ko
V
D.3.2.1 D.3.2.2 D.3.2.3
Welche Tests sind in der Planungsphase definiert worden? Welche Ergebnisse wurden erzielt? Welche Arten von Dokumentationen liegen vor?
L
Einerseits ist es natürlich sinnlos, Tests zu planen, wenn die Tests dann nicht durchgeführt werden. Andererseits lassen sich belastbare Ergebnisse nur durch vorher geplante Tests erzielen. Die Tests sollten in den Pflichten- und Lastenheften dokumentiert sein. Somit ist diese Anforderung eine Konkretisierung der Anforderung B.1.2. Werden geplante Tests nicht umgesetzt, sind keine belastbaren Aussagen für das weitere Vorgehen gegeben. Fehler werden erst spät oder gar nicht entdeckt. Anforderungen an den Betrieb können nicht gestellt werden. Die geeignete Umgebung geht möglicherweise zu groß oder zu klein in Betrieb.
#
Umsetzen aller geplanten Tests. Verantwortlichkeiten definieren. Geeignete Testdokumentation erstellen. Tests überprüfen und Ergebnisse als „Lessons learned“ für den Betrieb dokumentieren.
Í
Lassen Sie Tests als eigenes Projekt mit eigenen Zuständigkeiten und Projektleitung laufen. Dies erhöht die Aussagekraft und die Genauigkeit der Ergebnisse.
238
Siehe auch (in GoIT): Abschnitt B.1.2
D.4 Betriebsphase
D.4
Betriebsphase D.4.1
Anforderungen der Applikation an den Betrieb sind dokumentiert.
Om
V
Si
D.4.1.1 D.4.1.2
L
Zm
Wi
Ko
Welche Dokumente enthalten die Anforderungen an den Betrieb? Welche Anforderungen hat die Applikation an den Betrieb?
Eine Dokumentation der Betriebsanforderungen ist essenziell wichtig für den IT-Betrieb, da hier Ressourcen etc. eingeplant und effizient eingesetzt werden müssen. Wird der Betrieb der Anwendung einem Dritten überlassen, so sind gesetzliche Bestimmungen zu beachten. Nicht definierte Anforderungen können zur Nichterfüllung der geschäftlichen Ziele der Anwendung führen. Nicht definierte Sicherheitsanforderungen stellen eine erhebliche Gefahr dar. Hierbei sind alle Bereiche betroffen (Verfügbarkeit, Vertraulichkeit und Integrität).
#
Í
Kontrolle der Anforderung auf Relevanz für den Betrieb. Dokumentation der relevanten Anforderungen. Verfassen von Service Level Agreements. Die Anforderungen sollten Sie frühzeitig definieren und diese dann durch eine Rechtsabteilung prüfen lassen. In der Praxis birgt insbesondere die Definition der datenschutzrechtlichen Anforderungen ein großes Problempotenzial. Hier kann der § 11 des BDSG helfen. Hier sind die Anforderungen an den Auftragdatenverarbeiter definiert. Vergleiche: BDSG § 11
239
D Applikationsebene
D.4
Betriebsphase
D.4.2
Prozesse zur sicheren Applikationsverwaltung sind beschrieben.
Om
Si
Zm
Wi
Ko
V
D.4.2.1 D.4.2.2 D.4.2.3
Welche Prozesse zur Applikationsverwaltung sind beschrieben? Wer ist für die Prozesse verantwortlich? Gibt es eine geregelte Zuordnung zu den Prozessen?
L
Prozesse zur Applikationsverwaltung sind im Sinne der GoIT: Change Management Release Management Anforderungsmanagement Diese Prozesse werden in gängigen Standards wie ITIL genauer beschrieben. Wenn keine Prozessbeschreibung vorliegt, können Verantwortlichkeiten nicht zugewiesen werden. Prozesse werden dann nicht oder nur intuitiv umgesetzt. Sicherungsmaßnahmen werden nicht umgesetzt. Es entsteht das „Bastelbudenprinzip“.
#
Í
240
Prozesse nach Standards modellieren. Prozessverantwortlichkeiten zuordnen. Verantwortlichkeiten definieren. Ergebnisse dokumentieren. Zur Modellierung der Betriebsprozesse hat sich in der Praxis das Vorgehen nach ITIL bewährt. In seiner derzeitigen Fassung kommt insbesondere die Governance mehr zum Tragen. Sie sollten aber nicht versuchen, sich sklavisch an ITIL zu halten. Insbesondere bei der Dokumentation ist zu viel Standard nicht immer zielführend. Hier kann externe Hilfe von Vorteil sein, da ein praxisbezogener Einsatz hier viel von Erfahrungen abhängt. Vergleiche: ITIL v3
D.4 Betriebsphase
D.4
Betriebsphase
D.4.3
Integritäts- und vertraulichkeitssichernde Maßnahmen sind für den Betrieb beschrieben und umgesetzt.
Om
Si
Zm
Wi
Ko
V
D.4.3.1 D.4.3.2 D.4.3.3
Welche Maßnahmen wurden für den sicheren Betrieb definiert? Wie wird die Integrität im Betrieb sichergestellt? Wie wird die Vertraulichkeit im Betrieb sichergestellt?
L
Im Sinne der GoIT sind insbesondere bei der Sicherung der Vertraulichkeit und der Integrität Maßnahmenbeschreibung und Umsetzung als untrennbare Einheit zu verstehen. Es sollte keine Reifegraderhöhung darstellen, wenn Maßnahmen nur definiert, aber nicht umgesetzt sind. Werden diese Sicherheitsmaßnahmen nicht beschrieben und die damit zusammenhängenden Verantwortlichkeiten nicht definiert, so ist die zwingende Umsetzung der Maßnahmen und der damit zu erreichende Sicherheitsstandard gefährdet. Die daraus folgenden Gefährdungen sind mannigfaltig und bedrohen das gesamte Unternehmen.
#
Í
Maßnahmen für den sicheren Betrieb definieren. Verantwortlichkeiten für die Maßnahmen zuweisen. Die Umsetzung der Maßnahmen kontrollieren. Dokumentieren des gesamten Prozesses. Um die Maßnahmen zu definieren, sollte eine Risikoanalyse (ISO 27005, COBIT etc.)durchführt werden. Eine Einführung eines ISMS ist gerechtfertigt, wenn die Anwendungen einen hohen Wert für die Erreichung der unternehmerischen Ziele haben. Vergleiche: ISO 27005 BSI 100-3 COBIT
241
D Applikationsebene
D.4
Betriebsphase
D.4.4
Etwaige Verschlüsselungsverfahren sind beschrieben.
Om
Si
Zm
Wi
Ko
V
D.4.4.1 D.4.4.2
Welche Verschlüsselungsverfahren werden verwendet? Wo sind die Verfahren beschrieben?
L
Zu den Verschlüsselungsverfahren im Sinne der GoIT zählen nicht nur die einzelnen Chiffremechanismen, sondern auch alle Prozesse um diese Mechanismen herum. Hierzu zählen auch die Schlüsselverwaltung, die Prozessdefinition und die Verantwortlichkeiten für die Lebenszyklusphasen der Verschlüsselungsverfahren. Werden die Verschlüsselungsverfahren nicht beschrieben, so sind die Bedrohungen mannigfaltig. Es können Schlüssel verloren gehen, und verschlüsselte Daten sind damit nicht mehr verwendungsfähig. Nicht aktualisierte Schlüsselpaare können veralten und ggf. geknackt werden. Dadurch kann ein falsches Gefühl von Sicherheit entstehen.
#
Í
242
Definieren der Anforderungen an das/die Verfahren. Regelungen für den Einsatz definieren. Verantwortlichkeiten definieren. Prozesse zur Schlüsselverwaltung und Aktualisierung beschreiben und dokumentieren. Um hier eine geeignete Dokumentation zu erstellen, kann aus den BSI-Grundschutzkatalogen der Baustein 1.7 Kryptokonzept zur Hilfe genommen werden. Vergleiche: BSI Grundschutzkataloge Baustein 1.7 Kryptokonzept
D.4 Betriebsphase
D.4
Betriebsphase
D.4.5
Prozesse für die Benutzerverwaltung innerhalb der Anwendung sind dem Betrieb bekannt und dokumentiert.
Om
Si
Zm
Wi
Ko
V
D.4.5.1 D.4.5.2
Welches Dokument unterstützt die Benutzerverwaltung? Welche Prozesse unterstützen die Benutzerverwaltung?
L
Da die Benutzerverwaltung nicht immer in den Händen der Fachabteilung liegt, sollten die Prozesse definiert sein. Diese sind im Allgemeinen: Anlegen, Bearbeiten und Löschen eines Benutzers. Benutzer werden unkontrolliert angelegt, nicht oder falsch bearbeitet und in der Regel nicht gelöscht, sobald sie die Anwendung nicht mehr verwenden. Unberechtigter Zugang und Zugriff sind die Folge. Daten können vernichtet oder gestohlen werden, ohne dass etwas nachgewiesen werden kann.
#
Übergabe der Regelungen der Benutzerverwaltung durch die Entwicklung. Prozesse zur Verwaltung definieren. Zuständigkeiten und Verantwortlichkeiten definieren. Kontrolle der Umsetzung. Meldeergebnisse definieren. Eskalationswege definieren.
Í
Eine für den Betrieb geeignete Dokumentation für den Betrieb kann in einem Betriebshandbuch erfolgen. Dieses Handbuch sollte auch Teil der Serviceverträge sein. Hierbei sind insbesondere Administrationszugänge des Betreibers wichtig. Eine weitere Hilfe bei der Definition der Prozesse kann das RACI-Schema (Responsable, Accountable, Consulted, Informed) sein.
Vergleiche: RACI-Model
243
D Applikationsebene
D.4
Betriebsphase
D.4.6
Eine Testumgebung der Applikation ist vorhanden.
Om
Si
Zm
Wi
Ko
V
D.4.6.1 D.4.6.2
Wie werden Tests durchgeführt? Welche Testumgebung wird genutzt?
L
Testumgebungen im Sinne der GoIT sind produktivnahe Umgebungen, in denen unter realen Bedingungen getestet werden kann, welche Auswirkungen Anwendungsänderungen (Patches, Releasewechsel etc.) haben. Es wird hierbei nur mit Testdaten gearbeitet (pseudoanonymisiert oder anonymisiert). Ohne eine Testumgebung können Änderungen nicht unter realen Verhältnissen getestet werden. Dies kann dazu führen, dass die Anwendung nach einer Änderung weder verfügbar noch integritätssicher ist. Dies hat Auswirkungen auf die geschäftlichen Ziele, deren Erreichung die Anwendung unterstützen soll.
244
#
Definition einer Testumgebung. Realisierung der Testumgebung. Erstellen eines Zugriffkonzepts für die Testumgebung. Datenaufbereitung für die Testfälle. Dokumentation der Ergebnisse der Testfälle. Sicheres Löschen aller Daten, auch der pseudoanonymisierten Testdaten.
Í
In der Praxis stellen virtuelle Systeme eine erheblich günstigere Variante der Testumgebung dar. Auf der anderen Seite kann bei einem Totalausfall der Produktivumgebung die Testumgebung als Notfallsystem herangezogen werden. Die jeweiligen Vor- und Nachteile sollten gegenübergestellt werden.
D.5 Migrationsphase
D.5
Migrationsphase D.5.1
Der im Falle einer Migration durchzuführende Prozess ist definiert und dokumentiert.
Om
V
Si
D.5.1.1 D.5.1.2
L
Zm
Wi
Ko
Welche Prozesse zur Änderung und Migration sind implementiert? Welche Standards liegen diesen Prozessen zu Grunde?
Migrationen von Anwendungen gehen über das normale Releasemanagement hinaus. Sie bedürfen eines gesondert definierten und dokumentierten Migrationsprozesses. Migrationen ohne geeigneten Prozess können zu erheblichen Störungen der Verfügbarkeit bzw. zu einem Totalausfall der Anwendung führen. Dies hat erhebliche Auswirkungen auf die Erfüllung der geschäftlichen Ziele, welche die Anwendung unterstützen soll.
#
Den Migrationsprozess beschreiben. Die Verantwortlichkeiten definieren. Sicherungsverfahren und Roll-Back-Verfahren definieren und dokumentieren. Die Migrationsphase in einzelnen Schritten durchführen. Geeignete Ressourcen für die Migrationsphase bereitstellen.
Í
Auch hier bietet es sich an, ein eigenes Projekt für die Migration zu etablieren, um den geschäftlichen Hintergrund der Migration stets mit den entstehenden Kosten und Änderungen im Blick zu behalten und dessen geschäftliche Rechtfertigung zu liefern.
245
D Applikationsebene
D.5
Migrationsphase
D.5.2
Eine Migration erfolgt geplant.
Om
Si
Zm
Wi
Ko
V
D.5.2.1
Auf welcher Grundlage wurde die Migrationsplanung durchgeführt?
L
Damit eine Migration geplant erfolgt, muss nicht nur ein Prozess umgesetzt werden, sondern auch in einem bestimmten zeitlichen Ablauf erfolgen. Ebenso sind Eventualitäten zu berücksichtigen, die außerhalb des Prozesses liegen, aber die Migration beeinflussen können. Eine nicht geplante Migration (z.B. zeitlicher Ablauf) kann aufgrund von nicht kalkulierten Eventualitäten außerhalb des Migrationsprozesses zu einem Totalverlust der Anwendung und in Folge zu extrem hohen Kosten für den Roll-Back bzw. die Neuentwicklung führen.
#
Í
246
Erstellen eines Projektplans zur Migration anhand des Prozesses. Definition von Lenkungskreis und Projektleitung. Herausarbeiten des geschäftlichen Zwecks. Kalkulation des Projektbudgets mit Toleranzen. Entscheidungsdefinition bei Ausnahmen. Definition eines Ersatzplanes. Es bietet sich an, ein eigenes Projekt für die Migration zu etablieren, um den geschäftlichen Hintergrund der Migration stets mit den entstehenden Kosten und Änderungen im Blick zu behalten und dessen geschäftliche Rechtfertigung zu liefern. Hierbei können Methoden wie PRINCE2® zu Hilfe genommen werden. Vergleiche: PRINCE2® 2009 www.prince2.org
D.6 Roll-Off
D.6
Roll-Off D.6.1
Die Benutzerverwaltung ist auch über die End-of-Life-Phase hinaus geregelt.
Om
Si
Zm
Wi
Ko
V
D.6.1.1 D.6.1.2
Welche Benutzer sind nach der End-of-Life-Phase eingerichtet? Welche gesetzlichen Anforderungen machen eine Benutzerverwaltung nötig?
L
Gesetzliche Anforderungen, insbesondere Aufbewahrungspflichten, können ein zur Verfügung stellen der Daten der Anwendung über das End of Life (bei Kaufsoftware „Out of Support“) voraussetzen. Daher sind alle Daten, die eine eigene Zugriffsstruktur oder gar Verschlüsselung besitzen, mit einer Benutzerverwaltung zu versehen. Daten, deren Anwendungen und somit die Zugriffsregelung nicht mehr verfügbar sind, können Unbefugten in die Hände gelangen. Bei Kontrollen durch Aufsichtsbehörden können Daten nicht mehr zeitnah zur Verfügung gestellt werden. Dies kann zu erheblichen Strafen führen.
#
Festlegen der gesetzlichen Anforderungen der Daten. Erstellen eines Zugriffskonzepts für die Daten der Anwendung. Erarbeiten eines Langzeitarchivierungsprozesses. Implementierung des Prozesses und des damit verbundenen Zugriffsschutzes. Beachten der Verschlüsselungsanforderungen.
Í
Um die gesetzlichen Anforderungen zu erfüllen, gibt es mehrere Wege wie Langzeitarchivierungssysteme oder die Übertragung auf andere Medien (Datenbänder, Papier, Mikrofilm etc.). Welche Lösung geeignet ist, hängt von der Masse der Daten sowie deren Archivierungsanforderungen ab.
247
D Applikationsebene
D.6
Roll-Off
D.6.2
Betriebsmittel werden ordnungsgemäß entsorgt
Om
V
Si
D.6.2.1 D.6.2.2
L
Zm
Wi
Ko
Welche Methoden zur Betriebsmittelentsorgung werden genutzt? Wer ist für die ordnungsgemäße Entsorgung verantwortlich?
Betriebsmittel wie Datenspeichermedien etc. können unter Umständen auch nach dem Roll-Off noch mit vertraulichen Daten gefüllt sein. Eine ordnungsgemäße Entsorgung im Sinne der GoIT ist eine vollständige Zerstörung der Daten auf logischer oder, wenn dies nicht möglich ist, auf physikalischer Ebene. Nicht ordnungsgemäß entsorgte Betriebsmittel können vertrauliche Daten enthalten, die Unbefugten zugänglich werden können.
#
Löschen aller Betriebsmittel gemäß den Vertraulichkeitsanforderungen. Ggf. physikalische Zerstörung.
Í
In der Praxis hat sich eine direkte, nicht wiederherstellbare Vernichtung der Datenträger mittels externer Datenvernichtungsfirmen etabliert. Achten Sie darauf, den Vernichtungsprozess zu überwachen oder vorher die Daten logisch mithilfe von Shredder-Tools zu vernichten.
248
Vergleiche: BSI GSK M2.13
D.6 Roll-Off
D.6
Roll-Off
D.6.3
Durch die Anwendung mitgenutzte Ressourcen sind durch Befugte freigegeben.
Om
V
Si
D.6.3.1 D.6.3.2
L
Zm
Wi
Ko
Welche Ressourcen der Anwendung werden von mehreren Anwendungen genutzt? Wer gibt die Ressourcen frei?
Mitgenutzte Ressourcen im Sinne der GoIT sind z.B. Datenbankmanagementsysteme, die mehrere Datenbanken unterschiedlicher Anwendungen betreiben, oder Mainframe-Systeme, deren Rechenkraft mitgenutzt wird. Werden nicht mehr benötigte Ressourcen nicht wieder freigegeben, so werden diese unnötig gebunden, und es kommt zu Systemleichen, die nicht mehr optimal genutzt werden. Dies kann erhebliche Investitionskosten nach sich ziehen, die aufgrund falscher Auslastungszahlen entstehen.
#
Í
Definieren aller Ressourcen, die nicht mehr benötigt werden. Verantwortliche für eine Freigabe definieren. Die Ressourcenfreigabe dokumentieren. Hierbei können die Anforderungsbeschreibung bzw. vertraglich zugesicherte Ressourcen zu Hilfe gezogen werden.
249
E E Inhaltsebene Inhalte im Sinne der Inhaltsebene sind alle Objekte, die von den IT-Systemen abgebildet und in Form von Daten geführt werden: Nutzdaten, z.B. Personaldaten in einem Personalmanagementsystem oder Materialbestandsdaten in einer Lagerverwaltung Systemeigene Daten, z.B. Konfigurationsdaten Systemerzeugte Daten, z.B. Logging-Daten
251
E Inhaltsebene
E.1
Planungsphase E.1.1
Es werden die und nur die Daten vorgesehen, die für den Geschäftszweck benötigt werden.
Om
V
Si
E.1.1.1
E.1.1.2
L
Zm
Wi
Ko
Wo ist dokumentiert, welche Daten für welche Zwecke benötigt werden, wann sie erhoben, wo sie gespeichert1 und für welchen Zeitraum sie vorgehalten werden sollen? Wie soll gewährleistet werden, dass die Vorgaben für die Speicherung der Daten eingehalten werden (z.B. Löschung von personenbezogenen Daten, die nicht mehr benötigt werden)?
I
M
P
R
Eine effektive Datenplanung sorgt dafür, dass benötigte Daten zur Verfügung stehen und nicht benötigte Daten erst gar nicht geführt werden. Die Speicherung nicht benötigter personenbezogener Daten entspricht nicht dem Datenvermeidungsgrundsatz des BDSG (Ordnungsmäßigkeit). Das Führen nicht benötigter Daten ist zudem unwirtschaftlich. Fehlen benötigte Daten, kann die Funktionserfüllung beeinträchtigt werden (Zweckmäßigkeit).
#
Í
1
252
B
E
Erstellen einer Datenübersicht/Data Dictionary und entsprechender Datenmodelle. Einpflegen von verwendeten Daten in Prozessbeschreibungen und Verfahrensdokumentationen. Definieren von Vorgaben zur Speicherung der Daten und Festlegung von Maßnahmen, die die Einhaltung der Vorgaben sicherstellen. Die Datenplanung sollte bei Änderungen der Architektur und/oder der Prozesse überprüft werden. Vergleiche: BDSG §3a, BDSG §14 Abs. 1
Unter dem Speicherort wird hier der logische Speicherort (z.B. ein Datenbank-Datenfeld) verstanden, da bei modernen Speicherkonzepten der physische Speicherort dynamisch bestimmt wird.
E.1 Planungsphase
E.1
Planungsphase
E.1.2
Die Gewährleistung der Datenkonsistenz ist in der Planung berücksichtigt.
Om
Si
Zm
Wi
Ko
V
E.1.2.1 E.1.2.2 E.1.2.3
Wie werden die Speicherorte der Daten synchronisiert? Wie werden Änderungen an den Daten erkennbar gemacht? Wie wird verhindert werden, dass die Daten unsinnige Inhalte speichern?
L
Die Datenkonsistenz sorgt dafür, dass die Daten nicht inhaltlich verfälscht oder in ihrer Bedeutung fehlerhaft werden. Risiko, dass inkonsistente Daten unbemerkt inhaltlich falsch sind oder mehrere, verschiedene Inhalte zu einem Datum existieren. Bei buchführungsrelevanten Daten Verstoß gegen die ordnungsgemäße Aufbewahrung, bei personenbezogenen Daten unbefugte Veränderung der Daten.
#
Í
2
Etablierung eines führenden Speicherorts2 für ein Datum. Synchronisation aller anderen Speicherorte. Sicherung der Datenintegrität, z.B. durch Prüfsummen oder digitale Signatur. Validierung und Plausibilisierung von Dateneingaben. Datenkonsistenz und Datenintegrität sind eng verbunden. Vergleiche: GoB Hauptgrundsätze §238 Abs.1 HGB BDSG §9 Anhang
Siehe auch (in GoIT): Abschnitte E.1.3 und E.4.2
Unter dem Speicherort wird hier der logische Speicherort (z.B. eine Datenbank) verstanden, da bei modernen Speicherkonzepten der physische Speicherort dynamisch bestimmt wird.
253
E Inhaltsebene
E.1
Planungsphase
E.1.3
Die Gewährleistung der Datenqualität ist in der Planung berücksichtigt.
Om
V
Si
E.1.3.1 E.1.3.2 E.1.3.3 E.1.3.4
L
Zm
Wi
Ko
Wo ist dokumentiert, wann die Inhalte als korrekt und vollständig zu betrachten sind? Wie wird der Aktualitätsstand der Daten zu erkennen sein? Wie sollen unsinnige Dateneingaben verhindert bzw. Dateninhalte auf Korrektheit geprüft werden? Welche Prozesse zur Datenaktualisierung sollen etabliert werden?
Die Datenqualität sorgt dafür, dass die Daten korrekt, aktuell und vollständig sind. Bei buchführungsrelevanten Daten Verstoß gegen die Vollständigkeit und formale Richtigkeit der Daten. Mit nicht korrekten Daten kann die Funktion des IT-Verfahrens nicht erfüllt werden (Zweckmäßigkeit).
#
Í
254
Implementieren von Plausibilitätsprüfungen im Zuge der Dateneingabe. Mitspeichern eines Zeitstempels. Erstellen eines Datenanforderungskatalogs. Die Datenqualität kann nur zum Teil automatisiert sichergestellt werden. Vor allem der semantische Inhalt der Daten wird manuell zu prüfen sein. Vergleiche: GoBS Punkt 3.1
Siehe auch (in GoIT): Abschnitte E.1.2 und E.4.2
E.1 Planungsphase
E.1
Planungsphase
E.1.4
Die Daten werden hinsichtlich der Kritikalität bewertet.
Om
V
Si
E.1.4.1 E.1.4.2
L
Zm
Wi
Ko
Wo ist dokumentiert, auf welche Weise die Kritikalität bewertet werden soll und welche Folgen sich aus der Bewertung ergeben? Wann wird die Kritikalität der Daten bewertet und wo wird sie vermerkt?
Die Datenkritikalität gibt an, wie schutzbedürftig die Daten im Sinne der Informationssicherheit anzusehen sind. Kritische Daten sind stärker zu schützen als unkritische. Beeinträchtigung von Geschäftsprozessen und Schäden für das Unternehmen (monetär, Image usw.), wenn kritische Daten nicht ausreichend geschützt werden.
#
Definieren von Kritikalitätsstufen und dem sich daraus ergebenden Schutzbedarf. Verankern eines Bewertungsschritts im Prozess der Datenplanung.
Í
Für den Schutzbedarf, der sich aus der Kritikalität ergibt, sollten Anforderungen hinsichtlich der Sicherheitskriterien (Verfügbarkeit, Vertraulichkeit, Integrität usw.) formuliert werden.
Vergleiche: ISO 27005 Annex B
255
E Inhaltsebene
E.2
Entwicklungsphase E.2.1
Es werden möglichst keine Produktionsdaten in Entwicklungs- oder Testumgebungen verwendet.
Om
V
Si
E.2.1.1 E.2.1.2
L
Zm
Wi
Ko
Woher stammen die Daten, die in den Entwicklungs- und Testumgebungen verwendet werden? Wie wird gewährleistet, dass ausschließlich fiktive Personendaten verwendet bzw. die Daten anonymisiert werden?
Produktionsdaten sind Echtdaten (z.B. Kundendaten), die für die Abwicklung der Geschäftsprozesse benötigt werden. Vertrauliche Daten (u.U. personenbezogen) können Unbefugten (Entwickler, Tester) zugänglich werden.
#
Í
256
Definieren des Prozesses zur Bereitstellung von Daten, die in der Entwicklung und im Test verwendet werden sollen. Überschreiben von vertraulichen Daten, Anonymisierung von personenbezogenen Daten. Produktionsdaten sollten grundsätzlich nur in der Produktionsumgebung auftauchen (nicht in anderen Umgebungen, Handbüchern, Fehlermeldungen, Reports, Protokollen ...) Vergleiche: BSI M6.2.6. BDSG Anlage zu §9
I
B
E
M
P
R
E.2 Entwicklungsphase
E.2
Entwicklungsphase
E.2.2
Für Tests werden möglichst geeignete Testdaten verwendet.
Om
V
Si
E.2.2.1 E.2.2.2 E.2.2.3
L
Zm
Wi
Ko
Wie wird ermittelt, welche Strukturen und Datenkonstellationen in der Praxis vorkommen bzw. vorkommen können? Wie werden aufgrund der Strukturanalyse der Daten die Testdaten erstellt? Wie viele Kombinationen von Datenausprägungen (Datenfälle) werden für Tests erstellt?
I
B
E
M
P
R
Die Aussagekraft von Tests hängt entscheidend von der Qualität und der Eignung der Testdaten ab. In der Praxis auftretende Datenkonstellationen werden nicht getestet und können im Betrieb die Funktionserfüllung beeinträchtigen (bis hin zu Ausfall von Systemen oder Geschäftsprozessen).
#
Í
Untersuchen der Charakteristika der Daten. Festlegen der Testabdeckung (Anzahl der getesteten Fälle im Verhältnis zu den möglichen Fällen). Neben der inhaltlichen Analyse sollten auch die verwendeten Datenformate und Wertebereiche untersucht werden, insbesondere wenn die Daten automatisiert weiterverwendet werden. Wird beispielsweise für eine Telefonnummer ein Textfeld verwendet, ist auch der Inhalt „Handy: 0171/123456“ zulässig. Vergleiche: BSI M2.8.3
257
E Inhaltsebene
E.2
Entwicklungsphase
E.2.3
Testdaten werden möglichst automatisiert generiert.
Om
V
Si
E.2.3.1 E.2.3.2 E.2.3.3
L
Zm
Wi
Ko
Wie wird ermittelt, wie viele Testfälle für den Test erforderlich sind und wie komplex sind die Testfälle? Welche Tools (Testdatengeneratoren) kommen für die Erstellung der Testfälle bzw. Testdaten zum Einsatz? Wie wird garantiert, dass die Anforderungen an die Testfälle von den Generatoren erfüllt werden?
Testdatengeneratoren sind Softwareprodukte, die einen Testdatenbestand mit sehr vielen verschiedenen Datenkonstellationen erstellen können. Unzureichende Anzahl von Testfällen, da aufgrund des Aufwands manuell nur eine begrenzte Anzahl von Testfällen erstellt werden kann.
258
#
Definieren der Anforderungen für die Testfälle. Auswahl geeigneter Testdatengeneratoren für die Erstellung der Testfälle.
Í
Die Charakteristik der Daten sollte möglichst vielfältig gestaltet werden können (Umlaute, Zahlenbereiche, Datenformate, usw.)
I
B
E
M
P
R
E.2 Entwicklungsphase
E.2
Entwicklungsphase
E.2.4
Die Daten, die durch das entwickelte System entstehen, werden dokumentiert.
Om
V
Si
E.2.4.1 E.2.4.2
L
Zm
Wi
Ko
Welche Daten entstehen durch das entwickelte System und wo sind sie im aktuellen Zustand dokumentiert? Wo ist dokumentiert, was diese Daten bedeuten und wie diese Daten beschaffen sein müssen, damit das System einwandfrei funktioniert?
I
B
E
M
P
R
Daten, die durch das entwickelte System entstehen, sind beispielsweise Konfigurationsdaten, Einstellungen oder Protokollierungsdaten. Bei fehlerhaften Daten ist die Funktionserfüllung gefährdet. Fehlt die Dokumentation, ist eine Wiederherstellung des Systems erschwert.
#
Erstellen einer Übersicht der durch das entwickelte System entstehenden Daten und einer Beschreibung dieser Daten (soweit nicht bereits vorhanden). Dokumentieren des Zustands dieser Daten zu dem Zeitpunkt, in dem das System in Produktion geht geht, und jeweils dann, wenn Änderungen an diesen Daten erfolgen.
Í
Bei Standardsoftware, die von einem Hersteller bezogen wird, sollte eine Beschreibung der Systemdaten Bestandteil der mit ausgelieferten Handbücher sein. Erfolgt die Dokumentation des Zustands durch das System selbst, dann muss sichergestellt sein, dass nach Störungen (Absturz, Datenträger-Crash, usw.) das System vollständig wiederhergestellt werden kann.
Vergleiche: GoBS 6.
Siehe auch (in GoIT): Abschnitt E.4.3
259
E Inhaltsebene
E.3
Implementierungsphase E.3.1
Es ist transparent, welche Daten in welchen Speicherorten geführt und auf welchen Datenträgern archiviert werden
Om
V
Si
E.3.1.1
E.3.1.2
L
Zm
Wi
Ko
Wo ist vermerkt bzw. wie kann kurzfristig ermittelt werden, welche Speicherorte3 innerhalb der Implementierung für welche Daten verwendet werden? Wo ist dokumentiert, welche Daten laut Implementierungskonzept auf welchen Datenträgern archiviert werden sollen?
Für die Datensteuerung und -kontrolle sowie für den Datenschutz ist es notwendig, zu jeder Zeit bestimmen zu können, wo welche Daten geführt werden. Verstoß gegen das BDSG, wenn die Existenz personenbezogener Daten nicht geklärt werden kann. Auftreten von „Datenleichen“. Unzureichend geschützte Speicherorte und Datenträger, wenn der aus den Daten resultierende Schutzbedarf nicht ermittelt werden kann.
#
Í
3
260
Erstellen von Datenplänen, -übersichten und -modellen, besonders wenn gemeinsame, übergreifende Speicher verwendet werden. Einsatz von Software, die Datenspeicher analysiert (Data Mining). Bei modernen Speichersystemen bzw. -infrastrukturen ist nicht mehr statisch nachvollziehbar, auf welchen Datenträgern die Daten physisch existieren. Vergleiche: AO §200 Abs. 1, GDPdU, BDSG Anlage zu §9
Siehe auch (in GoIT): Abschnitt E.1.2
Unter dem Speicherort wird hier der logische Speicherort (z.B. ein Datenbank-Datenfeld) verstanden.
I
B
E
M
P
R
E.3 Implementierungsphase
E.3
Implementierungsphase
E.3.2
Es wird kontrolliert, dass die Daten gemäß ihrer Spezifikation implementiert werden
Om
V
Si
E.3.2.1
E.3.2.2 E.3.2.3
L
Zm
Wi
Ko
Auf welche Weise wurde dafür gesorgt, dass die Datenplanung und ggf. durchgeführte Tests die Grundlage der Implementierung bildeten? Wann wurden die implementierten Datenstrukturen mit der Datenplanung abgeglichen? Wird die Planung im gesamten implementierten Verfahren eingehalten (z.B. bei Datentransporten, Schnittstellen, Konvertierungen usw.)?
I
B
E
M
P
R
In der Praxis kann ein IT-Verfahren aus einer komplexen Architektur von IT-Systemen und Anwendungen bestehen. Es ist wichtig, dass die Datenplanung in der gesamten Architektur des IT-Verfahrens eingehalten wird. Beeinträchtigung der Sicherheit und Zweckmäßigkeit, wenn die implementierten Daten nicht der Datenplanung entsprechen.
#
Í
Überprüfen der Datenplanung in der Implementierung (können die Daten gemäß der Planung beschafft bzw. erzeugt werden, funktionieren die Schutzmechanismen für die Daten usw.). Die Überprüfung kann nicht nur statisch in den Systemen, sondern auch dynamisch (Datenströme) erfolgen, d.h. wie die Daten durch die Systeme „fließen“.
261
E Inhaltsebene
E.4
Betriebsphase E.4.1
Buchführungsrelevante Daten sind nach der Eingabe nicht mehr änderbar
Om
V
Si
E.4.1.1
E.4.1.2
L
Zm
Wi
Ko
Auf welche Weise stellt das System sicher, dass buchführungsrelevante Daten nach der Eingabe nicht mehr geändert werden können? Durch welche Applikationen und Systeme fließen die Daten nach der Eingabe und erfüllen alle Systeme diese Anforderung?
Zum Schutz vor Manipulationen schreiben die Grundsätze ordnungsmäßiger Buchführung (GoB) vor, dass nachträgliche Veränderungen nicht vorgenommen werden dürfen. Werden die Daten mithilfe eines EDV-Systems geführt, dann setzt das System diese Forderung durch. Verstoß gegen die Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS).
#
Í
262
Aufnahme dieser Anforderung in das Pflichtenheft vor der Beschaffung bzw. Entwicklung des Systems. Test der Funktionserfüllung: Lassen sich die Daten nach der Eingabe tatsächlich nicht mehr ändern? Es muss verhindert werden, dass die Daten unter Umgehung der Applikation nachträglich verändert werden können (z.B. durch den Datenbank- oder Plattformadministrator) Vergleiche: GoBS Teil III
I
B
E
M
P
R
E.4 Betriebsphase
E.4
Betriebsphase
E.4.2
Wichtige Daten werden vor der Speicherung validiert bzw. plausibilisiert
Om
V
Si
E.4.2.1 E.4.2.2 E.4.2.3
L
Zm
Wi
Ko
Wie werden wichtige, eingegebene Daten auf Plausibilität geprüft? Wie wird geprüft, ob eingegebene Werte gültig sind? Wo sind die Eingabeprüfungen beschrieben?
I
B
E
M
P
R
Für die Prüfung der Plausibilität bei Dateneingaben gibt es verschiedene Möglichkeiten, u.a.: das Datenformat (besteht die Eingabe bei einer Zahl tatsächlich nur aus Ziffern?), der Wertebereich (Ene negative Zahl im Datenfeld „Entfernung“ ist nicht plausibel) oder ein Datenmuster (Eine deutsche Postleitzahl muss fünfstellig sein). Einbringen von unsinnigen bzw. unkorrekten Daten (Datenschrott) in den Datenbestand.
#
Definieren der Anforderungen in Bezug auf die Validierung und Plausibilisierung. Einbeziehen der Anforderungen in die Produktauswahl bzw. Aufnahme in das Pflichtenheft.
Í
Im Fall von Standardsoftware ist im Zuge der Beschaffung zu klären, welche Möglichkeiten die Software bietet, um eingegebene Daten zu validieren bzw. auf Plausibilität zu prüfen.
Vergleiche: GoBS 3.1
Siehe auch (in GoIT): Abschnitte E.1.2 und E.1.3
263
E Inhaltsebene
E.4
Betriebsphase
E.4.3
Wichtige, kritische oder sensible Daten sind vor Verlust geschützt
Om
V
Si
E.4.3.1 E.4.3.2 E.4.3.3 E.4.3.4 E.4.3.5
L
Zm
Wi
Ko
Auf welche Weise werden wichtige Daten vor Verlust geschützt? Gab es eine Planung dieses Schutzes? Wo sind die Ergebnisse dokumentiert? Welche Verlustszenarien (Datenträgerdefekte, Diebstahl, usw.) wurden in dieser Planung zugrunde gelegt? Wie wurde entschieden, auf welcher Ebene (Applikation, System, Hardware) der Schutz realisiert werden soll? Wie ist die Zuständigkeit für den Schutz (Implementierung, Prüfung) geregelt?
Wichtige bzw. kritische Daten sind in der Regel Daten, die für die Geschäftstätigkeit von Bedeutung sind. Sensible Daten sind besonders schützenswerte Daten, deren Verlust oder Kompromittierung negative Folgen für das Unternehmen hätte. Bei buchführungsrelevanten Daten Verstoß gegen die GoBS. Beeinträchtigung von Geschäftsprozessen und dadurch Schäden für das Unternehmen.
#
Erstellen einer Datensicherung (Backup) auf einem dauerhaften OfflineDatenträger (DVD, Bandlaufwerk ...). Spiegelung der Daten unter Einsatz von mehreren Online-Datenträgern (meist Festplatten). Replikation der Daten auf mehrere Systeme (Applikationsebene).
Í
Neben augenscheinlichen Ursachen wie z.B. Datenträgerdefekte sollten auch Ursachen wie Überschreibungen, falsche Änderungen usw. betrachtet werden.
264
Vergleiche: GoBS 5. BSI Baustein 1.4
I
B
E
M
P
R
E.4 Betriebsphase
E.4
Betriebsphase
E.4.4
Vertrauliche Daten sind nur den Personen zugänglich, für die sie bestimmt sind
Om
V
Si
E.4.4.1
E.4.4.2 E.4.4.3
L
Zm
Wi
Ko
Wie ist ein vertrauliches Datum als solches erkennbar und wie kann nachvollzogen werden, für wen das Datum zugänglich sein soll? Wie wird verhindert, dass vertrauliche Daten nicht unbefugt gelesen oder kopiert werden? Wie wird überprüft, ob die Schutzmaßnahmen funktionieren und (noch) angemessen sind?
I
B
E
M
P
R
Als vertraulich gelten alle Daten, die vor unbefugtem Zugriff geschützt werden müssen. Bei personenbezogenen Daten Verstoß gegen das BDSG. Bei buchführungsrelevanten Daten Verstoß gegen die GoBS. Finanzielle (z.B. Verstoß gegen Verträge) und Imageschäden durch die unbefugte Kenntnisnahme oder das Bekanntwerden von vertraulichen Daten.
#
Í
Definieren des Personenkreises, für den ein vertrauliches Datum zugänglich sein soll bzw. Definieren von Vertraulichkeitsstufen. Etablieren eines effektiven Zugriffsschutzes (Berechtigungskonzept) für die Daten auf Applikations- und Systemebene (Authentifizierung und Autorisierung). Verschlüsselung der Daten bei Speicherung und Übermittlung. In der Praxis gebräuchlich sind die Vertraulichkeitsstufen öffentlich, unternehmensintern, vertraulich (nur bestimmte Gruppen im Unternehmen), streng vertraulich (nur einzelne Personen). Vergleiche: BDSG, Anlage zu §9 GoBS 5.3 BSI Baustein 1.1 Organisation M2.6, 2.7, 2.8
265
E Inhaltsebene
E.4
Betriebsphase
E.4.5
Vertrauliche bzw. personenbezogene Daten dürfen nur Personen zugänglich sein, die eine Verpflichtungserklärung zu Vertraulichkeit und Datenschutz abgegeben haben.
Om
V
Si
E.4.5.1 E.4.5.2 E.4.5.3
L
Zm
Wi
Ko
Existiert eine Vorlage für die Verpflichtungserklärung? Wie wurde sichergestellt, dass sie alle benötigten Inhalte enthält und rechtlich nicht zu beanstanden ist? Wie wird erreicht, dass alle Personen, die mit vertraulichen bzw. personenbezogenen Daten umgehen, die Erklärung abgegeben haben?
Verpflichtungserklärungen zur Wahrung der Vertraulichkeit (Datenschutz, Betriebsgeheimnis) sollten zum Standard jedes Beschäftigungsverhältnisses (auch bei externen Mitarbeitern und Dienstleistern) gehören. Bei Verstößen ist es schwieriger, der Person nachzuweisen, dass sie sich der besonderen Verantwortung hätte bewusst sein müssen.
#
Erstellen einer Verpflichtungserklärung zu Vertraulichkeit und Datenschutz. Verankerung der Erklärung im Personalbeschaffungsprozess (z.B. als Anlage zum Arbeitsvertrag).
Í
In vielen Fällen wird zusätzlich auch eine Erklärung gefordert, dass die betreffende Person kein Angehöriger von Scientology ist und deren Methoden nicht anwendet.
266
Vergleiche: BDSG §5
I
B
E
M
P
R
E.4 Betriebsphase
E.4
Betriebsphase
E.4.6
Der Zugriff auf vertrauliche/sensible Daten wird protokolliert
Om
V
Si
E.4.6.1 E.4.6.2 E.4.6.3
L
Zm
Wi
Ko
Wie kann nachvollzogen werden, wer wann auf welche vertrauliche/sensible Daten zugegriffen hat? Wo werden solche Zugriffe protokolliert? Wer hat Zugriff auf diese Protokolle und wie werden sie gegen unbefugte Veränderung geschützt?
I
B
E
M
P
R
Bei der Protokollierung von Zugriffen wird festgehalten, welche Identität zu welcher Zeit in welcher Weise auf Daten zugegriffen hat. Fehlende Beweissicherung bei Verstößen.
#
Í
Einrichtung einer Protokollierung von solchern Zugriffen (möglichst automatisiert durch die Applikation). Umsetzen eines angemessenen Schutzes für die Vertraulichkeit der Protokolldaten (Autorisierung, Verschlüsselung). Unter dem Begriff Zugriff wird hier vor allem lesender Zugriff verstanden. Ändernder Zugriff siehe E.5.7 Vergleiche: BDSG §9 Anhang Satz 1 BSI Bausteine Abschnitt Protokollierung, M5.9
267
E Inhaltsebene
E.5
Migrationsphase E.5.1
Die Verfügbarkeit und Vertraulichkeit der Daten ist auch bei Änderungen und Migrationen zu jedem Zeitpunkt sichergestellt
Om
V
Si
E.5.1.1
E.5.1.2 E.5.1.3 E.5.1.4 E.5.1.5
L
Zm
Wi
Ko
Wie wurden die Verfügbarkeits- und Vertraulichkeitsrisiken der Migration in der Migrationsstrategie berücksichtigt und wo wurden sie dokumentiert? Welche Migrationsstörungen wurden betrachtet und wie sollte ihnen begegnet werden? Existierte ein Rollback-Konzept? Wie wird gewährleistet, dass auf Datensicherungen und Archive der ursprünglichen Lösung weiter zugegriffen werden kann? Wie wird dafür gesorgt, dass Verantwortlichen der ursprünglichen Lösung ihre Rechte verlieren und die der neuen Lösung die Rechte bekommen?
Daten können im Zuge der Migration auch aus den Systemen extrahiert und in Zwischenspeichern (Dumps, temporäre Dateien usw.) gehalten werden. Sie sind in diesem Fall dort adäquat zu schützen. Fehlende Funktionserfüllung während oder nach der Migration. Verstoß gegen Aufbewahrungs- und Zugriffspflichten. Schäden durch Vertraulichkeitsverlust (z.B. durch ungeschützte Zwischenspeicherung von Daten).
#
268
Festlegen der Datenumgebungen in der Migration. Realisieren eines durchgängigen Zugriffskonzepts. Realisieren einer durchgängigen Datensicherung. Sicherstellen eines konsistenten Datenbestandes. Vergleiche: BDSG §9, GoBS Punkt 5, GDPdU
I
B
E
M
P
R
E.5 Migrationsphase
E.5
Migrationsphase
E.5.2
Die Datensemantik wird von einer Migration nicht ungewollt verändert
Om
V
Si
E.5.2.1 E.5.2.2 E.5.2.3 E.5.2.4
L
Zm
Wi
Ko
Wo ist die Semantik der Daten dokumentiert? Wie wurde dafür gesorgt, dass Datenbezeichnungen gleichbleibende Bedeutung besitzen? Wie sollte vorgegangen werden, wenn das neue System Daten nicht 1:1 abbilden kann? Wie wurde geprüft, ob sich die Datensemantik durch die Migration verändert hat?
I
B
E
M
P
R
Die Datensemantik steht für die inhaltliche Bedeutung der Daten. Diese soll sich durch die Migration nicht verändern. Verstoß gegen Verpflichtungen (z.B. bei buchführungsrelevanten Daten). Beeinträchtigungen von Geschäftsprozessen durch falsche Daten. Einspeisung von falschen Daten und dadurch semantisches Datenchaos. Verlust der Nachvollziehbarkeit.
#
Dokumentation, wie die Daten bezeichnet werden und welche inhaltliche Bedeutung sie haben. Mapping der Semantik vom Alt- auf das Neusystem (ggf. Anpassung der Datenbezeichnungen). Sicherstellen der semantisch korrekten Einspeisung von Daten bei datenzuführenden Systemen. Vergleiche: GoBS 2.
269
E Inhaltsebene
E.5
Migrationsphase
E.5.3
Datenänderungen werden in einem geordneten Prozess durchgeführt
Om
V
Si
E.5.3.1 E.5.3.2 E.5.3.3
L
Zm
Wi
Ko
Wo ist das Verfahren für Änderungen dokumentiert? Wer darf Änderungen beantragen, wer genehmigt sie nach welchen Maßgaben, wer führt die Änderungen durch? Wie wird die Möglichkeit von negativen Effekten (funktional, Sicherheit) durch die Änderung geprüft?
Daten werden durch Änderungen in ihrer Semantik oder Syntax modifiziert. Daher muss sichergestellt werden, dass die geänderten Daten den Prüfkriterien der Revision entsprechen. Gefährdung der Funktion oder der Sicherheit durch vorgenommene Änderungen. Verletzung der Ordnungsmäßigkeit, wenn die verwendete IT-Architektur nicht mehr zu den geänderten Daten passt.
#
Í
270
Etablierung eines Data-Change-Management-Prozesses, der für jede Änderung durchlaufen werden muss. Definieren eines Workflows für die Freigabe und die Produktivsetzung von Änderungen. Änderungen sollten grundsätzlich so geplant werden, dass es eine RollbackMöglichkeit gibt.
I
B
E
M
P
R
E.5 Migrationsphase
E.5
Migrationsphase
E.5.4
Datenänderungen werden protokolliert
Om
V
Si
E.5.4.1 E.5.4.2
E.5.4.3
E.5.4.4
L
Zm
Wi
Ko
Wie kann nach der durchgeführten Datenänderung der ursprüngliche Zustand in Erfahrung gebracht werden? Wo ist dokumentiert, welche Änderung an welchen Daten durchgeführt wurde, d.h. welcher „Vorher-Zustand“ in welchen „Nachher-Zustand“ überführt wurde? Wo ist der Verlauf des Änderungsprozesses dokumentiert, d.h. wer wann die Änderung beantragt, genehmigt und durchgeführt hat und welche Risiken betrachtet wurden? Wo und wie lange wird die Dokumentation aufbewahrt, wer hat in welcher Weise Zugriff darauf?
I
B
E
M
P
R
Die Forderung nach Transparenz in der IT erfordert es, sowohl den aktuellen Datenstand in der IT als auch deren Historie nachvollziehen zu können. Fehlende Transparenz und damit abnehmende Beherrschbarkeit der IT. Erschwerte Rollback-Möglichkeit. Erschwerte bis unmögliche Prüfbarkeit durch die Revision.
#
Í
Einrichten eines Workflows, der Dokumentationsschritte enthält. Erstellen eines Dokumentationsframeworks. Die Durchführung der Dokumentation kann mit Hmithilfe eines elektronischen Workflows durchgesetzt werden, d.h. die Datenänderung kann nicht abgeschlossen werden, wenn nicht dokumentiert wurde.
271
E Inhaltsebene
E.6
Roll-Off E.6.1
Vorgeschriebene Aufbewahrungsfristen werden gewährleistet
Om
V
Si
E.6.1.1
E.6.1.2 E.6.1.3
L
Zm
Wi
Ko
Wo ist dokumentiert, welche Aufbewahrungsfristen für die einzelnen Daten gelten und wer für die Einhaltung der Aufbewahrungsfristen verantwortlich ist? Wie wird eine Löschung von aufbewahrungspflichtigen Daten verhindert? Wie wird bei Migrationen sichergestellt, dass aufbewahrte Daten zugreifbar bleiben?
Die Aufbewahrungsfristen ergeben sich aus gesetzlichen Vorschriften und Verordnungen. Je nach Daten Verstoß gegen HGB, AO, GoBS, ProdHaftG, Steuerrecht, BGB, ZPO, AktG, RöV, StrlSchV.
#
272
Ermitteln und Dokumentieren der Aufbewahrungsfristen. Einrichten einer Löschsperre für die Daten. Archivierung der Applikations- und ggf. der Systemumgebung. Vergleiche: HGB §238, §257, §261 AO §147 GoBS 7.
I
B
E
M
P
R
E.6 Roll-Off
E.6
Roll-Off
E.6.2
Es ist definiert, wann und durch wen Daten gelöscht werden dürfen
Om
V
L
Si
E.6.2.1 E.6.2.2
Zm
Wi
Ko
Wo sind die Löschbedingungen für die Daten dokumentiert? Welche Rollen dürfen welche Daten löschen?
Die Zuständigkeit für Löschvorgänge muss eindeutig definiert sein, dabei müssen alle Accounts der löschenden Identitäten personalisiert sein.
I
B
E
M
P
R
Daten werden unbefugt oder unzulässigerweise gelöscht.
#
Umsetzen der Löschbedingungen in ein softwaregesteuertes System. Einrichten von Löschfenstern, in denen Daten gelöscht werden dürfen. Umsetzen der Löschberechtigungen durch entsprechende Berechtigungskonzepte.
Í
Es ist sicherzustellen, dass keine Aufbewahrungsfristen durch die Löschung verletzt werden (siehe E.5.1).
273
E Inhaltsebene
E.6
Roll-Off
E.6.3
Sensible Daten werden sicher, zuverlässig, dauerhaft und nachweisbar gelöscht
Om
V
Si
E.6.3.1 E.6.3.2 E.6.3.3
L
Zm
Wi
Ko
Gibt es einen definierten Datenlöschprozess für sensible Daten? Wie wird die Vertraulichkeit der Daten zu jedem Zeitpunkt der Löschung sichergestellt? Wie wird geprüft, ob sensible Daten zuverlässig und dauerhaft gelöscht wurden?
Sensible Daten, die gelöscht wurden, müssen unwiederherstellbar vernichtet sein. Datenschutzverstoß im Falle von personenbezogenen Daten. Schäden durch Vertraulichkeitsverlust.
#
274
Definieren eines Leitfadens zum Umgang mit sensiblen Daten und deren Löschung. Stichprobenkontrollen der Datenträger auf Spuren der gelöschten Daten. Vergleiche: BDSG §9 Anlage Satz 1 BSI 1.15
I
B
E
M
P
R
E.6 Roll-Off
E.6
Roll-Off
E.6.4
Die Vernichtung von Datenträgern mit sensiblen Daten wird geprüft und protokolliert
Om
V
Si
E.6.4.1 E.6.4.2
E.6.4.3 E.6.4.4
L
Zm
Wi
Ko
Welcher Ablauf ist vorgesehen, um einen Datenträger unbrauchbar zu machen bzw. zu vernichten? Auf welche Weise kann der Weg eines konkreten Datenträgers von der Außerbetriebnahme bis zur erfolgten Vernichtung nachvollzogen werden? Wo ist dokumentiert, wann und durch wen ein Datenträger unbrauchbar gemacht bzw. vernichtet wurde? Wer bestätigt die erfolgte Vernichtung? Erfolgt die Bestätigung für jeden konkreten Datenträger?
I
B
E
M
P
R
Es muss sichergestellt sein, dass ein zu vernichtender Datenträger auch tatsächlich vernichtet wurde. Datenträger (und damit alle unverschlüsselten bzw. nicht physisch gelöschten Daten) können in falsche Hände gelangen.
#
Konzipieren und nachhaltiges Umsetzen eines sicheren, kontrollierten Prozesses zur Vernichtung von Datenträgern mit sensiblen Daten. Alternativ: Verschlüsseln aller sensiblen Daten auf den Datenträgern. Vergleiche: BSI 1.15
275
F F Personelle Ebene Zu der personellen Ebene gehören: Administratoren User Outsourcing
277
F Personelle Ebene
F.1
Planungsphase F.1.1
Aufgaben und Verantwortung von Angestellten sind definiert.
Om
Si
Zm
Wi
Ko
V
F.1.1.1 F.1.1.2
Welche Dokumente beschreiben die Aufgaben der Angestellten? Welche Rollen sind für die Angestellten definiert worden?
L
Sicherheitsaufgaben und -verantwortung von Angestellten, Auftragnehmern und Drittbenutzern müssen im Einklang mit den Grundsätzen der IT-Organisation definiert werden. Sind Aufgaben und Verantwortungen nicht definiert, kann das dazu führen, dass wichtige Maßnahmen für einen ordnungsgemäßen IT-Betrieb nicht oder nur teilweise umgesetzt werden.
#
Í
1
278
Aufteilung der Aufgaben und Verantwortungen in Rollen. Die Rollenbeschreibungen dokumentieren. Beachtung aller relevanten Gesetze bei der Definition der Aufgaben und der Verantwortung. Wenn Sie innerhalb Ihrer Organisation Aufgaben und Verantwortungen definieren, ist das RACI1-Modell eine adäquate Lösung. Vergleiche: COBIT® – RACI-Modell ISO 27001
RACI: responsable, accountable, consulted, informed
F.1 Planungsphase
F.1
Planungsphase
F.1.2
Stellenbeschreibungen werden verwendet
Om
Si
Zm
Wi
Ko
V
F.1.2.1 F.1.2.2 F.1.2.3
Wer hat die Stellenbeschreibungen erstellt? Wie wurden die Sicherheitsorgane eingebunden? Wie werden die Stellenbeschreibungen bei der Vergabe mit eingebunden?
L
Stellenbeschreibungen definieren, was jeder Mitarbeiter zu tun hat. Sie können bei der Suche nach geeignetem Personal zu Rate gezogen werden. Ohne die Stellenbeschreibungen sind Verantwortlichkeiten nicht klar definiert. So kann es zu Kompetenzüberschreitungen und -überschneidungen kommen und damit zu einer erheblichen Störung des Ablaufes innerhalb der IT.
#
Í
2
Für jeden Mitarbeiter die wahrzunehmenden Aufgaben beschreiben. Die Aufgaben so zuschneiden, dass keine Überschneidungen entstehen. Stellenbeschreibungen für den Informationssicherheitsbereich können aus den einschlägigen Standards entnommen werden. Bei der Stellenbeschreibung sollten die Zuständigkeiten nach dem RACI2-Modell zugeordnet werden. Dies erleichtert das Verständnis für die zu besetzende Stelle. Vergleiche: BSI GSK M 3.51 COBIT® - RACI Modell
RACI: responsable, accountable, consulted, informed
279
F Personelle Ebene
F.1
Planungsphase
F.1.3
Anforderungen an besondere Stellen sind definiert.
Om
Si
Zm
Wi
Ko
V
F.1.3.1 F.1.3.2
Wie wurden die Stellenbeschreibungen definiert? Welche Sicherheitsstufen wurden eingeführt?
L
Besondere Stellen im Sinne der GoIT sind Stellen, deren Inhaber weitreichenden Einfluss auf die Schutzwerte der Informationstechnologie haben. Dies sind z.B. Administratoren für sensitive Systeme, das Informationssicherheitspersonal, Personen mit dem Zugang zu geheimen Informationen. Sind keine besonderen Stellenanforderungen definiert, so kann dies zu einer Falschbesetzung führen. Die Stelleninhaber sind unterqualifiziert und/oder nicht für einen sensitiven Bereich geeignet. Dies kann zu erheblichen Störungen des Betriebsablaufes und zu einem Verlust von sensitiven Informationen führen.
#
Í
280
Bei der Erstellung der Stellenbeschreibungen von besonderen Stellen Risikoanalysen durchführen. Eine Sicherheitsstufe für die jeweiligen Stellen vergeben. Mögliche Mitarbeiterüberprüfungen für die besonderen Stellen vorher mit dem Personalrat abstimmen. Müssen geheime oder streng vertrauliche Informationen geschützt und die jeweiligen Stellen entsprechend beschrieben werden, kann Hilfe beim Bundeswirtschaftsministerium (Geheimschutzvereinbarung) angefordert werden. Vergleiche: https://bmwi-sicherheitsforum.de
Siehe auch (in GoIT): Abschnitte F.1.4 und F.3.3
F.2 Entwicklungsphase
F.1
Planungsphase
F.1.4
Eine Überprüfung der Angestellten fand im Einklang mit den Gesetzen statt.
Om
Si
Zm
Wi
Ko
V
F.1.4.1 F.1.4.2 F.1.4.3
Wer hat die Sicherheitsüberprüfung durchgeführt? Welche internen/externen Organe wurden hinzugezogen? Welche Gesetze wurden beachtet?
L
Überprüfungen der Mitarbeiter im Sinne der GoIT beziehen sich auf die Überprüfung der vom Angestellten bereitgestellten Informationen. Des Weiteren sind die Vorschriften insbesondere des Datenschutzes und etwaiger anderer landesspezifischer Gesetze einzuhalten. Bei Sicherheitsüberprüfungen, die nicht gesetzeskonform durchgeführt werden, kann es zu erheblichen Geld- oder Haftstrafen kommen. Wird der Angestellte gar nicht überprüft, so können Unbefugte auf Unterlagen des Unternehmens zugreifen und Daten entwenden oder stehlen.
#
Í
F.2
Überprüfen der Informationen, die Bewerber geben. Kontrolle der Angestellten mit Zugang zu VS-Grad geschützten Dokumenten nach den Vorgaben der Sicherheitsüberprüfung Ü1. Wenn Sie in Ihrem Unternehmen Informationen besitzen, verarbeiten oder lagern, die einen Verschlusssachengrad haben, sollten Sie beim Bundesministerium für Wirtschaft eine Geheimschutzbetreuung anfordern. Dort bekommen Sie Informationen, wie Sie ggf. Angestellte gesetzeskonform überprüfen können. Vergleiche: BDSG https://bmwi-sicherheitsforum.de
Siehe auch (in GoIT): Abschnitte F.1.3 und F.3.3
Entwicklungsphase Im Sinne der GoIT werden Anforderungen wie Schulung und Training in der Betriebsphase betrachtet. Somit werden in dieser Phase keine Anforderungen gestellt.
281
F Personelle Ebene
F.3
Implementierungsphase F.3.1
Sicherheitsrichtlinien für Angestellte sind durch das Management in Kraft gesetzt worden.
Om
Si
Zm
Wi
Ko
V
F.3.1.1 F.3.1.2
Welcher Bereich ist für die Richtlinien zeichnungsberechtigt? Welcher Bereich bereitet die Richtlinien vor?
L
In Kraft zu setzende Richtlinien werden durch die Geschäftsleitung unterzeichnet und allen Betroffenen bekannt gegeben. Sie enthalten einen Zeitpunkt, ab dem sie verpflichtend sind. Werden Sicherheitsrichtlinien nicht in Kraft gesetzt, so sind sie nicht bindend. Verstöße können nicht geahndet werden.
#
Sicherheitsrichtlinien durch die Geschäftsführung in Kraft setzen. Kontrolle, ob Sanktionen bei Verstößen anwendbar. Von Richtlinien betroffene Angestellte vor der Inkraftsetzung informieren.
Í
Jedes in Kraft zu setzende Dokument sollte eine Zeichnungstabelle enthalten. Hier kann auch das RACI3-Modell helfen.
3
282
Vergleiche: COBIT® - RACI-Modell
RACI: responsable, accountable, consulted, informed
F.3 Implementierungsphase
F.3
Implementierungsphase
F.3.2
Angestellte sind Ihren Aufgaben entsprechend sensibilisiert.
Om
Si
Zm
Wi
Ko
V
F.3.2.1 F.3.2.2 F.3.2.3
Wie werden die Schulungen der Mitarbeiter nachgewiesen? Welche Schulungen werden durchgeführt? Wie werden die Inhalte vermittelt?
L
Entsprechend sensibilisiert sind Angestellte, wenn sie die für sie geltenden Regelungen kennen und nachvollziehen können. Werden Angestellte nicht entsprechend ihrer Aufgaben sensibilisiert, kann dies dazu führen, dass sie die Regelungen nicht akzeptieren und in der Folge Sicherheitsmaßnahmen umgehen oder nicht beachten. Dies kann zu extremen Schäden in allen Bereichen des Unternehmens führen.
#
Í
Sensibilisieren aller Angestellten der Organisation, Auftragnehmer und Drittbenutzer anhand geeigneter Maßnahmen. Regelmäßiges Informieren der Angestellten über organisationseigene Regelungen und Verfahren. Um eine durchgreifende Sensibilisierung der Angestellten zu erreichen, sollten die Schulungen für Awareness in das Schulungskonzept integriert werden. Besonders die Methode eLearning sollte dabei aus Kosten- und Ressourcenersparnisgründen beachtet werden. Welcher Sensibilisierungsgrad für welche Stelle notwendig ist, sollte aus der Stellenbeschreibung hervorgehen. Vergleiche: ISO 27001 Annex A.8.2.2
283
F Personelle Ebene
F.3
Implementierungsphase
F.3.3
Sensible Posten sind mit vertrauenswürdigen Angestellten besetzt.
Om
Si
Zm
Wi
Ko
V
F.3.3.1 F.3.3.2
Welche Posten erfordern eine Vertrauenswürdigkeit? Welche Form der Überprüfung wurde vorgenommen?
L
Im Sinne der GoIT sind sensible Posten Stellen, die einen Zugang zu sensiblen Informationen haben (z.B. Personalunterlagen, Forschung und Entwicklung etc.) Vertrauenswürdig sind Angestellte, wenn diese überprüft worden sind und die Überprüfung keine negativen Ergebnisse hatte. Werden sensible Posten nicht mit vertrauenswürdigen Angestellten besetzt, können Informationen gelöscht, gestohlen oder verfälscht werden.
#
Sensible Posten mit vertrauenswürdigen Angestellten besetzen. Regelmäßiges Durchführen gesetzeskonformer Überprüfungen. Die Stellenbeschreibungen der Posten definieren den Überprüfungsgrad.
Í
Werden sensible Posten in der Planungsphase definiert und in der Stellenbeschreibung gekennzeichnet, ist das Besetzen der Posten erheblich einfacher. Eine Risikoanalyse der sensiblen Bereiche kann die Einstufung erheblich vereinfachen.
284
Vergleiche: BSI GSK BS 1.2
Siehe auch (in GoIT): Abschnitte F.1.3 und F.1.4
F.3 Implementierungsphase
F.3
Implementierungsphase
F.3.4
Angestellte haben den vertraglichen Vereinbarungen ihrer Posten zugestimmt.
Om
Si
Zm
Wi
Ko
V
F.3.4.1 F.3.4.2
Wie wurde die Zustimmung eingeholt? Wurden die Angestellten auf die Sanktionen hingewiesen?
L
Die Zustimmung zu den vertraglichen Vereinbarungen erfolgt schriftlich. Obwohl bei Arbeitsverträgen die mündliche Vereinbarung auch bindend ist, so ist eine Zustimmung schriftlich zu erfassen, um nachträgliche gerichtliche Streitigkeiten zu verhindern. Sollte den Vereinbarungen nicht zugestimmt werden, so ist eine spätere Sanktion nicht möglich. Des Weiteren ist die Kontrolle, ob die Angestellten ihre Aufgaben tatsächlich kennen, nicht möglich.
#
Í
Eine schriftliche Zustimmung von den Angestellten einholen. Vereinbarungen klar und eindeutig formulieren. Für Verstöße gegen die Vereinbarungen klare Sanktionen definieren. Den Betroffenen die Sanktionen bekannt machen. Die Vereinbarungen sollten als Anhang der Arbeitsverträge gestaltet und vom Angestellten unterzeichnet werden. Diese Anhänge können ggf. erweitert und bekannt gegeben werden. Sollte kein Widerspruch erfolgen, ist die Anlage auch ohne weitere schriftliche Bestätigung gültig.
285
F Personelle Ebene
F.4
Betriebsphase F.4.1
Angestellte werden regelmäßig über die geltenden Regelungen informiert.
Om
Si
Zm
Wi
Ko
V
F.4.1.1 F.4.1.2 F.4.1.3
Wie werden die Angestellten informiert? Welche Stelle unterzeichnet die Regelungen? Wie ist eine Änderung nachvollziehbar?
L
Regelmäßige Informationen über die Regelungen und etwaige Änderungen lassen sich über verschiedene Kanäle verbreiten, z.B. über elektronische Medien oder in Schulungen. Werden Angestellte nicht über Regelungen informiert, so ist deren Umsetzung nicht möglich. Es kann zu erheblichen Schäden führen.
#
Í
286
Angestellte regelmäßig über die sie betreffenden Regelungen informieren. Einen Nachweis führen, welche Informationen bekannt gemacht wurden. Ein geeignetes Medium zur Information wählen. Für viele Unternehmen lohnt sich die Integration der Informationspflicht in ein schon vorhandenes Intranet. Sollte dies noch nicht vorhanden sein, können andere schon existierende Medien genutzt werden. Hier sollte der Fokus auf eine schnelle Verbreitung und eine Kontrollfunktion gelegt werden.
F.4 Betriebsphase
F.4
Betriebsphase
F.4.2
Sanktionen sind definiert.
Om
Si
Zm
Wi
Ko
V
F.4.2.1 F.4.2.2 F.4.2.3
Welche Sanktionen sind definiert? Welche Gesetze sind hierbei berücksichtigt worden? Wie wurden die Mitarbeiter darauf hingewiesen?
L
Für Verstöße gegen die Regelungen müssen Sanktionen definiert sein. Bei Angestellten können dies disziplinarische Maßnahmen arbeitsrechtlicher Natur sein (z.B. Abmahnung), bei Externen können die disziplinarischen Maßnahmen vertraglicher Natur sein (z.B. Vertragsstrafe). Werden keine Sanktionen definiert, so gibt es nach einem Sicherheitsvorfall keine Möglichkeit, eine Wiederholung auszuschließen.
#
Í
Sanktionen für Verstöße gegen Regelungen definieren. Sanktionen gesetzeskonform gestalten. Den Angestellten die Sanktionen bekannt machen. Sanktionen gegenüber Angestellten sollten mit juristischer Hilfe erstellt und mit dem Personalrat abgestimmt werden. Bei Vertragsstrafen ist eine Risikobetrachtung der möglichen Schäden bei Verstößen von Vorteil, um die entstehenden finanziellen Schäden in gewissem Maße abzudecken. Vergleiche: Betriebsverfassungsgesetz §77 ff.
287
F Personelle Ebene
F.4
Betriebsphase
F.4.3
Mitarbeiter sind ausreichend geschult.
Om
Si Wie Wie Wie Wie
Zm
Wi
Ko
V
F.4.3.1 F.4.3.2 F.4.3.3 F.4.3.4
wird eine Schulung anforderungsgerecht geplant? wird eine Schulung durchgeführt? werden die Schulungen besetzt? werden die Ergebnisse der Schulungen dokumentiert?
L
Mitarbeiter sind dann ausreichend geschult, wenn sie alle Anforderungen der Stellenbeschreibung und der daraus resultierenden Aufgaben erfüllen können. Unzureichend geschulte Angestellte können die an sie gestellten Anforderungen nicht oder nur teilweise erfüllen. Dies hat zur Folge, dass Aufgaben nicht korrekt erfüllt werden, was zu erheblichen Schäden im Unternehmensumfeld führen kann.
#
Í
288
Schulungen gemäß den Anforderungen an die Stelle des jeweiligen Beschäftigten planen. Schulungsinhalte in ein Schulungskonzept des Unternehmens eingliedern. Erhaltene Schulungen in der Personalakte dokumentieren. Die Schulungen sollten rollenbasiert den Stellenbeschreibungen entsprechen. Die jeweiligen Mitarbeiterschulungen können bei dedizierten Arbeitsplätzen auch mithilfe von eLearning-Angeboten umgesetzt werden. Eine Nachweisbarkeit sollte vorhanden sein, muss aber mit dem Personalrat abgestimmt werden. Dies dient zur Kontrolle der Befähigung der Beschäftigten, die zu besetzende Stelle sicherheitsgemäß auszufüllen. Vergleiche: BSI GSK M 3.5
F.5 Roll-Off
F.5
Roll-Off F.5.1
Die Verantwortlichkeiten für das Ausscheiden der Angestellten sind geregelt.
Om
Si
Zm
Wi
Ko
V
F.5.1.1 F.5.1.2
Wer ist für das Ausscheiden von Angestellten verantwortlich? Wie werden die einzelnen Verantwortlichkeiten dokumentiert?
L
Ein geregeltes Ausscheiden eines Angestellten ist durch einen geeigneten Prozess abgebildet. Verantwortlichkeiten können hier gut definiert werden. Sind keine Verantwortlichkeiten für das Ausscheiden eines Mitarbeiters geregelt, gibt es kein geregeltes Ausscheiden des Beschäftigten, es können noch nach dem Ausscheiden Zugriffe auf wichtige Informationen erfolgen. Nicht gesperrte Benutzerkonten können missbraucht werden. Zutrittsmittel können für dolose Handlungen missbraucht werden.
#
Zuordnung von Verantwortlichkeiten zu dem Ausscheidungsprozess definieren. Einen geeigneten Prozess etablieren.
Í
Ein geeigneter Prozess kann nach dem RACI-Modell4 erstellt werden. Sie können hier auch die Erfahrungen bei der Einstellung des Angestellten zur Rate ziehen.
4
Vergleiche: COBIT® - RACI-Modell
RACI: responsable, accountable, consulted, informed
289
F Personelle Ebene
F.5
Roll-Off
F.5.2
Alle organisationseigenen Wertgegenstände sind zurückgenommen worden.
Om
Si
Zm
Wi
Ko
V
F.5.2.1 F.5.2.2
Wie wird die Rücknahme protokolliert? Wie werden die Bestandsregister gepflegt?
L
Organisationseigene Wertgegenstände sind Betriebsaustattungen, die der Angestellte zur Verfügung gestellt bekommen hat. Auch alle Aufzeichnungen und Unterlagen, die Informationen über das Unternehmen und dessen Geschäftsprozesse und -abläufe enthalten, sind Werte im Sinne der GoIT. Werden nicht alle organisationseigenen Wertgegenstände zurückgenommen, so können Informationen gestohlen werden.
#
Einen geeigneten Prozess zur Rücknahme von organisationseigenen Werten etablieren. Die Rücknahme protokollieren. Die Verantwortlichkeiten sind gemäß der Anforderung F.4.1 zu befolgen. Zurückgenommene Wertgegenstände unverzüglich in die Bestandslisten einpflegen.
Í
Ein Laufzettel kann hier als Dokumentations- und Prozesshilfe dienen. Bei den zu fordernden Unterlagen ist es wichtig, eine Bestätigung des Angestellten einzuholen. Dies ermöglicht eine spätere Sanktion bei Verstößen über das Angestelltenverhältnis hinaus.
290
Vergleiche: BSI GSK M 2.13
Literaturhinweise Hinweis: Es liegt im Wesen des World Wide Web, dass die Informationsinhalte dynamisch sind. Aus diesem Grund kann nicht garantiert werden, dass die online verfügbaren Inhalte über die angegebenen Weblinks abrufbar sind. [BDSG09] Bundesministerium der Justiz: Bundesdatenschutzgesetz (BDSG). Bezug online, u.a. über http://www.gesetze-im-internet.de [BMI07]
Bundesministerium des Innern: Umsetzungsplan KRITIS. Bezug online über http://www.bmi.bund.de.
[BSI10]
Bundesamt für Sicherheit in der Informationstechnik (BSI): IT-GrundschutzKataloge und IT-Grundschutz-Standards. Bezug online über http://www.bsi.bund.de/
[BSI06]
Bundesamt für Sicherheit in der Informationstechnik: Integration und ITRevision von Netzübergängen. Bundesanzeiger-Verlag, 2006
[DIIR02]
Deutsches Institut für Interne Revision: Leitfaden zur Durchführung von Prüfungen der Informationsverarbeitung (Loseblattsammlung/CDROMs). Verlag Erich Schmidt, 2002-
[Haar04]
Tobias Haar, Sarah Schädler: Verbaselt. IT-Sicherheit zukünftig relevant für Kreditvergabe und -rückzahlung. In: iX, 2004 Heft 12, S. 99
[IDW]
Institut der Wirtschaftsprüfer in Deutschland (IDW): Prüfungsstandards (mehrere Veröffentlichungen). Bezug über http://shop.idw-verlag.de
[ISO09]
International Organization for Standardization (ISO): ISO/IEC 27001:2008-09. Bezug über http://www.iso.org. Deutsche Fassung erschienen im Beuth Verlag.
[Kam95]
Gerd F. Kamiske, Jörg-Peter Brauer: Qualitätsmanagement von A bis Z. Carl Hanser Verlag, 1995
291
Literaturhinweise
292
[MaRisk]
Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin, Hrsg): Mindestanforderungen an das Risikomanagement (MaRisk). Bezug online über http://www.bundesbank.de/download/bankenaufsicht/pdf/marisk/090814_rs.pdf
[Schr08]
Georg Schranner, Daniel Gläser: Nutzen der IT-Revision. In: Deutsches Institut für Interne Revision (Hrsg.): Interne Revision aktuell, 2008, S. 329-338.
[Sowa07]
Aleksandra Sowa: IT-Revision in der Bankenpraxis. In: Praxis der Wirtschaftsinformatik, 2007, Heft 254, S.82-93
[SOX02]
Congress of the United States of America: Sarbanes-Oxley Act of 2002. Bezug online über http://www.sec.gov/about/laws/soa2002.pdf
[VOI08]
Verband Organisations- und Informationssysteme (Hrsg.): PK-DML Prüfkriterien für Dokumentenmanagement- und Enterprise Content ManagementLösungen (2008). Bezug über www.voi.de
Register A Administratorauswahl 196 Applikationstests 238 Applikationsverwaltung 240 Architekturübersicht 90 Aufbewahrungsfrist 69, 272 Aufbewahrungspflicht 120 Auswirkungskategorie 45
B Basel II 76 Basis-Sicherheitscheck (BSC) 115 Benutzerverwaltung 243 Berechtigungskonzept 97 Bestandsverzeichnis 179 Betriebsanforderungen 239 Betriebsmittelentsorgung 178, 248 Bewertungsbereich 122 Branchenvorschrift 76 BSI Grundschutz 105 BSI-Standard 106 Bugtracker 236 Bundesdatenschutzgesetz 67, 105
C CobIT 125 Aktueller Reifegrad 128 Erreichte Reifegradstufe 128 Kontrollkreislauf 133
Kontrollziele 126 Outcome Measure 132 Performance Indicators 132 Reifegradmodell 125 Reifegradstufen 126 Zielsystem 131 Corporate Governance 66
D Datenänderung 270, 271 Datenarchivierung 101 Datenausgabe 100 Dateneingabe 100 Datenfluss 91 Datenimplementierung 261 Datenintegrität 94 Datenklassifikation 233 Datenkonsistenz 253 Datenkritikalität 255 Datenlöschung 103, 274 Datenmigration 102 Datenqualität 254 Datenschutz 11, 105 Datenschutzerklärung 266 Datensemantik 269 Datensicherung 101 Datenträgervernichtung 275 Datentransfer 101 Datenvalidierung 263
293
Register Datenverarbeitung 100 Dokumentenmanagement 120
E Entsorgungsnachweis 178 Entwicklungsdokumentation 236 Entwicklungsumgebung 256 Ergänzende Sicherheitsanalyse 116
F Fachausschuss für Informationstechnologie 55 FAIT siehe Fachausschuss für Informationstechnologie Feedbackbogen 51 Feststellung 44 Fokus 154 Funktionstest 211
G GDPdU siehe Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen Gebäudeplanung 160 Gefährdungskatalog 106 Geheimschutzbetreuung 281 Geheimschutzvereinbarung 280 Gesetz für IT-Revision relevant 62 GoBS 74 siehe auch Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme GoIT-Prüfungsaspekt 156 Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme 55 zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU) 55, 73
H Handelsbuch 64 Handelsgesetzbuch 63
I IDW siehe Institut der Wirtschaftsprüfer in Deutschland IKS siehe Internes Kontrollsystem
294
Infrastrukturplanung 234 Institut der Wirtschaftsprüfer in Deutschland 55 Integrationstest 211 Internes Kontrollsystem 6, 54, 89, 133 ISMS 77 ISO 27001 59 IT-Compliance 10 IT-Controlling 9 IT-Governance 10 IT-Lebenszyklusphase 155 IT-Lösung 80 IT-Qualitätsmanagement 10 IT-Revision 3, 6, 8 IT-Revisionsprüfung 25 IT-Sicherheitsmanagement 10 IT-Strategie 85 IT-Strukturierungsmodell 152 IT-Verbund 107 IT-Verfahren 79 Basisverfahren 79 fachbezogen 79 ITIL 240
J Jahresabschlussprüfung 54
K Kapazitätsanforderung 206, 210 Kapazitätsmanagement 187 KonTraG 66 Kontrollsystem, internes 6, 89, 133
L Lastenheft 231 Lasttest 210 Leistungsanforderung 206, 210 Leitungsplanung 163 Leitungsredundanz 164 Lizenzvereinbarung 212, 225 Löschberechtigung 273 Lösung sachlogische 89 technische 90
Register
M MaRisk 77 Maßnahme 47 Empfehlungen 7 Maßnahmenkatalog 107 Migrationsplanung 246 Migrationsprozess 245 Mitarbeiterschulung 288 Modellierung 114 Monitoring 194, 217
N Netzdokumentation 189 Netzkopplung 186 Netzprotokollierung 192 Netzrealisierungsplan 189 Netzsteuerung 188 Netzvertrag 190 Netzwerkrealisierungsplan 185 Netzwerksegmentierung 182 Notfallmaßnahme 175, 198 Notfallübung 176, 199
P PDCA-Modell 107 PK-DML 122 Programmidentität 93 Progressive Prüfung 74 Protokoll 24 Protokollauswertung 193 Protokollierung 267 Prüfprogramm Durchführung 54 Entwicklung 54 Prüfung progressive 74 retrograde 74 risikoorientierte 5 Prüfungsbericht 43 Prüfungsfrage 38 Prüfungsfragmentierung 81 Prüfungshandlung formelle 40
materielle 40 Prüfungsmethodik 26 Prüfungsplanung 25 Prüfungsprogramm 26
Q Quellcodesicherung 237
R RACI-Modell 278 Rahmenbedingung des Gesetzgebers 120 Raumdeklaration 162 Ressourcenfreigabe 249 Ressourcenplanung 232 Retrograde Prüfung 74 Revisionsbereich 8 Revisionsbericht siehe Prüfungsbericht Revisionsprüfung 5 Revisionstool Betriebssystemprüfung 147 Checklisten 142 Datenprüfung 147 Dokumentenerstellung 144 Maßnahmenempfehlungen 143 Maßnahmenverfolgung 146 Projektcontrolling 144 prüfend 136 prüfungsbegleitend 136 Prüfungshandbuch 141 Prüfungsplanung 138 Ressourcenzuordnung 140 Revisor 13 Richtlinie Definition 71 IDW 72 Risiko 5 Risikoanalyse 241 Risikoorientierte Prüfung 5 Rollback 220
S Sachlogische Lösung 89 Sanktion 287
295
Register Schadensklasse 112 Schnittstelle 91 Schutzbedarf 204 Schutzbedarfsfeststellung 113 Schutzbedarfskategorie 112 Sensibilisierung 283 Sicherheitsanalyse, ergänzende 116 Sicherheitsmaßnahmen 241 Sicherheitsrahmenkonzept 117 Sicherheitsrichtlinie 4, 282 Sicherheitsstandard 22 Sicherheitsüberprüfung 281 Sicherheitszone 170 Snapshot 24 Solvency II 78 Speicherort 260 Stellenanforderung 280 Stellenbeschreibung 279 Strukturanalyse 108 System, virtuelles 111 Systemdimensionierung 207 Systemdokumentation 218 Systemfunktion 219, 224 Systemhärtung 209 System-Recovery 214
T Technische Lösung 90 Terminplanung 28 Testdaten 257 Testfall 258 Testumgebung 244, 256
296
U Umgebungsbedrohung 168 Update 215
V VDI-Richtlinie 161 Verfahrensdaten 99 Verfahrensdokumentation 87, 95, 123 Verifikation 41 Verschlüsselungsverfahren 242 Vertrag 5 Vertrauenswürdigkeit 284 Vertraulichkeitserklärung 266 Virtuelles System 111 V-Model XT 235 Vollständigkeitserklärung 50
W Widerstand 39 Wirtschaftsprüfer 53 Wirtschaftsprüferordnung 53
Z Zugangsschutz 184 Zugriffskontrolle 216 Zugriffsschutz 216 Zutrittskontrolle 167, 169 Zutrittsschutz 173
Alles für IT-Projektmanager
Tiemeyer (Hrsg.) Handbuch IT-Projektmanagement Vorgehensmodelle, Managementinstrumente, Good Practices 714 Seiten. ISBN 978-3-446-42192-9
Die deutliche Mehrheit der IT-Projekte sprengt nach wie vor den Kosten- oder Zeitrahmen oder wird abgebrochen. Wer seine IT-Projekte erfolgreich abschließen will, muss ein breites Praxiswissen haben. Das reicht von Kenntnissen darüber, wie Projekte geplant, beantragt und gestartet werden, über die Fähigkeit, Teams zu bilden und zu führen bis hin zu komplexen Management-Aufgaben wie Risikomanagement, Stakeholdermanagement, Qualitätsmanagement, Projekt-Marketing und mehr. In diesem Handbuch haben 16 in der Wirtschaft und an Hochschulen tätige Autoren ihre vielfältigen Erfahrungen zusammengefasst. Sie geben Ihnen einen vertieften Einblick in die für die Projektarbeit notwendigen Methoden, Instrumente und Führungstechniken. Egal, mit welcher Art von IT-Projekt Sie sich befassen, mit diesem Handbuch können Sie sich alle wesentlichen Teilgebiete und Prozesse im IT-Projektmanagement gezielt erschließen. Die zahlreichen Tipps und Beispiele aus der Praxis versetzen Sie in die Lage, IT-Projekte erfolgreich zu starten, zu leiten und zu steuern.
Mehr Informationen zu diesem Buch und zu unserem Programm unter www.hanser.de/computer
Alles im Griff.
Tiemeyer (Hrsg.) Handbuch IT-Management Konzepte, Methoden, Lösungen und Arbeitshilfen für die Praxis 3., überarbeitete und erweiterte Auflage 739 Seiten ISBN 978-3-446-41842-4
Informationstechnik (IT) hat inzwischen so gut wie alle Geschäftsbereiche durchdrungen und kann über Erfolg oder Misserfolg der Unternehmenstätigkeit entscheiden. Deshalb nehmen IT-Manager in Unternehmen eine ganz zentrale Rolle ein. Damit IT-Manager für die Praxis gerüstet sind, stellt dieses Handbuch umfassendes, aktuelles und in der Praxis unverzichtbares Wissen aus allen Bereichen des IT-Managements zur Verfügung. Die Autoren, allesamt Experten auf ihrem Gebiet, vermitteln die Fähigkeit zur Entwicklung von IT-Strategien, technisches Know-How und fundiertes Wissen zu Managementthemen und Führungsaufgaben.
Mehr Informationen zu diesem Buch und zu unserem Programm unter www.hanser.de/computer
eBooks zum sofortigen Download www.ciando.com
find ou t!
tf e rn t. e in e n K li c k e n r u n t is w o H w Kno ad beziehen. lo n w o D r e p rt n Sie sofo lt li c h . - e B o o k s könne it e lw e is e e rh ä p a k r e d o z n a che. - e B o o k s s in d g a b le Vo ll te x ts u rt fo m o k e in e - e B o o k s b ie te n
DAS AKTUELLE PRAXISBUCH FÜR IT-REVISOREN // ■ Erfahren Sie, welche Aufgaben die IT-Revision hat und wie sie am besten durchgeführt werden. ■ Nutzen Sie die konkret formulierten Anforderungen an die ordnungsgemäße IT als Grundlage für Ihre IT-Revision.
IT-REVISION IN DER PRAXIS // Die Ordnungsmäßigkeit der Informationsverarbeitung wird im Umfeld von Corporate Governance, IT-Governance, SOX-Compliance und Basel II u.a. immer wichtiger. Entsprechend wächst auch die Bedeutung der ITRevision stetig. Doch häufig kennen diejenigen, die die Ordnungsmäßigkeit sicherstellen müssen, die Anforderungen nicht hinreichend. Das liegt auch daran, dass der Gesetzgeber die Bestimmungen bewusst nicht konkretisiert. Dieses Buch führt Sie in die Aufgaben und die Durchführung der IT-Revision ein. Dazu erhalten Sie im ersten Teil einen fundierten Überblick darüber, was IT-Revision eigentlich ist, welche Gesetze, Richtlinien und Vorschriften dafür relevant sind, wie sie durchgeführt wird und wie das Prüfungsverfahren dokumentiert wird. Der zweite Teil des Buches besteht aus den Grundsätzen einer ordnungsgemäßen Informationstechnik (GoIT), die in Form von Anforderungen formuliert sind. Sie liefern Ihnen einen Anforderungskatalog, der als Basis für Ihre IT-Revision dient. Daraus können Sie eine Checkliste erstellen, die ganz individuell auf Ihre konkrete Prüfungssituation abgestimmt ist.
AUS DEM INHALT // Teil 1: Grundlagen der IT-Revision // Prüfungsorganisation und Vorbereitung // Zusammenspiel mit externen Wirtschaftsprüfern // Relevante Prüfungsgrundlagen // Prüfung von IT-Verfahren // Besondere Prüfungsgebiete // CobITPrüfungen // Tools zur Prüfungsunterstützung // Teil 2: Grundsätze für eine ordnungsgemäße Informationstechnik, gegliedert in die Schichten Physikalische Ebene, Netzwerkebene, Systemebene, Applikationsebene, Inhaltsebene und Personelle Ebene //
Klaus SCHMIDT ist Geschäftsführer der Innomenta GmbH & Co. KG, die Unternehmen in IT-Themen an der Schnittstelle zwischen Management und Technik (IT-Revision, Security Management, Identity Management) unterstützt. Dirk BRAND ist leitender Berater bei der SILA Consulting GmbH mit den Schwerpunkten IT-Revision und Informationssicherheitsmanagement nach nationalen und internationalen Standards. www.hanser.de/computer € 49,90 [D] | € 51,30 [A] ISBN 978-3-446-41706-9
IT-Revisoren, Interne Revisoren, Wirtschaftsprüfer, CIOs
9
783446 417069
Systemvoraussetzungen für eBook-inside: Internet-Verbindung und eBookreader Adobe Digital Editions.
■ Profitieren Sie von der Revisionserfahrung der Autoren. ■ Im Internet: Der Anforderungskatalog für die IT-Revision als Excel-Datei.
