Methodik
Unsere Tests sind wiederholbar, messbar und transparent. Sie beruhen auf anerkannten offenen Methodiken, und wir dokumentieren jeden Schritt.
Frameworks, auf denen wir aufbauen
Sicherheit von Webanwendungen
OWASP Top 10:2025 zur Risikoeinordnung, ASVS 5.0.0 für Prüfanforderungen und WSTG v4.2 für strukturierte Testfälle.
API- und Mobile-Sicherheit
OWASP API Security Top 10:2023 und OWASP Mobile Top 10 2024. Bei mobilen Anwendungen ergänzen MASVS-Kontrollen und MASTG-Testverfahren die Prüfung.
PTES und NIST SP 800-115
Ein strukturierter Ablauf von Freigabe und Aufklärung bis zu Analyse, kontrollierter Ausnutzung und Berichterstattung – mit vereinbarten Schutzmaßnahmen für den Produktivbetrieb.
FIRST CVSS v4.0
Technische Schwere dokumentieren wir mit Wert und Vektor. Geschäftliche Auswirkungen, Exposition und Ausnutzungswahrscheinlichkeit fließen zusätzlich in die Priorisierung ein.
ISO/IEC 27001:2022, KVKK und NIS2
Vorbereitung durch Zuordnung technischer Befunde zu relevanten Sicherheitsmaßnahmen. Anwendbarkeit und rechtliche Pflichten sind mit qualifizierten Beratern zu klären.
PCI DSS v4.0.1
Technische Prüfungen und Vorbereitung für Zahlungsumgebungen im vereinbarten Umfang. Wir bieten keine QSA-Bewertung, ASV-Scans oder PCI-Zertifizierung an.
Testphasen
1. Vorgespräch und Umfang
Ziele, Assets, Testart (Black, Grey oder White Box), Zeitfenster und Ansprechpartner werden festgelegt.
2. Freigabe
Ohne schriftliche Testfreigabe und unterzeichnete Rules of Engagement beginnt kein aktiver Test.
3. Aufklärung
Durch passive und aktive Informationsgewinnung wird die Angriffsfläche erfasst.
4. Schwachstellenanalyse
Automatisierte Tools und manuelle Prüfung werden kombiniert, False Positives aussortiert.
5. Kontrollierte Ausnutzung
Die tatsächliche Auswirkung der Befunde wird belegt, ohne Datenintegrität oder Verfügbarkeit zu gefährden.
6. Reporting
Management Summary und technischer Bericht werden erstellt und präsentiert.
7. Nachtest
Behobene Befunde werden erneut getestet und das Ergebnis dokumentiert.
Schweregrade (CVSS v4.0)
Der CVSS-Wert zeigt die technische Schwere. Für die Priorität berücksichtigen wir zusätzlich die geschäftliche Bedeutung des Assets und die Wahrscheinlichkeit einer Ausnutzung.
| Schweregrad | CVSS-v4.0-Bereich | Empfohlenes Vorgehen |
|---|---|---|
| Kritisch | 9,0 – 10,0 | Sofort handeln; wird noch während des Tests gemeldet. |
| Hoch | 7,0 – 8,9 | Kurzfristig und vorrangig beheben. |
| Mittel | 4,0 – 6,9 | Im geplanten Wartungszyklus beheben. |
| Niedrig | 0,1 – 3,9 | Bei Gelegenheit oder zusammen mit anderen Arbeiten angehen. |
| Information | 0,0 | Kein direktes Risiko; Hinweise zu Härtung und Best Practice. |
Beispielbefund
Der folgende Eintrag ist ein fiktives Beispiel und zeigt den Aufbau der Befunde in unseren Berichten. Er bezieht sich auf keinen realen Kunden.
- Titel
- SQL-Injection ohne Authentifizierung in der Login-API
- Schweregrad
- Kritisch
- CVSS v4.0
9,3 · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N- Betroffenes Asset
POST /api/v1/auth/login (Beispiel)- Auswirkung
- Ein nicht authentifizierter Angreifer kann Kundendatensätze in der Datenbank lesen und verändern.
- Nachweis
- Reproduktionsschritte, Request-/Response-Beispiele und Screenshots (sensible Daten maskiert).
- Empfehlung
- Parametrisierte Abfragen verwenden, Rechte des Datenbankbenutzers einschränken und Rate Limiting für den Login-Endpunkt einführen.
- Zuordnung
- OWASP Top 10 A05:2025 Injection · ASVS 5.0.0 V1 · ISO/IEC 27001:2022 A.8.28
Beispielhafter Berichtsablauf
Kickoff
Abstimmung des Umfangs und Freigabe der Rules of Engagement.
Testphase
Kurzer täglicher Statusbericht; kritische Befunde melden wir sofort.
Berichtsentwurf
Nach Testende erhalten Sie einen Berichtsentwurf und die Befundliste.
Abschlusspräsentation
Zusammenfassung für das Management und eine Befundbesprechung mit dem technischen Team.
Finaler Bericht
Der finale Bericht mit eingearbeitetem Feedback, verschlüsselt übergeben.
Nachtest
Erneuter Test der Behebungen und aktualisierter Statusbericht.
Rules of Engagement
- Ohne schriftliche Freigabe wird kein System aktiv getestet.
- Getestet werden nur Assets im vereinbarten Umfang.
- Denial-of-Service und Social Engineering nur, wenn sie ausdrücklich im Umfang enthalten sind.
- Für beide Seiten wird ein Kanal festgelegt, über den die Arbeit sofort gestoppt werden kann.
- Personenbezogene Daten, auf die wir beim Test stoßen, berühren wir so wenig wie möglich und kopieren sie nicht.
- Nach Projektende werden Testdaten und temporäre Zugänge entfernt.
Finden Sie Ihre Schwachstellen, bevor Angreifer es tun.
Lassen Sie uns den Umfang gemeinsam festlegen. Sie erhalten ein schriftliches Angebot mit dem passenden Test und einem klaren Zeitplan.