Kurzerklärung IT-Audit sowie Penetrationstest

Kurze Erklärung, was ein IT-Audit sowie ein Penetrationstest ist.

Ein Penetrationtest (Eindringen) wird oft als Audit (Prüfung) bezeichnet; dies ist aber Grundlegend falsch.
Der Penetrationtest kann ein Bestandteil eines Audit's sein, dies ist aber nicht zwingend Notwendig.
Dabei geht es darum, mit den Mitteln eines Intruder (Eindringlings), alle Schwachstellen eines digitalen Rechensystems ausfindig zu machen. Das dies durch den Auftrag des Verantwortlichen erfolgt versteht sich von selber.

Aufgrund der Tatsache das der Intruder nur eine oder wenige Lücken finden muss, aber der Penetration Tester möglichst alle , wird ein komplexeses sowie breitgefächertes Wissen über möglichst viele Plattformen und Datenbanksystemen vorausgesetzt.

Dies beginnt aber nicht mit einem einfachen "nmap scan", sondern bei den Auftraggebern.
Das Vorgehen eines Penetrationtests wird mit dem Kunden ausführlich durchgesprochen, sowie die Ziele schriftlich festgehalten. Dies beginnt bei der Analyse der Umgebung (welche Systeme, sowie Dienste laufen?
Aber auch die Hardware wie Router, Firewalls o.ä. darf dabei nicht ausser acht gelassen werden) und führt zu der aktiven Ausnutzung von Schwachstellen und Stresstests oder auch DoS Angriffen.

Dabei wird zwischen Black und White Penetrationtests unterschieden.

Bei den Black Tests hat das Tigerteam (Sicherheitsspezialisten, welche den Penetrationtests durchführen) keine Ahnung über die Infrastruktur und Simuliert hierbei den Eindringling von aussen.

Aber auch der White Test, welcher den Fall des internen Angreifers (Mitarbeiter) simuliert, kann abgedeckt werden.
In diesem Fall sind diverse Infrastukturinformationen vorhanden, wie zum Beispiel Informationen über die Erreichbarkeit mancher Systeme.

Bei beiden Vorgängen ist die Dokumentation über jeden Schritt Pflicht.

Ein Audit geht tiefer unter die Haube und ist ein laufender Vorgang.
Das wichtigste an einem Audit ist die unabhängikeit der Person, welche ihn durchführt.
Es hat keinen Sinn wenn, die Person Fehler endeckt, welche Sie selber verschuldet hat, oder nicht bei dem Vorgesetzten verantworten kann. Daher sollte die Person nicht an dem Projekt, welches das Ziel des Audit's ist, teilnehmen. Am idealsten wäre es, wenn externe Personen (Auditors), welche das Vertrauen der Firma besitzen, dies durchführen.

Auch bei einem Audit müssen zuvor Ziele definiert werden, welche von Auftraggebern schriftlich festgelegt werden.


Interessante Ziele wären:

Zugriffsrechte: Die Buchhaltung benötigt keinen Zugriff auf die Projekte der Entwicklungsabteilung und umgekehrt. (Einführung von ACL'S)

Prüfung und Verbesserung der Konfigurationen des digitalen Rechensystems im einzelnen und ganzen.

Verbesserungen, die nicht liefen wie angestrebt, zu analysieren und die Fehler zu beheben.

Die interne Sicherheit durch Mitarbeiterschulungen zu erhöhen.


Es ist ein Notfallplan (z.B. Backups, Versicherungen) aufzustellen, sowie genau zu definieren, wann ein Notfall eintritt.
Aber wichtiger ist eine Aufstellung des normalen Arbeitsablaufes (Schulungen der Mitarbeiter, klare Arbeitsanweissungen), welche das Riskos mindert.

Während des ganzen Audit's ist das Vorgehen zu dokumentieren und mit den Mitarbeitern des Auftraggebers zu besprechen (z.B. über Fehler). Regelmässige Berichte über den Fortschritt an den Auftraggeber gehören zur Selbstverständlichkeit. Die Dokumentation sollte die geprüften Bereiche sowie Fortschritte, behobene Fehler, Ursachen der Probleme und Stichproben enthalten.

Autor : Cornelius ' poiin2000 ' Wasmund
poiin2000 no_at_spam yahoo dot de
http://linux.regionnet.de

Das unveränderte Weiterreichen mit einer original Quellenangabe ist für diesen Text bei nichtwirtschaftlichen Interessen erlaubt.
 
Ihr 2 habt schon mal aufs Datum geschaut oder?

Naja, wenn der Link wirklich als schädlich eingestuft wird, dann muss man auch bei einem alten Thread mal was machen, aber in letzter Zeit war da wohl nichts auffälliges laut den erweiterten Infos. Ich hab trotzdem mal bei poiin nachgefragt, mal gucken, ob von da eine Antwort kommt.
 
Die Kurzerklärung bezieht sich auf die ISACA Methodik richtig ?

Habt ihr euch in dem Zusammenhang mal die BSI bzw die OSSTMM Methodiken angesehen ? Bei Bedarf könnte ich eine kleine Zusammenfassung Posten.
 
Die Kurzerklärung bezieht sich auf die ISACA Methodik richtig ?

Habt ihr euch in dem Zusammenhang mal die BSI bzw die OSSTMM Methodiken angesehen ? Bei Bedarf könnte ich eine kleine Zusammenfassung Posten.

Qualifikation in einem Fach verhaelt sich umgekehrt proportional zur Abstraktion desselben.

Ergo: Viel spannender waere es, wenn es Postings darüber gäbe, wie man ganz konkret zB. Backtrack nutzt um sein WEP geschütztes WLAN zu testen bzw. aufzumachen. Richtig formuliert könnte das als Use-Case stehen im Rahmen einer Tutorial Sammlng in Sachen Security.

Hand aufs Herz: Ich kann alle BSI, OSSTMM und WHATEVER Prozesse, Verfahren, Standarts etc. kennen und bin trotzdem nicht in der Lage auch nur einen Sicherheitstest in der Praxis durchzuführen (ausser nen nessus session anzuwerfen).

blubb.
 
Schön freut mich zu hören das hier weniger Wert auf die Managment Ebene gelegt wird. =) Ich bereite einen entsprechenden Use-Case vor.

Für mich Persönlich hat eigentlich immer dieses Tut ausgereicht ist sehr umfassend und behandelt
zusätzlich so ziemlich alles was an Installationsaufwand betrieben werden muss usw.

http://tinyurl.com/3xcpcx

Wenn das zu viel sein sollte schreibe ich das etwas zusammen.

Nachtrag:
Ansonsten denke ich das ich hier wohl etwas OT bin ;)

Gruß
 
Zuletzt bearbeitet:
Zurück
Oben