Sicherheitsaudit für Webanwendungen

Wann ein Audit der richtige erste Schritt ist

Vor dem Start einer wichtigen Funktion

Die Anwendung soll eine neue Anmeldung, Zahlungen, ein Kundenportal, Mitarbeiterrollen, eine Integration oder API erhalten. Der vereinbarte Bereich soll geprüft werden, bevor er echte Nutzer und Daten verarbeitet.

Nach einem Anbieterwechsel oder bei der Übernahme eines Systems

Die Anwendung läuft, doch es ist unklar, welche Entscheidungen zu Zugriffen, Konfiguration und Datenschutz bereits geprüft wurden. Ein Audit hilft, dringende Probleme von Themen zu trennen, die später geplant werden können.

Vor einer größeren Erweiterung

Neue Rollen, Module oder Integrationen sind vorgesehen. Wer bestehende Einschränkungen vorher kennt, verhindert, dass aktuelle Schwachstellen in weitere Teile der Anwendung übernommen werden.

Bei auffälligem Verhalten

Nutzer sehen Daten, auf die sie keinen Zugriff haben sollten, die Anmeldung verhält sich uneinheitlich, die API liefert zu viele Informationen oder die Konfiguration wirkt fragwürdig. Wir klären zunächst, ob ein geplantes Audit ausreicht oder eine dringende Behandlung des Vorfalls notwendig ist.

Wenn eine Reihenfolge für die Behebung fehlt

Die Warnliste eines automatischen Scanners zeigt noch nicht, welche Befunde sich in dieser Anwendung tatsächlich bestätigen lassen und welche für das Unternehmen besonders relevant sind. Dafür braucht es Bestätigung, Kontext und Prioritäten.

Audit, Konfigurationsprüfung, Code-Review und Penetrationstest sind nicht dasselbe

Die Bezeichnungen werden teilweise austauschbar verwendet, obwohl der tatsächliche Leistungsumfang stark abweichen kann. Deshalb hält unser Angebot vor Beginn fest, welche Tätigkeiten zum Auftrag gehören.

Den Begriff "Penetrationstest" verwenden wir nur, wenn der konkrete Auftrag tatsächlich vereinbarte Penetrationstests umfasst. Ein Sicherheitsaudit allein ist kein Versprechen eines vollständigen Pentests.

Den Umfang stimmen wir vor Beginn ab

Jede Anwendung hat eigene Anmeldewege, Rollen, Daten, Integrationen und Risiken. Vor der Angebotserstellung klären wir mindestens:

• die betroffenen Domains, Anwendungen und Umgebungen;
• die zu prüfenden Funktionen und Geschäftsprozesse;
• die Rollen und Testkonten, die genutzt werden dürfen;
• ausgewählte API-Endpunkte und angebundene Integrationen;
• erlaubte Testarten und deren Grenzen;
• ausdrücklich ausgeschlossene Bereiche;
• sichere Bedingungen für Test- oder Produktivumgebungen;
• die Form des Ergebnisses und die zum Empfang berechtigten Personen.

Liegt ein Teil der Anwendung, Infrastruktur oder des Codes außerhalb des Auftrags, halten wir dies als Einschränkung fest. Das Ergebnis erweckt dadurch nicht den Eindruck, ungeprüfte Bereiche seien abgedeckt worden.

So kann die Zusammenarbeit ablaufen

1. Wir ordnen den Bedarf kurz ein

Ein kostenloses Gespräch von bis zu 20 Minuten hilft, Ziel, wichtige Bereiche und benötigte Unterlagen zu verstehen. Es ist keine kostenlose Diagnose, kein Audit und kein Bericht.

2. Wir legen Umfang und Sicherheitsregeln fest

Vor Beginn erhalten Sie ein individuelles Angebot. Darin stehen Umgebung, erlaubte Handlungen, Ausschlüsse, Ergebnis, Termin und Preis.

3. Sie übermitteln benötigte Unterlagen sicher

Nach der Beauftragung vereinbaren wir einen geeigneten Kanal für Testkonten, Code oder Dokumentation. Passwörter, API-Schlüssel, Datenbankkopien und Kundendaten gehören nicht in das normale Kontaktformular.

4. Wir führen die vereinbarten Prüfungen durch

Wir kombinieren nur Methoden, die zum Umfang und zu den Bedingungen der Anwendung passen. Wo es möglich und sicher ist, bestätigen wir Probleme, statt lediglich eine ungeprüfte Liste automatischer Warnungen weiterzugeben.

5. Wir übergeben das Ergebnis und besprechen Prioritäten

Das Ergebnis zeigt, was geprüft und bestätigt wurde, welche Einschränkungen gelten und womit die Behebung beginnen sollte. Das genaue Format vereinbaren wir vor dem Start.

Was Sie nach dem Audit erhalten

Die konkreten Ergebnisse richten sich nach dem Angebot. Die vereinbarte Zusammenfassung kann enthalten:

• den geprüften Umfang, die Umgebung und die Einschränkungen;
• bestätigte Probleme mit Einschätzung ihrer Bedeutung;
• Nachweise und Schritte zur Reproduktion, sofern sie sicher weitergegeben werden können;
• mögliche technische und geschäftliche Auswirkungen;
• Empfehlungen für Behebung oder weiterführende Prüfung;
• eine vorgeschlagene Reihenfolge der Maßnahmen;
• technische Informationen für das Team, das die Änderungen umsetzt.

Sie können die Unterlagen für weitere Arbeiten mit Domin Software verwenden oder sie unter Beachtung der Vertraulichkeit und der vereinbarten Regeln an einen anderen Anbieter übergeben.

OWASP ist eine Orientierung, keine automatische Zusage vollständiger Abdeckung

Bei der Festlegung des Umfangs können wir aktuelle OWASP-Materialien zu Webanwendungstests, Sicherheitsanforderungen und API-Risiken heranziehen. Sie helfen, Prüfbereiche zu strukturieren, ersetzen jedoch keinen individuell vereinbarten Auftrag.

Ein OWASP-Verweis bedeutet nicht, dass jeder Auftrag sämtliche Tests des Web Security Testing Guide, alle ASVS-Anforderungen oder jede Kategorie von API-Risiken umfasst. Im Angebot steht, was tatsächlich geprüft wird.

Was der grundlegende Umfang nicht enthält

Sofern ein konkretes Angebot nichts anderes festlegt, umfasst das Audit nicht automatisch:

• ein Sicherheitszertifikat;
• die Garantie, jede Schwachstelle zu finden oder zukünftige Probleme auszuschließen;
• Tests des gesamten Codes, der gesamten Infrastruktur, Netzwerke und Geräte;
• Social-Engineering-Tests oder gegen Mitarbeiter gerichtete Maßnahmen;
• Lasttests oder eine Beeinträchtigung des Produktivbetriebs;
• die Umsetzung aller empfohlenen Korrekturen;
• eine Rund-um-die-Uhr-Überwachung oder dauerhafte Incident Response;
• eine erneute Prüfung zu einem beliebigen späteren Zeitpunkt oder nach nicht abgestimmten Änderungen.

Aktive Tests in der Produktivumgebung führen wir nur durch, wenn sie gesondert vereinbart, freigegeben und abgesichert wurden. Ist für eine sichere Prüfung eine andere Umgebung nötig, weisen wir vor Beginn darauf hin.

Behebung und erneute Prüfung

Die Umsetzung von Korrekturen ist ein eigener Leistungsumfang, sofern das Angebot nichts anderes festlegt. Nach dem Audit können wir die Arbeiten separat anbieten oder die Unterlagen an das vom Kunden gewählte Team übergeben.

Wenn Domin Software die Korrekturen umsetzt, kann eine erneute Prüfung innerhalb des im Angebot genannten Zeitraums kostenlos sein. Nach einer längeren Pause, nach Änderungen durch Dritte oder außerhalb des ursprünglichen Umfangs ist ein neues Angebot erforderlich.

Führt das Audit zu einem größeren Projekt, das Domin Software umsetzt, wird der bezahlte Auditpreis auf die Gesamtkosten dieses Projekts angerechnet.

Dauer, Angebot und Abrechnung

Jedes Audit wird individuell kalkuliert. Der Preis hängt unter anderem von der Anzahl der Bereiche, Rollen, Endpunkte und Umgebungen, den benötigten Zugängen und den erlaubten Testarten ab.

Als Arbeitsrahmen rechnen wir mit 7 bis 15 Werktagen, nachdem der vollständige Umfang, eine verfügbare Umgebung und die vereinbarten Testkonten vorliegen. Den verbindlichen Termin nennt das Angebot.

In der Regel erfolgt die Abrechnung nach Abschluss der vereinbarten Etappe. Bei größerem Umfang kann eine Anzahlung vereinbart werden.

Häufige Fragen

Worin unterscheidet sich ein Sicherheitsaudit von einem Penetrationstest?

Audit ist der weiter gefasste Begriff für eine bezahlte Prüfung vereinbarter Bereiche. Es kann Konfigurationsprüfung, Analyse ausgewählter Funktionen, Code-Review und Tests verbinden. Ein Penetrationstest umfasst kontrollierte Versuche, Schwachstellen innerhalb ausdrücklich erlaubter Grenzen auszunutzen. Nicht jedes Audit enthält einen solchen Test.

Können Tests in der Produktivumgebung stattfinden?

Davon gehen wir nicht automatisch aus. Zuerst bewerten wir das Risiko und prüfen, ob eine Testumgebung ausreicht. Jede Handlung in der Produktivumgebung benötigt eine gesonderte Freigabe, einen begrenzten Umfang und Bedingungen zum Schutz von Daten und Verfügbarkeit.

Ist Zugriff auf den Quellcode nötig?

Nicht immer. Das hängt von Ziel und Umfang ab. Manche Probleme lassen sich an der laufenden Anwendung prüfen, andere erfordern Konfiguration, Dokumentation oder ausgewählte Codebereiche. Den nötigen Zugriff klären wir vor der Kalkulation.

Was steht in der Zusammenfassung nach dem Audit?

Wir beschreiben den geprüften Umfang und seine Einschränkungen, bestätigte Probleme, deren Bedeutung, verfügbare Nachweise, Reproduktionsschritte, Risiken und Empfehlungen. Format und Detailtiefe werden im Angebot festgelegt.

Umfasst das Audit auch die Umsetzung der Korrekturen?

Nicht im grundlegenden Umfang. Wir können die Umsetzung separat anbieten. Die Auditunterlagen können Sie auch an einen anderen Anbieter übergeben.

Ist eine erneute Prüfung im Preis enthalten?

Wenn Domin Software die Korrekturen umsetzt, kann innerhalb des im Angebot genannten Zeitraums eine kostenlose Prüfung gelten. Nach einer längeren Pause, weiteren Änderungen oder außerhalb des vereinbarten Umfangs erstellen wir ein neues Angebot.

Garantiert das Audit, dass die Anwendung keine Schwachstellen hat?

Nein. Das Ergebnis bezieht sich auf einen bestimmten Umfang, Zeitpunkt, eine bestimmte Umgebung und die verfügbaren Informationen. Es garantiert weder die Entdeckung jedes Problems noch das Ausbleiben zukünftiger Schwachstellen.

Wie werden Zugänge und Testkonten übermittelt?

Beschreiben Sie im Formular nur die Situation und den gewünschten Umfang. Nach der Beauftragung nennen wir einen sicheren Übertragungsweg. Tragen Sie keine Passwörter, API-Schlüssel, Kundendaten oder Datenbankkopien in das Formular ein.

Was Sie in der ersten Nachricht angeben können

• Art der Anwendung und ihre Bedeutung für das Unternehmen;
• Anlass des Audits, etwa eine geplante Einführung, ein Anbieterwechsel oder eine größere Erweiterung;
• Verfügbarkeit einer Testumgebung;
• Anzahl der wichtigsten Nutzerrollen;
• vorhandene API oder wichtige Integrationen;
• gewünschter Zeitraum und Grund für die aktuelle Prüfung;
• bekannte Zugriffsbeschränkungen, ohne vertrauliche Daten zu übermitteln.

Senden Sie über das Formular keine Passwörter, API-Schlüssel, Tokens, Datenbankkopien, Quellcode oder Kundendaten. Den sicheren Übertragungsweg stimmen wir gesondert ab.

CTA: Auditumfang abstimmen

Wenn Sie ein bestehendes System von einem anderen Anbieter übernehmen, können Sie zuerst die Checkliste zur Anwendungsübernahme verwenden.

Nach dem Audit können wir separat eine Modernisierung der Anwendung oder eine laufende Betreuung vereinbaren. Für mit KI-Werkzeugen erstellte Projekte gibt es außerdem das Audit einer KI-Anwendung; Probleme mit Antwortzeit und Last gehören in ein Performance-Audit.

Technische Quellen

• OWASP Web Security Testing Guide - Orientierung für Prüfbereiche von Webanwendungen und Webservices, die an den konkreten Auftrag angepasst werden müssen.
• OWASP Application Security Verification Standard - Katalog technischer Anforderungen, der bei der Festlegung von Sicherheits- und Prüfanforderungen helfen kann.
• OWASP API Security Top 10 - Orientierung für typische Risiken von APIs.

Der öffentliche Text behauptet keine vollständige Übereinstimmung mit sämtlichen Inhalten dieser Materialien.