Komplett Protokollierung

[Starocotes]

SOX verlangt nicht, dass alles protokolliert wird sondern dass alle Änderungen dokumentiert sind.
Wenn also per SQL o.ä. irgendwas geändert wird muss es ganz einfach schriftliche Aufzeichnungen darüber geben warum, weshalb und durch wen dies oder das ausserhalb der normalen Anwendung durchgeführt wird.

Und wenn es diese Aufzeichnungen nicht gibt weis niemand das was geändert wurde. Theoretisch kann ich doch kurz bevor eine Zahlung an die Bank geht über einen SQL Befehl mal kurz die Kontonnummer austauschen und das nachher wieder rückgängig machen, aufschreiben tue ich das natürlich nicht.

Sonst müsste ja auch festgehalten werden, warum gerade dieser Auftrag gelöscht wurde (weil der Bediener einen Fehler gemacht hat oder weil der Kunde storniert hat ?).

Gerade als ADMIN darf man eben nicht so einfach in den Dateien rumwursteln, dafür ist man ja ADMIN des SYSTEMS.
Für die Anwendungen sind ja (eigentlich) auch wieder andere Leute zuständig.

Das dem Theoretisch so ist ist klar, nur wie kann ich das sicher stellen oder im Nachhinein kontrollieren und das ist da wo SOX eigentlich ansetzt.

SOX wird nicht so heiß gegessen wie es aussieht.
Ich bin ja sowohl Entwickler, Tester, Installer und Admin. Eigentlich müsste ich 4 Personen sein, was aber weder personell noch finanziell vertretbar ist.
Und das geht auch.
Es muss nur über organisatorische Verfahren attestiert sein.

Es muss Kontrollen geben die sicher stellen das kein Unfug getrieben wird oder das Unfug aufgedeckt werden kann. Bei SOX gibt es zwei wichtige Prinzipien, zum Einen Teilung der Zuständigkeiten (segregation of Dutys) und zum anderen das vier Augen Prinzip.

Wir sind da mitten drin viele Dinge umzusetzen und lassen uns von externen Partnern beraten aber letztendlich ist es der Prüfer auf den es ankommt und hier liegt die Crux bei der Sache. Wenn der Prüfer ein Hardliner ist oder Angst hat dann verlangt er Kontrollen auf Alles und das kann keiner Bezahlen. Wenn er aber etwas lockerer ist sieht er das man sich Mühe gibt bestimmte Dinge zu kontrollieren und gibt sich damit zufrieden. Man weis aber vorher nicht wie der Prüfer das sieht. Nicht umsonst sind schon einige Unternehmen in den USA an SOX gescheitert.

Ich jedenfalls kann es mir nicht so einfach machen das abzuwälzen da ich ja dafür verantwortlich bin und auch wenn ein Externer das letztendlich machen soll muss ich das immer noch Koordinieren.

[Fuerchau]

Die Klagen diesbezüglich kann ich durchaus verstehen.
Ich weiß auch nicht, was sich die Amis dabei gedacht haben.
Insbesonders was die Aufzeichnung von Daten angeht, gibt es gerade dort Probleme ohne Ende.

Beschränken kann man sich da ja (eigentlich) auf die Fibu-Systeme, da ja nur diese überwacht werden müssen.
Andere ERP-Systeme spielen da ehe eine untergeordnete Rolle.

Aber auch die lückenlose Verfolgung der Daten stellt sich als schwerig dar.
Was bringt es, wenn ich garantieren kann, dass die Daten mein Unternehmen unverfälscht verlassen wenn ich nicht sicher sein kann, dass diese auch unverfälscht ankommen ?

Das Problem des Admins ist, dass dieser im wesentlichen nicht kontrollierbar ist !
Hier hilft ausschließlich Vertrauen, da im Ernstfall alle Kontrollen versagen da ein Admin gerade diese jederzeit umgehen kann.

[BenderD]

Hallo,

vielleicht noch ein paar Anmerkungen:

- Journalisierung aller Dateien sollte (bei dem EDV Budget einer Bank) kein Problem sein - rein technisch ist das keins.

- read Trigger könnten da schon eher Kapazitäten sprengen, da wäre ich vorsichtig

- ein alternativer Ansatz kann noch 4 Augen Prinzip nach Art des Tresorraumes sein, für den man zwei Schlüssel braucht. Technisch geht das kurz skizziert wie folgt:
Auditing für QSECOFR einschalten, damit protokolliert wird, wenn der Mechanismus deaktiviert wird.
Alle nicht interaktiven Schnittstellen über Exit Schnittstellen für QSECOFR zunageln.
Für die interaktive Anmeldung ein Startprogramm festlegen, dass als erstes mit einem Kennwort eines Revisors freigeschltet werden muss (da gibt es APIs für), selbiger muss dann ein entsprechendes Aktivitätsprotokoll mit dem ausführenden gemeinsam abzeichnen.

Voraussetzung ist dann weiterhin, dass die Applikation entsprechende Protokollmechanismen etc. hat, alle Zugriffsschutz Mechanismen korrekt implemetiert sind (keineswegs trivial), die Maschine und das Netz entsprechend physikalisch sicher sind.

mfg

Dieter Bender

Und wenn es diese Aufzeichnungen nicht gibt weis niemand das was geändert wurde. Theoretisch kann ich doch kurz bevor eine Zahlung an die Bank geht über einen SQL Befehl mal kurz die Kontonnummer austauschen und das nachher wieder rückgängig machen, aufschreiben tue ich das natürlich nicht.


Das dem Theoretisch so ist ist klar, nur wie kann ich das sicher stellen oder im Nachhinein kontrollieren und das ist da wo SOX eigentlich ansetzt.
Es muss Kontrollen geben die sicher stellen das kein Unfug getrieben wird oder das Unfug aufgedeckt werden kann. Bei SOX gibt es zwei wichtige Prinzipien, zum Einen Teilung der Zuständigkeiten (segregation of Dutys) und zum anderen das vier Augen Prinzip.

Wir sind da mitten drin viele Dinge umzusetzen und lassen uns von externen Partnern beraten aber letztendlich ist es der Prüfer auf den es ankommt und hier liegt die Crux bei der Sache. Wenn der Prüfer ein Hardliner ist oder Angst hat dann verlangt er Kontrollen auf Alles und das kann keiner Bezahlen. Wenn er aber etwas lockerer ist sieht er das man sich Mühe gibt bestimmte Dinge zu kontrollieren und gibt sich damit zufrieden. Man weis aber vorher nicht wie der Prüfer das sieht. Nicht umsonst sind schon einige Unternehmen in den USA an SOX gescheitert.

Ich jedenfalls kann es mir nicht so einfach machen das abzuwälzen da ich ja dafür verantwortlich bin und auch wenn ein Externer das letztendlich machen soll muss ich das immer noch Koordinieren.

[Starocotes]

Hallo,

vielleicht noch ein paar Anmerkungen:

- Journalisierung aller Dateien sollte (bei dem EDV Budget einer Bank) kein Problem sein - rein technisch ist das keins.

Wir sind leider keine Bank sondern eine kleine Deutsche Zweigstelle eines internationalen Unternehmens das an der NYSE notiert ist.

- ein alternativer Ansatz kann noch 4 Augen Prinzip nach Art des Tresorraumes sein, für den man zwei Schlüssel braucht. Technisch geht das kurz skizziert wie folgt:
Auditing für QSECOFR einschalten, damit protokolliert wird, wenn der Mechanismus deaktiviert wird.
Alle nicht interaktiven Schnittstellen über Exit Schnittstellen für QSECOFR zunageln.
Für die interaktive Anmeldung ein Startprogramm festlegen, dass als erstes mit einem Kennwort eines Revisors freigeschltet werden muss (da gibt es APIs für), selbiger muss dann ein entsprechendes Aktivitätsprotokoll mit dem ausführenden gemeinsam abzeichnen.

Voraussetzung ist dann weiterhin, dass die Applikation entsprechende Protokollmechanismen etc. hat, alle Zugriffsschutz Mechanismen korrekt implemetiert sind (keineswegs trivial), die Maschine und das Netz entsprechend physikalisch sicher sind.

Das hört sich machbar aber zu aufwendig an, was genau das ist was ich suche. Vielen Dank.

Wir können hier nur mit Vorschlägen kommen wie das implementiert werden kann, dann aufzeigen was es kostet und warten was passiert.

[TARASIK]

Hallo,
schaue Dir einmal diesen Thread durch:
http://www.rlpforen.de/showthread.php?t=6293