01
Webanwendungstests
Authentifizierte und nicht authentifizierte Tests von Geschäftslogik, Zugriffskontrolle und Injection-Klassen.
01 — Offensive Security
Finden Sie den Weg, den ein Angreifer nehmen würde.
Realistische Angriffssimulation über Anwendungen, APIs, Infrastruktur, Netzwerke und Cloud-Umgebungen hinweg.
Angriffspfad
Recon: Die exponierte Angriffsfläche und Einstiegspunkte kartieren.
Ein Penetrationstest ist die kontrollierte Simulation eines echten Angriffs. Statt theoretische Schwachstellen aufzulisten, verketten unsere Tester Befunde so, wie ein Angreifer es täte — vom Erstzugang über Rechteausweitung bis zur Geschäftsauswirkung. So wissen Sie, welche Schwachstellen tatsächlich relevant sind.
- Scope und Rules of Engagement werden vor Testbeginn schriftlich vereinbart.
- Befunde werden nach Ausnutzbarkeit und Geschäftsauswirkung bewertet, nicht allein nach Scanner-Severity.
- Berichte für zwei Zielgruppen: Engineers, die beheben, und Entscheider, die priorisieren.
Was das Engagement umfasst
02
API-Tests
REST- und GraphQL-Schnittstellen, Autorisierungsgrenzen und Datenexposition.
03
Netzwerk & Infrastruktur
Tests des externen Perimeters und der internen Segmentierung.
04
Cloud-Umgebungen
Identitäts-, Rollen- und Konfigurationspfade innerhalb von Cloud-Konten.
05
Social Engineering
Menschliche Angriffspfade — getestet in vereinbartem Scope mit Eskalationsplan.
06
Retests
Verifikation, dass die Behebung den Pfad tatsächlich geschlossen hat.
Spezialplattform
Vertiefte Details zu Penetrationstests finden Sie auf unserer Spezialseite.
Unsere spezialisierte Plattform für Penetrationstests enthält die vertiefte Methodik, Testarten und technischen Details. Evolvice verantwortet das Enterprise-Engagement; die Spezialseite bleibt die tiefere Quelle.
Fragen & Antworten
Worin unterscheidet sich ein Penetrationstest von einem Schwachstellenscan?
Ein Scan listet potenzielle Schwachstellen auf. Ein Penetrationstest weist nach, welche davon ausnutzbar sind, wie weit ein Angreifer kommt und welche Auswirkung das für das Geschäft hätte.
Wie oft sollten wir testen?
Die meisten Organisationen testen jährlich sowie nach relevanten Architektur- oder Release-Änderungen. Systeme mit kontinuierlichen Änderungen profitieren von einem wiederkehrenden Testzyklus.
Stört der Test den Produktivbetrieb?
Tests laufen nach vereinbarten Rules of Engagement, in definierten Zeitfenstern und mit Eskalationskontakten. Destruktive Tests erfolgen nur mit ausdrücklicher Freigabe.
Weiter in der Säule
- 02Cloud-SicherheitArchitektur, Identitäten, Konfiguration, Workloads und Datenschutz über Cloud-Umgebungen hinweg.
- 03SchwachstellenanalyseKontinuierliche Erkennung, risikobasierte Priorisierung und verifizierte Behebung von Schwachstellen und Bedrohungen.
- 04Security AwarenessRollenbasierte Awareness-Programme, die Verhalten im Moment der Entscheidung verändern.