Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

08.05.1987 - 

Unterstützung der Entwicklungs-, Informations- und Betriebsfunktionen:

DV-Revision agiert mit phasenabhängigen Prüfverfahren

Die Revision ganz allgemein ist immer stärker mit den Problemen der DV-Sicherheit konfrontiert. Für die Fachwelt hat es nicht erst des Falles der verschwundenen VW-Millionen bedurft, um den hohen Stellenwert von Sicherheitsmaßnahmen aller Art speziell im DV-Sektor anzuerkennen. Die tragende Rolle der Revision ist unbestritten; Diskussionen gibt es darüber, mit welchen Werkzeugen sie ihre schwierige Arbeit erleichtern kann. Peter Küchler von der SCS, Essen, hat in der Sicherheits-Fachpublikation KES* einen Überblick über die "Software für den Revisor" veröffentlicht, den wir hier leicht gekürzt wiedergeben.

Von - unvermeidbarem - Irrtum abgesehen, wird die DV-Sicherheit unter anderem zu 66 Prozent durch technische Defekte, zu 51 Prozent durch Nachlässigkeit der Mitarbeiter und zu 5,5 Prozent durch Manipulation von Daten oder Programmen beeinträchtigt. Dieser Bereich wird einerseits, wie im folgenden ausgeführt wird, durch Komponenten von Standard-Software revisionsseitig unterstützt, andererseits jedoch durch Versicherungen selten abgedeckt (14 Prozent Computer-Mißbrauchsversicherung und 14 Prozent Folgekostenversicherung, im übrigen werden jedoch mehr dingliche Verluste versichert).

Schutz wird in Sicherheitskonzepten gesucht, die sich für eine maschinelle Unterstützung geradezu anbieten, wenn man an die folgenden Nennungen denkt:

- Paßworte 93 Prozent

- Benutzer-Identifikation 85 Prozent

- kontrollierte Zugriffsberechtigung 77 Prozent

- Programmfreigabeverfahren 62 Prozent

- Protokollierung von Zugriffen 54 Prozent

- Software zur Ablaufsicherung 39 Prozent

- Maßnahmen gegen unberechtigten Zugriff 30 Prozent

- Klassifizierung von Daten und Programmen 30 Prozent

- Sicherheits-Codes 28 Prozent

Diese Komponenten werden jedoch häufig unzureichend in Maßnahmen umgesetzt, wenn man die aus Abbildung 1 ersichtliche Verteilung betrachtet:

Durch die Komplexität derzeitiger DV-Anwendungen (siehe Abbildung 2) wachsen die Schwierigkeiten für eine DV-Revision. Somit beschränkt sich die folgende Diskussion auf mögliche System-Software-Komponenten, die lokal die Revision der Entwicklungs-, Informations- und Betriebsfunktionen (siehe Abbildung 3) der DV unterstützen.

Die Aufgabengebiete der DV-Revision lassen sich allgemein aus Abbildung 4 ablesen.

Die allgemeinen Prüfkriterien der DV-Revision sind namentlich identisch mit denen der üblichen internen Revision, inhaltlich jedoch im Hinblick auf die DV zu interpretieren:

- Funktionsfähigkeit: richtige, vollständige, termingerechte Ergebnisse produzieren,

- Sicherheit: Fehler, Störungen und Mißbrauch verhindern oder in ihren Auswirkungen beschränken,

- Ordnungsmäßigkeit: Vorschriften und Interessen wahren: Nachvollziehbarkeit und Protokollierung sicherstellen und

- Wirtschaftlichkeit: im üblichen ökonomischen Sinn beachten.

In der DV sind vergleichbare Phasenmodelle für die Entwicklung allgemein gebräuchlich, wobei die DV-Revision sinnvollerweise mit phasenabhängig unterschiedlichen Prüfverfahren agiert (siehe Abbildungen 5 und 6):

Die folgende Beschreibung eines Szenarios wünschenswerter, benötigter Funktionalität, um den gestellten Anforderungen Rechnung zu tragen, betrifft zunächst die Revision der Anwendungsentwicklung.

Finanzierungsrechnungen und -modelle sowie Bestimmungen des "Return of Investment" werden benötigt, um die Wirtschaftlichkeitsbetrachtungen zur Projektgenehmigung nachzurechnen, eine Verifikation ist damit leider nicht verbunden oder impliziert, da sie eine inhaltliche Evaluation der Argumentation voraussetzt.

Spezifikationssprachen könnten eine maschinelle Überprüfbarkeit eines Pflichtenhefts im Hinblick auf Vollständigkeit und Widerspruchsfreiheit ermöglichen. Ähnlich verhält es sich mit Beschreibungssprachen für Datenstruktur-, Funktions- und Kommunikationsanalyse, die allmählich am Markt verfügbar werden. (Zur Zeit sind solche Prüfungen nur als inhaltliche Prüfungen von Vorgaben und Phasenergebnissen möglich, die personell aufwendig und mit einer hohen Fehlerquote behaftet sind.) In der Zukunft sind auch Expertensysteme vorstellbar, die diese bislang noch durch Kreativität und Kommunikation geprägten Phasen der Projektentwicklung stärker unterstützen könnten.

Die maschinelle Unterstützung eines Phasenmodells der Projektabwicklung sollte von der Vorgabe her den Systementwurf (welche Module tun was?), den Modulentwurf (was tut ein Modul wie?) und die dazwischenliegende Schnittstellenproblematik (liefert der Aufrufer alle Daten in einer Art und Weise, die der Aufgerufene erwartet?) sichern. Angebotene und verfügbare Hilfsmittel dazu findet man unter den Stichworten Entwurfssprachen und Pseudocode. Je nach der verwendeten Umgebung lassen sich daraus eventuell sogar ablauffähige Programme in Programmiersprachen der dritten Generation erzeugen.

Ein anderes bekanntes Hilfsmittel, das in diesem Umfeld schon seit langem die Entwicklung phasenübergreifend unterstützt, sind Entscheidungstabellen mit den entsprechenden Generatoren. Eventuell sind sie sogar in ein maschinell gestütztes Phasenmodell zur Entwicklung eingebunden.

Derartige Unterstützungen zur Abwicklung nach Phasenmodellen führen den Entwickler im allgemeinen über eine begleitende Dokumentation. Dadurch wird zwar die Dokumentation nicht automatisch erstellt (was man für derartig kreative Aufgaben auch nicht erwarten kann), aber einer menschlich naheliegenden Unterlassung wird durch Erinnerung vorgebeugt.

In diesem Zusammenhang sei auch auf die Möglichkeit hingewiesen, daß zukünftig normierte Programmiersprachen, wie zum Beispiel ADA, im Umfeld ihrer Normierung nach Syntax und Semantik gleichzeitig weitreichende Standardfunktionen und außerdem komplette Entwicklungsumgebungen mit bereitstellen, die dann vorteilhafterweise auch gleichzeitig herstellerunabhängig sind.

Eine weitere Möglichkeit, die spätere Nachvollziehbarkeit der Programme zu verbessern, besteht in der simplen Nutzung installationseinheitlicher Programmrahmen, die einerseits die vorhandenen Erfahrungen langfristig konservieren und andererseits einen Beitrag zur egolosen Programmierung leisten. Eine technische Verfeinerung dieser Vorgehensweise liegt in der Verwendung von Transaktions-Entwicklungs-Tools, die Transaktionen in bestimmte funktionale Bausteine zerlegen und normierte Schnittstellen zu den DB-/DC-Umgebungen der jeweiligen Hersteller bieten.

Ansatzweise lassen sich frühe Design-Überlegungen zukunftsträchtig in die Anwendungsentwicklung einbinden, indem rechtzeitig Daten(struktur)beschreibungssprachen einerseits als Kommunikationsmittel in der Spezifikation und andererseits als Dokumentation und Eingabe für die maschinelle Ableitung von Datenbank- und -satz-Beschreibungen verwendet werden.

Die Compiler und/oder Interpreter für die höheren Programmiersprachen können nach erfolgreich überstandener Syntaxprüfung vielfältig semantisch wirken beziehungsweise eingreifen:

- Compiler- beziehungsweise maschinenabhängig kann grundsätzlich das Erzeugen von selbstmodifizierenden Programmen unterbunden werden.

- Jegliche Art von Defaults erscheint in ihrem Nutzen für die Entwickler fragwürdig, da dabei der Zusammenhang zwischen dem Willen menschlichen Tuns und den maschinell resultierenden Folgen dramatisch aufgeweicht wird. Man sollte versuchen, für Revisionszwecke solche Defaults auszuschalten beziehungsweise zumindest die Umwandlungen auf entsprechende Hinweise genauestens zu überprüfen.

- Durch unbedingte Sprünge können Teile des Programms eventuell nie zur Ausführung gelangen. Da normalerweise niemand Programmteile erstellt, die beabsichtigterweise nicht durchlaufen werden sollen, sind entsprechende Hinweise des Compilers/Interpreters notwendig, um auf vermutlich falsche Sprünge aufmerksam zu machen. Ähnliche Situationen sind aus bedingten Sprüngen herleitbar, die durch statische Analyse auf die entscheidbare Auswertung logischer Ausdrücke zurückzuführen sind. Auch Sie könnten erkannt werden.

- Das umgekehrte Problem stellt sich mit Programmschleifen, die im Sinne statischer Analyse niemals beendet werden. Jedoch sind dabei schon (meist technische) Notwendigkeiten denkbar, die derartige Programmierungen angemessen erscheinen lassen; sie führen auf die Notwendigkeit der wesentlich schwierigeren dynamischen Programmanalyse.

- Auch die Verwendung bestimmter (schwer nachzuvollziehender oder mißverständlicher) Sprachelemente behindert eventuell ein Nachvollziehen des Programms (Schreibtischtest, Inspection); zum Beispiel Perform Until in seiner (Cobol-)Semantik und der dadurch notwendigen Vorbesetzung der Endebedingung oder Alter wegen seiner dynamischen Wirkung. Solche Konstrukte können verboten werden.

- Der Compiler bietet eventuell die Möglichkeit, die syntaktisch als Schachtelung erkannten Konstrukte entsprechend visualisiert darzustellen, auch wenn der vorliegende Quellencode nicht dieser Visualisierung genügt.

Verbreitete Meinung ist in diesem Umfeld, daß die Revision erst nach (zumindest Modul-)getesteten Programmen aktiv werden sollte. Mir liegen jedoch nach eigenen Untersuchungen Fakten vor, die dafür sprechen, daß eine revisionsartige Kontrolle sehr effizient schon nach dem Stadium des fehlerfreien Compilierens ansetzen kann und sollte. Für die notwendigen Aktivitäten des Schreibtischtests und des Author-Reader-Cycle über dem Programm ist es jedoch egal, ob diese Tätigkeit von der DV-Revision oder geplant im Umfeld der Realisierungsaktivitäten durchgeführt wird.

Bei den Ablauftests wird das Programm in möglichst vielen Anweisungen (Anweisungstest) durchlaufen, man gewinnt damit einen lokalen Eindruck von der korrekten Ausführbarkeit der einzelnen Anweisungen (was in dem dynamischen Prozeß, den das Programm beschreibt, noch nicht sonderlich viel aussagt). Durch Debugger sollte dieser Test im Ablauf unterstützt werden, indem einzelne Variablenwerte angezeigt werden und zur weiteren Durchführung verändert werden können. Dabei sollte auch ein über mehrere Testläufe konsistenter Nachweis der getesteten Anweisungen erfolgen.

Ähnliche Forderungen bestehen, wenn die Zweige eines Programms (Zweigtest) getestet werden. Durch die Einbeziehung des Kontextes der einzelnen Anweisungen wird hierbei natürlich eine wesentlich größere Sicherheit im Test erreicht.

Wiederum Gleiches gilt für den Test über alle den Kontrollfluß tangierenden Anweisungen (Pfadtest), der jedoch in der Praxis nicht mehr realistisch durchführbar wird (wenn man sich die mögliche Anzahl verschiedener Pfade eines "normal großen" Programms vor Augen führt).

Bei Datentests wird das Programm mit verschiedenen Eingaben in seinen Reaktionen getestet. Hierbei lassen sich durch Testdatengeneratoren die Daten (zufällig und gleichzeitig reproduzierbar) erzeugen und durch Systemhilfsmittel, die die Eingaben von externen Geräten (zum Beispiel Terminals) simulieren, reproduzierbare Tests konstruieren.

Wenn auch die Ausgaben entsprechend maschinenlesbar protokolliert werden, hat man hiermit auch eine gute Basis für zukünftige Regressionstests nach späteren Programmänderungen.

An diese Überlegungen schließen sich Simulationen zum Massen- und/oder Lasttest an.

Die Beweisbarkeit von Programmen ist wiederum ein kreativ und theoretisch geprägtes Verfahren, das im praktischen Einsatz keine Rolle spielt und zudem nach dem jetzigen Stand der Technik nicht von DV-Verfahren unterstützt wird (werden kann).

Ein Test der Handhabungsvorschriften und Arbeitsanweisungen für den Anwender und auch den RZ-Betrieb (Operating) beinhaltet den Vergleich der Funktionalität des erstellten Systems mit der in der Vorgabe seitens der Anwender beschriebenen. Da diese Vorgaben nicht maschinell be-/verarbeitbar waren, ist dies folglich auch hier ausgeschlossen.

Wesentlich für die späteren Prüfmöglichkeiten ist eine durchgängige Dokumentation der Testvorgaben, -strategien, -ergebnisse und -auswertungen von Anfang an. Alle technischen Möglichkeiten sollten hier ausgeschöpft werden, auch wenn die DV aus gegebenen technischen Notwendigkeiten nur als Textspeicher verwendet wird.

Eine maschinengeführte Dokumentation aller Tests erleichtert den Einsatz der DV-Revision und sollte automatisch mitgeführt werden, um menschliche Unterlassungen in diesen oft streßbelasteten Phasen am Ende eines Projekts auszuschalten.

Alle weitergehenden Revisionsbetrachtungen wenden sich nun dem RZ-Betrieb (der Produktion) zu, den im folgenden behandelt werden soll.

Dabei soll die Revision der verwendeten Hardware und System-Software aus unseren Betrachtungen ausgeklammert werden, da die DV-Revision sie eigentlich nicht beeinflussen kann; außer durch Beeinflussung der Beschaffungsmaßnahme. Im allgemeinen bestehen bei den handelsüblichen Produkten nur unwesentliche Abweichungen, so daß dadurch kein wesentlicher Revisionsbeitrag gewonnen wird; Ausnahmen davon bestehen zum Beispiel bei der Notwendigkeit des Einsatzes von fehlertoleranten Rechnern, wobei die Angebotspalette wesentlich eingeschränkt wird.

Die System-Software hat aber Bedeutung, soweit sie zu Zwecken der Revision von Applikationen verwendet werden kann beziehungsweise diese unterstützt. Vorrangig sind durch System-Software folgende Aspekte (positiv) beeinflußbar:

- Systemintegrität,

das heißt sicherzustellen, daß das DV-System dem Versuch widersteht, seine Kontrollen durch Mißbrauch oder Manipulation zu umgehen;

- Zugriffskontrolle,

das heißt die Beschränkung der Benutzung der Systemressourcen auf dazu berechtigte Personen und weiterhin deren Beschränkung auf gerade die benötigten Ressourcen ("need to know");

- Schutz der Datenübertragung,

das heißt das Verschlüsseln von sensitiven Daten in Bereichen, wo eine physische Zugriffskontrolle nicht gewährleistet werden kann.

Zu dem Ziel, die Systemintegrität zu gewährleisten, tragen die folgenden Funktionalitäten bei:

- Die virtuellen Maschinen und/oder Speicherbereiche müssen benutzerbezogen isoliert werden.

- Das System muß den gegenseitigen Zugriff der Benutzer auf die gleichen realen Speicherbereiche verhindern beziehungsweise besonders autorisieren. Dahinter verbergen sich auch unterschiedliche Sicherheitsaspekte von weiteren Systemkomponenten; zum Beispiel gilt ein DC-System, dem alle Transaktionen als Unterprogramme zugeordnet werden, als ein Nutzer in diesem Sinne, so daß der aus der Anwendung her erwünschte Schutz verschiedener Transaktionen nur durch gleichzeitige Nutzung mehrerer derartiger DC-Systeme oder durch einen vertieften Schutzmechanismus innerhalb des DC-Systems erreicht werden kann.

- Exemplare von Systemprogrammen, die Zugriffe manipulieren, müssen besonderen systemseitigen Schutz genießen, zum Beispiel werden über derartige Möglichkeiten Computerviren in Systeme eingeschleust, indem es Programmen ermöglicht wird, weitere und/oder andere Exemplare als Lademodule abzulegen.

Zu dem Ziel, die Zugriffskontrolle zu gewährleisten, tragen die folgenden Funktionalitäten bei:

- Jeder potentielle Benutzer des Systems sollte eindeutig identifizierbar sein (Benutzeridentifikation).

- Jeder Benutzer sollte verifizierbar sein (Paßwort). Damit wird in einer weiteren Stufe die verwendete Benutzeridentifikation überprüft.

- Diese Sicherheitsstufen können für spezielle Benutzer (wie Operator, Systemverwaltung) noch durch weitere Identifikationsmittel ergänzt werden (zum Beispiel Identifikationskarte, Schlüsselschalter).

- Jede Systemressource, als da sind:

* Terminals,

* Datenübertragungswege,

* Daten,

* Transaktionen/Anwendungsfunktionen (Teilhaberbetrieb),

* Systemfunktionen/Anwendungsfunktionen (Teilnehmerbetrieb), muß als entsprechend schutzbedürftig klassifizierbar sein.

- Potientielle Ressourcen-Anforderungen von Benutzern müssen beschrieben und vor ihrer Nutzung überprüft werden. Dabei sollten auch Kombinationen komplexer Art darstellbar sein, zum Beispiel Nutzung einer Transaktion von einem bestimmten Terminal nur innerhalb eines gewissen Zeitrasters durch gewisse Benutzer(-gruppen).

Um die Datenübertragung zu schützen, wird im allgemeinen die Kryptographie verwendet, dabei bestehen praktikable Systeme meist aus einem Algorithmus (einem Regelwerk, nach dem die Ver- beziehungsweise Entschlüsselung der Daten zu erfolgen hat) und einem (kryptographischen) Schlüssel, der die Abbildung der Schlüsselung in beiden Richtungen eindeutig steuert. Diesen Überlegungen folgt auch der DES (Data Encryption Standard) des U.S. National Bureau of Standards, der üblicherweise in der DV verwendet wird. Die Schlüsselung kann hard- oder softwaremäßig vorgenommen werden. (Hardwaremäßig bietet sich für die Datenübertragung über entfernte Leitungen an, softwaremäßig für die maschineninterne Speicherung sensitiver Daten, wie Paßwörter etc.) Die Systeme sollten dafür sorgen, daß sie und ihre Daten geschützt sind und die softwaremäßige Abwicklung in einer ansonsten leeren Maschinenumgebung stattfindet.

Übergreifend stellt die Revision weitere Anforderungen an die Systemkomponenten, die über die reine Funktionalität zur Sicherung hinausgehen:

- Alle diese Komponenten müssen leicht zu verwalten sein (zum Beispiel Eintrag weiterer Benutzer, Erinnerung an einen periodischen Wechsel des Paßworts, Plausibilisierung von Paßwörtern etc.).

- Der Umfang der anzuwendenden Sicherungsmechanismen muß an das Schutzbedürfnis der jeweiligen Installation anpaßbar sein.

- Verstöße gegen diese Schutzmechanismen sind zu protokollieren und in geeigneter Weise der Systemverwaltung und der DV-Revision zugänglich zu machen. Darüber hinaus sollten diese Protokolle auch Auskunft über das normale, nicht gegen Sicherheitsanforderungen verstoßende Verhalten von Benutzern geben.

- Statistiken und Übersichten über den Schutz der Ressourcen und die Nutzungsmöglichkeiten der potentiellen Benutzer sollten verfügbar sein.

- Ernste Verstöße sollten im laufenden Betrieb bestimmten Verwaltern (auf speziellen Terminals) direkt gemeldet werden können.

Weitere Komponenten der System-Software können zum allgemeinen Nutzen beitragen, der im weiteren Sinne auch der DV-Revision zugute kommt:

- DB/DC-Systeme sichern die entwicklungsseitig notwendige und hinreichende logische Sicht der Daten, womit bewußten oder unbewußten Manipulationen vorgebeugt wird. In der Produktion tragen sie zum vereinfachten Umgang bei, indem Start und Wiederanlaufverfahren sowie Datensicherungen durch Hilfsprogramme der Hersteller leicht handhabbar sind. In der DC-Umgebung ergeben sich eventuell Vereinfachungen durch Unterstützung des Transaktionslogging.

- Eine wichtige Aussage für die DV-Revision ist die Kenntnis der jeweils aktuell für die Produktion verwendete Version eines Programms, Versionenkontrollen (in der Entwicklung) und auch für Lademodule sollten darüber Auskunft geben können.

- Jobablaufsteuerungen sichern die Produktion vor menschlichem Versagen und bieten je nach ihrem Funktionsumfang auch komplexe Möglichkeiten der bedingten Ablaufsteuerung einschließlich der Aktivierung von eventuell notwendigen Rekonstruktionen durch entsprechende Jobs im Fehlerfall. Damit wird auch eine Verschleppung eines Problems in nachfolgende Produktionen verhindert. Darüber hinaus kann die Eingabe zur Jobablaufsteuerung eine ansonsten benötigte Dokumentation der Handhabung für den RZ-Betrieb ersetzen, und zwar in dem Sinne, daß verbale Dokumentation durch maschinell verarbeitbare und damit überprüfbare ersetzt wird (was man grundsätzlich anstreben sollte).

- Abschließend sei auch der Vollständigkeit halber das Accounting erwähnt. Es handelt sich dabei um eine lange Zeit und weitverbreitete Komponente, die jedoch in den heutigen komplexen Online-Umgebungen auch wieder neuen technischen Anforderungen gegenübersteht. (Die Abrechnung von Batch-Ressourcen ist eben wesentlich einfacher als eine plausible Zuordnung des Verbrauchs im Dialog.) Je nach der System-Philosophie der DC-Systeme werden hierbei sogar anwendungsspezifische Vereinbarungen zur Umlage der verbrauchten Betriebsmittel notwendig.

Die in Abbildung 7 angegebenen Funktionalitäten referieren abkürzend die ausführliche Beschreibung im Abschnitt "Die benötigte Funktionalität"; dabei sind mögliche System-Software-Komponenten unter anderem:

a virtuelle Maschinen-/Speicherkonzeptionen,

b Sprachübersetzer (Compiler/Interpreter),

c Datenbank-System,

d Data-Dictionary/Datenbeschreibungssprachen,

e Datenkommunikations-Systeme,

f Testwerkzeuge,

g kryptographische Systeme,

h Monitor-Systeme,

i Zugriffsüberwachungs-Systeme,

j Basis-/Standard-Software,

k anwendungsspezifische Erweiterungen.

Diese Komponenten haben bei jedem Hersteller verschiedene Namen, sind jedoch durch die dargestellten Szenarien aus den jeweiligen Produktbeschreibungen leicht zu identifizieren.

Dabei ist Abbildung 6 wie folgt zu interpretieren:

- Falls eine Funktionalität durch die mit "a" - "j" benannte System-Software-Komponente erbracht werden könnte, ist der entsprechende Kreuzungspunkt in der Tabelle mit dem entsprechenden Buchstaben markiert.

- Alle Funktionalitäten, die anwendungsspezifisch sinnvoll machbar sind, wurden mit "k" klassifiziert (man wird zum Beispiel sicherlich nicht eine Spezifikationssprache oder einen Compiler als Anwendung entwickeln).

Die hier vorgenommene Beurteilung beruht auf den kumulierten Möglichkeiten real verfügbarer System-Software der Hardware-Hersteller. Darüber hinausgehende Möglichkeiten der Basis-Software von Fremdanbietern (Softwarehäusern) würde die Überdeckung der gewünschten Funktionalität sicherlich noch (wesentlich) verbessern.

Erfreulicherweise kann man sagen, daß die Vereinigung aller bereits durch die Hersteller angebotenen Funktionalität von System-Software hinreichende Möglichkeiten für die DV-Revision bietet. Leider liegt jedoch die Gewichtung der Funktionalität der einzelnen Hersteller auf der Abrundung des Funktionsumfangs in jeweils einigen der angesprochenen Teilgebiete, so daß (noch) niemand ein wirklich in sich vollständiges Instrumentarium anbietet. Damit besteht zur Zeit noch die Notwendigkeit, das Vorhandene durch eigene Software-Entwicklungen zu ergänzen. Jedoch ist dabei schon Hilfe von Softwarehäusern gegeben, die kompetente Produkte anbieten.

- Man sollte die gewünschte Funktionalität für die vorhandene Systemumgebung auswählen und bereitstellen.

- Dabei beachte man aber auch die Notwendigkeit der Schulung; sowohl für die Systemverwaltung, die damit immer höher qualifizierte Aufgaben wahrnehmen muß, als auch die der DV-Revisoren, die auch auf diesem technisch hohen Niveau kompetente Partner ihrer operativ tätigen Kollegen (der Systemverwaltung und -entwicklung) sein müssen.

- Man muß in diesem Umfeld auch seinen Mitarbeitern Vertrauen entgegenbringen, nicht nur den Revisoren, sondern auch den in der Systemverwaltung und -entwicklung tätigen, also zu einer Dualität zwischen operativer Ebene und DV-Revision kommen.