Cloud

Penetration Test Schweiz für Webanwendungen und APIs.

Autorisierte Penetrationstests aus der Schweiz. Klarer Umfang, nachvollziehbare Befunde, priorisierte Behebung und vereinbarter Nachtest.

Geprüft vom UHL-Team ·

Was unsere Penetrationstests abdecken

Jedes Engagement beginnt mit der Angriffsfläche, die für Ihr Unternehmen zählt. Wir konzentrieren uns auf Systeme, die wir wirklich in die Tiefe prüfen können, dieselben Arten von Systemen, die wir selbst entwickeln und betreiben.

Wir testen Webanwendungen, REST- und GraphQL-APIs, Kundenportale und Commerce-Plattformen sowie die darunterliegende Cloud- oder On-Premise-Infrastruktur. Gehören Anwendung und Betriebsumgebung zusammen, prüfen wir sie gemeinsam: Eine Anwendungsschwachstelle ist oft nur im Kontext von Netzwerk, Identität und Deployment ausnutzbar, oder überhaupt sichtbar.

Autorisierung und Regeln zuerst

Ein Penetrationstest findet nur mit expliziter, schriftlicher Autorisierung statt. Vor jedem Test vereinbaren wir den Umfang: welche Systeme dazu gehören und welche nicht, welche Testkonten reale Benutzerrollen abbilden, welche Techniken erlaubt sind, das Zeitfenster und die Eskalationskontakte, falls sich etwas unerwartet verhält.

Produktive Systeme erhalten besondere Sorgfalt. Kann eine Technik die Verfügbarkeit beeinträchtigen, besprechen wir sie vorher oder reproduzieren den Zustand in einer Staging-Umgebung. Sie behalten die Kontrolle über das Risiko, das der Test selbst mitbringt.

Wie eine Prüfung abläuft

Wir arbeiten mit einer strukturierten Methodik statt einer Checkliste. Die Aufklärung bildet die Anwendung, ihre Datenflüsse und Vertrauensgrenzen ab. Das Threat Modelling entscheidet, wo ein Angreifer tatsächlich ansetzen würde. Manuelle Tests versuchen dann die Ausnutzung unter den vereinbarten Regeln: Authentifizierung und Session-Handling, Zugriffskontrolle zwischen Rollen, Injection, Geschäftslogik, Dateiverarbeitung, Integrationen und die Konfiguration der Plattform darunter.

Automatisierte Scans unterstützen die Abdeckung, führen die Prüfung aber nicht. Scanner finden bekannte Muster; sie finden nicht den Logikfehler, mit dem ein Kunde die Daten eines anderen liest, oder den Workflow, der eigene Anfragen genehmigt. Die wichtigsten Befunde entstehen meist daraus, dass wir verstehen, wie sich Ihre Anwendung verhalten soll, und wozu sie gebracht werden kann.

Sprachmodell-Unterstützung unterliegt denselben Einsatzregeln. Unsere Organisation verfügt über verifizierten Zugang zu Daybreak Blue, der Trusted-Access-Stufe, die OpenAI für autorisierte defensive Sicherheitsarbeit betreibt, und nutzt sie für die Zusammenfassung von Aufklärungsdaten, die Triage von Befunden und Berichtsentwürfe auf bereinigten Eingaben. Kundendaten und Beweismittel gehen nie an externe Modellanbieter, und jeder KI-gestützte Schritt wird vom verantwortlichen Tester geprüft.

Ein Bericht, mit dem Ihr Team arbeiten kann

Das Ergebnis ist ein schriftlicher Bericht für die Menschen, die die Befunde beheben, kein Scanner-Export. Jeder bestätigte Befund dokumentiert die betroffene Komponente, die Voraussetzungen für die Ausnutzung, die praktische Auswirkung auf Ihre Daten und Systeme sowie reproduzierbare Nachweise, die Ihr Team verifizieren kann.

Befunde werden nach Ausnutzbarkeit und Auswirkung in Ihrer Umgebung priorisiert, mit einer Anleitung zur Behebung, die konkret genug ist, um sie umzusetzen. Wir unterscheiden eine bestätigte Schwachstelle von einer Härtungsempfehlung, und sagen klar, wenn sich ein vermutetes Problem im vereinbarten Umfang nicht bestätigen liess.

Retest und Verifikation

Ein Fix, der nie verifiziert wird, ist eine Hoffnung, kein Ergebnis. Nach Ihrer Behebung testen wir den ursprünglichen Befund erneut und prüfen das angrenzende Verhalten, hinter dem sich oft eine Teillösung versteckt, der zweite Endpoint mit demselben Fehler, die Prüfung, die das Format kontrolliert, aber nicht die Berechtigung.

Der Retest schliesst den Kreis: bestätigt behoben, weiterhin ausnutzbar oder behoben mit einem Restrisiko, das Sie bewusst tragen. Dieser Endstand wird als Teil des Engagement-Nachweises dokumentiert.

Compliance- und Prüfungsanlässe

Unternehmen beauftragen Penetration Testing Services aus verschiedenen Gründen: ISO-27001- und NIS2-orientierte Sicherheitsprogramme, PCI-DSS-Anforderungen, Cyber-Versicherungen, Sicherheitsfragebögen von Kunden oder schlicht technische Verantwortung vor einem Launch.

Wir sind präzise, was ein Test leistet: eine zeitpunktbezogene, umfangsgebundene Prüfung mit Nachweisen. Er unterstützt Compliance-Arbeit, ist aber keine Zertifizierung. Benötigt Ihr Auditor oder Ihre Versicherung ein bestimmtes Berichtsformat, nennen Sie es uns zu Beginn, wir gestalten das Engagement danach.

Tests aus der Schweiz, unter NDA

Befunde, Nachweise und Testkonten behandeln wir als vertrauliches Sicherheitsmaterial. Nachweise werden auf das reduziert, was der Bericht braucht, Zugriffe folgen dem vereinbarten Umfang, und wir arbeiten gern unter Ihrem NDA. Für Schweizer und EU-Organisationen bleibt der Umgang mit Daten planbar: Wir sind ein Schweizer Unternehmen, und Testnachweise wandern nicht über Drittplattformen.

Wann ein Test sinnvoll ist

Die wertvollsten Zeitpunkte sind vor einem öffentlichen Launch, nach einer grösseren Architekturänderung, nach einem Sicherheitsvorfall und periodisch für Systeme mit Kundendaten. Ob Ihr Vorhaben einen Penetrationstest oder eine leichtere Security Review braucht, klären wir ehrlich anhand des Systems. Unsere Application-Security- und Secure-SDLC-Arbeit deckt die gesamte Entwicklungsseite ab.

Ein überprüfbarer Testplan

Referenzen wie der OWASP Web Security Testing Guide, das OWASP-API-Sicherheitsprojekt und der OWASP Application Security Verification Standard helfen bei der Abdeckung. Der konkrete Testplan richtet sich nach autorisierten Anwendungen, Rollen und Risiken; die Nennung eines Standards bedeutet keine Zertifizierung.

Standards als Grundlage unserer Prüfungen

Rahmenwerke, auf die unsere Berichte verweisen: OWASP Testing Guide, PTES-Engagement-Struktur, NIST SP 800-115 für Assessment-Methodik.

Häufige Fragen

Was kostet ein Penetrationstest?

Kosten und Lieferzeit richten sich nach dem autorisierten Umfang: Anwendungen, Rollen, Umgebungen, Prüftiefe und Bericht. Daraus vereinbaren wir vor dem Start eine abgegrenzte Offerte, ein Lieferfenster und einen allfälligen Nachtest.

Black Box, Grey Box oder White Box - was passt?

Grey-Box-Tests mit repräsentativen Testkonten liefern meist die beste Abdeckung fürs Budget: Wir prüfen, was authentifizierte Benutzer und deren Grenzen offenlegen, nicht nur die Login-Seite. White-Box ergänzt Source-Code- und Architektur-Review für mehr Tiefe; Black-Box simuliert die Aussenansicht. Wir empfehlen das Modell je Umfang.

Wie unterscheidet sich ein Penetrationstest von einem Schwachstellenscan?

Ein Scan gleicht Systeme mit bekannten Schwachstellen-Signaturen ab und liefert eine Kandidatenliste. Ein Penetrationstest verifiziert, was tatsächlich ausnutzbar ist, verkettet Schwachstellen, prüft Geschäftslogik, die kein Scanner versteht, und trennt echte Befunde von Rauschen. Reife Programme nutzen beides, den Scan kontinuierlich, den Test periodisch.

Was sollten wir vor dem Test vorbereiten?

Das Wesentliche: schriftliche Autorisierung, eine Umfangsliste, Testkonten für die relevanten Rollen, einen technischen Ansprechpartner und einen Eskalationsweg. Dokumentation hilft, ist aber keine Voraussetzung; ein Teil der Prüfung ist, das System so zu entdecken wie ein Angreifer. Staging-Zugang ist nützlich, wo Produktivtests Verfügbarkeitsrisiken tragen.

Testen Sie nur Webanwendungen?

Webanwendungen und APIs sind unser Kernbereich, weil wir sie selbst entwickeln und betreiben. Infrastruktur und Netzwerksegmente prüfen wir, wo sie die Anwendung begrenzen, Cloud-Konfiguration, exponierte Dienste, Identitätspfade. Für grosse interne Netzwerk- oder Active-Directory-Engagements sagen wir das ehrlich und besprechen den passenden Ansatz mit Ihnen.

Sprechen wir über Ihr Projekt.

UHL kontaktieren