Anwendungssicherheit vor dem Release und im laufenden Betrieb.
Sicherheit gehört zu Entwicklung und Auslieferung: Code prüfen, Integrationsgrenzen testen und die bereitgestellte Anwendung vor dem Produktionsrelease verifizieren.
Geprüft vom UHL-Team ·
Die Prüfung im Staging verankern
Vor einer Prüfung vereinbaren wir Anwendungsumfang, Datenflüsse und Testberechtigungen. Im Staging prüfen wir geschäftsrelevante Abläufe: Anmeldung, Kontowiederherstellung, Berechtigungen, Checkout, Administration und Hintergrundverarbeitung. Ein erfolgreicher Build ist ein Nachweis, aber kein Beleg für sicheres Verhalten des laufenden Systems.
API-Integrationen absichern
Wir prüfen Authentifizierung, minimal nötige Berechtigungen, Geheimnisverwaltung, Eingabevalidierung und die zugänglichen Daten. Webhook-Prüfung, Wiederholungsschutz, Idempotenz, Seitennavigation und Wiederaufnahme nach Teilfehlern erhalten dieselbe Aufmerksamkeit wie der Erfolgsfall.
Zeitlimits, begrenzte Wiederholungen, Anfragegrössen und Ratenbegrenzungen helfen, die Anwendung bei langsamen oder ausgefallenen Abhängigkeiten zu schützen. Externe Ziele werden nach Möglichkeit eingegrenzt, um serverseitige Request-Forgery-Risiken zu reduzieren.
Vermeidbare Überlastung reduzieren
Teure Abfragen, unbegrenzte Importe, unkontrollierte Parallelität und Wiederholungsschleifen können gesunde Systeme überlasten. Wir testen realistische Grenzen und definieren bei Bedarf Rückstaukontrolle, Caching und Betriebsalarme. Anwendungskontrollen reduzieren vermeidbare Ressourcenerschöpfung; Schutz vor verteilten Denial-of-Service-Angriffen hängt auch von Netzkapazität und vorgeschalteten Kontrollen ab.
Befunde, die sich bearbeiten lassen
Das Ergebnis ist ein priorisierter Nachweis mit betroffener Komponente, Belegen, Auswirkungen, Korrekturvorschlag und Überprüfung. Code-Review, automatisierte Kontrollen, autorisierte Penetrationstests und Nachweise im laufenden System werden unterschieden. Verbleibende Grenzen nennen wir ausdrücklich.
Entwicklung und Sicherheitsbetrieb verbinden
Unsere Wazuh-Praxis verbindet über fünf Jahre internen Betrieb, eigene Erkennungsinhalte und Agenten auf unserer gesamten Infrastruktur. Für betriebliche Einblicke nutzen wir Grafana und Prometheus. Zuständigkeiten für Alarme und Reaktionen vereinbaren wir je Kundenumgebung.
Was eine Assurance-Prüfung abdeckt
Der Umfang wird zuerst schriftlich vereinbart: die Anwendung, ihre Schnittstellen, die berührten Daten und was wir testen dürfen. Dann arbeitet die Prüfung durch: Authentifizierung und Session-Handling, Autorisierung und objektbezogene Zugriffe, Eingabevalidierung, Business-Logik, Abhängigkeiten und Konfiguration.
Befunde werden so geschrieben, dass man damit arbeiten kann: betroffener Endpunkt oder Ablauf, das demonstrierte Verhalten, die Bedeutung für Ihre Daten oder Kunden und ein konkreter Behebungspfad. Ein Bericht, mit dem niemand arbeiten kann, ist ein verfehltes Ergebnis.
Methoden, nicht nur Scanner
Automatisiertes Scannen ist die Basis, nicht die Prüfung. Der Wert liegt in der manuellen Arbeit: Missbrauchsfälle durchspielen, die ein Scanner nicht ausdrücken kann, Autorisierungsentscheide zwischen Rollen lesen und kleine Schwächen zu ihrer tatsächlichen Wirkung verketten.
Wir arbeiten nach anerkannten Rahmenwerken - OWASP ASVS für die Anwendungsverifikation und die OWASP Top 10 für Web-Risiken - und weisen das im Bericht aus, damit Entwickler und Prüfer jeden Befund einer Kontrolle zuordnen können.
Referenzen und Dokumentation
Rahmenwerke, denen unsere Prüfungen folgen: OWASP ASVS, OWASP Top 10, NIST SP 800-115 Assessment-Methodik.
Häufige Fragen
Wie unterscheidet sich Security Assurance von einem Penetrationstest?
Ein Penetrationstest simuliert einen Angreifer in Umfang und Zeitrahmen. Assurance ist breiter und kooperativer: Architektur-Review, Code-Prüfungen, Konfiguration und Prozess - oft kontinuierlich neben der Entwicklung statt als einmalige Übung.
Was erhalten wir am Ende einer Prüfung?
Ein Befundbericht mit Reproduktionsschritten, Business-Auswirkung und Behebungsanleitung pro Punkt, plus Abschlussgespräch mit Ihren Engineers. Die Nachprüfung behobener Befunde gehört zum Engagement.
Können Sie ein System prüfen, das ein anderer Anbieter gebaut hat?
Ja - unabhängige Prüfung ist ein Normalfall. Wir brauchen die schriftliche Autorisierung des Eigentümers, Zugang zu Staging und Dokumentation sowie einen Kanal zum Bauteam. Befunde gehen an Sie, nicht an den Anbieter.
Wie oft sollte eine Anwendung geprüft werden?
Mindestens vor grossen Launches und nach wesentlichen Architektur- oder Abhängigkeitsänderungen. Bei aktiv weiterentwickelten Systemen vereinbaren wir meist eine wiederkehrende kompakte Prüfung statt seltener Grossaudits.