Security-Audit steht an: Was Sie in 4 Wochen vorbereiten müssen

In vier Wochen kommt der Auditor. Die E-Mail vom Kunden, vom Vorstand oder von der Compliance-Abteilung ist da. Jetzt beginnt entweder strukturierte Vorbereitung – oder Panik. Dieser Artikel gibt Ihnen einen konkreten 4-Wochen-Plan, zeigt die Findings, die garantiert kommen, und erklärt, was Prüfer wirklich sehen wollen.

Ein Audit prüft Systeme – nicht Menschen.

Welcher Audit steht an?

Bevor Sie vorbereiten, klären Sie: Was genau wird geprüft?

Die Vorbereitung unterscheidet sich. Ein Pentest erfordert technische Härtung, ISO 27001 verlangt Dokumentation. Dieser Artikel fokussiert auf die Schnittmenge – das, was bei jedem Audit hilft.

Der 4-Wochen-Plan

# Quick Asset Discovery
nmap -sn 10.0.0.0/24 > network-hosts.txt

# Welche Services laufen?
nmap -sV -top-ports 1000 10.0.0.0/24

# Cloud-Assets (AWS)
aws ec2 describe-instances --query 'Reservations[].Instances[].{ID:InstanceId,Type:InstanceType,State:State.Name}'
aws rds describe-db-instances --query 'DBInstances[].{ID:DBInstanceIdentifier,Engine:Engine}'

# Security Headers testen
curl -I https://ihre-app.de | grep -i "strict\|content-security\|x-frame\|x-content"

# SSL-Konfiguration prüfen
testssl.sh https://ihre-app.de

# Bekannte Vulnerabilities in Dependencies
npm audit
composer audit
pip-audit

# Selbst-Scan mit OWASP ZAP (Docker)
docker run -t owasp/zap2docker-stable zap-baseline.py -t https://ihre-app.de

# Oder mit Nikto
nikto -h https://ihre-app.de

# SSL Labs API (extern)
curl "https://api.ssllabs.com/api/v3/analyze?host=ihre-app.de"

Findings, die garantiert kommen

Nach hunderten Audits kann ich Ihnen sagen: Diese Findings tauchen in 90% aller Berichte auf. Fixen Sie sie vorher.

1. Fehlende oder schwache Security Headers

# Nginx-Konfiguration
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

2. Veraltete Software mit bekannten CVEs

Nichts ist peinlicher als ein Finding für eine Vulnerability, die seit 2 Jahren gepatcht ist.

3. Informationspreisgabe in Error Messages

Stack Traces, Datenbankfehler, Pfade – alles Gold für Angreifer.

# Schlecht (Produktion)
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'prod_db.users' doesn't exist
at /var/www/app/vendor/laravel/framework/src/Database/Connection.php:742

# Gut (Produktion)
Ein Fehler ist aufgetreten. Bitte versuchen Sie es später erneut. (Ref: ERR-7f3a2b)

4. Schwaches Session-Management

• Sessions, die nach Logout noch gültig sind
• Session-IDs in URLs
• Fehlende Session-Timeouts
• Cookies ohne Secure und HttpOnly Flags

# Cookie-Flags prüfen
curl -I https://ihre-app.de/login -c - | grep -i "set-cookie"

# Erwartetes Ergebnis:
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Strict

5. Fehlende Rate Limiting

Login, API-Endpunkte, Passwort-Reset – ohne Rate Limiting sind Brute-Force-Angriffe trivial.

# Test: Wie viele Login-Versuche sind möglich?
for i in {1..100}; do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -X POST https://ihre-app.de/login \
    -d "user=admin&pass=wrong$i"
done | sort | uniq -c

# Wenn alle 100 Requests HTTP 200/401 zurückgeben: Problem

6. CORS-Fehlkonfiguration

# Schlecht
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

# Gefährlich: Erlaubt jeder Domain, authentifizierte Requests zu machen

7. Fehlende Logging/Monitoring

Wenn Sie nicht erklären können, wer wann auf was zugegriffen hat, ist das ein Finding.

Was Prüfer wirklich sehen wollen

Nach vielen Jahren auf beiden Seiten des Tisches kann ich Ihnen sagen: Es geht nicht um Perfektion. Es geht um Nachvollziehbarkeit.

1. Bewusstsein für Risiken

Ein dokumentiertes Risiko mit bewusster Akzeptanz ist besser als ein unbekanntes Risiko. Prüfer respektieren: „Wir wissen, dass X ein Risiko ist. Wir haben entschieden, es zu akzeptieren, weil Y. Hier ist die dokumentierte Entscheidung."

2. Konsistenz zwischen Dokumentation und Realität

Nichts ist schlimmer als eine Security-Policy, die das Gegenteil der Realität beschreibt. Wenn Ihre Policy sagt „Alle Passwörter haben 12 Zeichen", dann darf die Datenbank keine 6-Zeichen-Hashes enthalten.

3. Nachvollziehbare Prozesse

Wie kommt Code in Produktion? Wer genehmigt Zugriffsrechte? Was passiert bei einem Security-Incident? Prüfer wollen sehen, dass es einen Prozess gibt – und dass er befolgt wird.

4. Reaktionsfähigkeit

Können Sie innerhalb von 24 Stunden eine kritische Vulnerability patchen? Wie schnell können Sie einen kompromittierten Account sperren? Prüfer interessiert nicht nur der Ist-Zustand, sondern auch Ihre Fähigkeit zu reagieren.

5. Kontinuierliche Verbesserung

Der beste Eindruck: „Hier ist unser letzter Audit-Bericht. Hier sind die Findings. Hier ist der Status – 90% geschlossen, 10% in Arbeit mit Deadline." Das zeigt Reife.

Dokumente, die Sie brauchen

Während des Audits

Kommunikation

• Single Point of Contact: Eine Person koordiniert alle Anfragen
• Antworten dokumentieren: Wer hat was gesagt? Schriftlich festhalten
• Keine Vermutungen: „Ich prüfe das und melde mich" ist besser als raten

Bei Findings

• Nicht defensiv werden: Findings sind keine persönliche Kritik
• Kontext liefern: Warum ist etwas so, wie es ist?
• Sofort-Maßnahmen anbieten: „Das können wir bis morgen fixen"
• Priorisierung diskutieren: Nicht jedes Finding ist gleich kritisch

Don'ts

• Nicht lügen: Prüfer merken das. Immer.
• Nicht verstecken: Bekannte Probleme proaktiv ansprechen
• Nicht improvisieren: Wenn Sie etwas nicht wissen, sagen Sie es

Nach dem Audit

Bericht erhalten

• Zeitnah reviewen: Stimmen die Findings? Kontext korrekt?
• Rückfragen stellen: Unklarheiten klären, bevor der Bericht final ist
• Severity diskutieren: Wenn Sie ein Finding anders bewerten, argumentieren Sie

Findings bearbeiten

• Tickets erstellen: Jedes Finding wird ein Backlog-Item
• Owner zuweisen: Wer ist verantwortlich?
• Deadlines setzen: Realistisch, aber verbindlich
• Tracking aufsetzen: Regelmäßiger Status-Report

Fazit

Ein Security-Audit ist keine Prüfung, die man besteht oder nicht. Es ist ein Werkzeug, um Schwachstellen zu finden – idealerweise bevor es ein Angreifer tut.

Die wichtigsten Punkte:

• Vorbereitung ist alles: 4 Wochen reichen für die Grundlagen
• Low-Hanging Fruits zuerst: Security Headers, Updates, Defaults
• Dokumentation = Nachweis: Was nicht dokumentiert ist, existiert nicht
• Ehrlichkeit gewinnt: Bekannte Risiken sind besser als versteckte
• Follow-through: Der Wert liegt im Fixen, nicht im Bericht

Ein Audit scheitert nicht an Technik, sondern an fehlender Vorbereitung und Ehrlichkeit.

Komplette Checkliste

Häufige Fragen

4 Wochen reichen nicht – was tun?

Priorisieren. Fokus auf: Security Headers, kritische Updates, Dokumentation der wichtigsten Systeme. Kommunizieren Sie dem Auditor, dass Sie im Verbesserungsprozess sind. Das ist besser als gar nichts.

Wir haben keinen Incident-Response-Plan – wie schnell geht das?

Ein Basis-Plan in 2-3 Tagen: Wer wird informiert? Wer entscheidet? Welche Sofortmaßnahmen? Das muss kein 50-Seiten-Dokument sein. Eine Seite mit klaren Verantwortlichkeiten ist ein Anfang.

Der Auditor findet etwas Kritisches – verlieren wir den Kunden?

Selten. Kunden wollen sehen, dass Sie reagieren können. Ein kritisches Finding mit 24h-Fix und Retest-Nachweis ist besser als ein „sauberer" Audit, dem niemand traut.

Können wir den Scope einschränken?

Ja, aber vorsichtig. Ein zu enger Scope wirkt wie Verstecken. Besser: Klar definieren, was geprüft wird – und warum der Rest außerhalb liegt (z.B. „Third-Party-Hoster, eigener Audit-Bericht liegt vor").

Carola Schulte

Software-Architektin mit 25+ Jahren Erfahrung in Security-Audits, sowohl als Prüferin als auch bei der Vorbereitung.

Beratung anfragen