SECURE BY DESIGN
Security Architecture Review
für Medizinprodukte
Erkennen Sie die Security-Entscheidungen, die später teuer werden, solange sich Ihre Architektur noch ändern lässt. Gemeinsam mit den Menschen, die Ihr Produkt bauen, prüfen wir Trust Boundaries, Abuse Paths und Blast Radius.
Eine funktionierende Architektur ist nicht automatisch eine sichere Architektur
Die meisten Teams testen, ob der vorgesehene Workflow funktioniert. Angreifer testen, was dieselben Komponenten sonst noch erlauben. Eine fehlende objektbezogene Autorisierungsprüfung, ein schwach gebundenes Token oder ein überprivilegierter Worker sind einzeln kleine Findings, verkettet aber eine vollständige Kompromittierung.
Je später ein Designfehler gefunden wird, desto teurer wird die Behebung.
Was in der Designphase eine Whiteboard-Diskussion kostet, wird nach der Implementierung ein Rework-Sprint und zum Release-Blocker, sobald ein Pentest, ein Audit oder ein Kunden-Assessment es findet. Teams in der Frühphase profitieren am meisten: Ihre Architektur lässt sich noch günstig ändern.
Der Zweck des Reviews ist, diese Angriffsketten zu finden und zu durchbrechen, solange eine Designänderung noch eine kleine Entscheidung ist und kein Projekt.
Der beste Zeitpunkt ist, bevor Security zum Release-Blocker wird
Fünf Momente, in denen sich ein Architecture Review bezahlt macht:
Neues Produkt oder großes Feature
Assets, Akteure und Trust Boundaries identifizieren, bevor die Implementierung Annahmen zementiert. Für Teams in der Frühphase ist das die günstigste Security-Arbeit, die sie je einkaufen werden.
Architekturänderung
Einen neuen Identity Provider, eine Cloud-Komponente, eine Integration, einen AI-Service oder einen Datenfluss bewerten, bevor er live geht.
Vor einem Pentest
Vermeidbare Designprobleme vorab beseitigen, damit bezahlte Testzeit in tiefe Angriffspfade fließt statt in die Dokumentation bekannter Schwächen.
Vor MDR- oder Kundenprüfung
Technische Security-Argumentation und Verantwortlichkeiten explizit machen, bevor eine Benannte Stelle oder das Security-Team eines Kunden danach fragt.
Nach einem gravierenden Finding
Die architektonische Ursache beheben und den Blast Radius reduzieren, statt einen einzelnen Endpoint zu patchen.
Was Ihr Team erhält
- Priorisierte Architekturrisiken und die Annahmen dahinter, live mit Ihrem Team diskutiert
- Pragmatische Empfehlungen, die zu bestehendem Produkt und Team passen
- Eine kompakte schriftliche Zusammenfassung: Entscheidungen, offene Fragen und die nächsten sinnvollen Validierungsschritte
Das Format ist bewusst leichtgewichtig: eine fokussierte Session von rund zwei Stunden plus kurze schriftliche Zusammenfassung, kein formaler Auditbericht und kein Zertifizierungspaket.
Das Review wird auf Ihren Pentest angerechnet
Buchen Sie innerhalb von 12 Monaten nach Ihrem Architecture Review einen Penetrationstest bei uns, wird die Review-Gebühr vollständig angerechnet. Die frühe Designarbeit kostet Sie auf dem Weg zu getesteter, auditfester Evidenz nichts extra.
So führen wir MDR-Penetrationstests durch →Treffen Sie die nächste Architekturentscheidung mit dem Abuse Path im Blick
Erzählen Sie uns, was Sie bauen, welche Entscheidung gerade ansteht und wo die Unsicherheit sitzt. Wir antworten mit dem sinnvollsten nächsten Schritt, auch wenn das kein Architecture Review ist.
Telefon
+49 221 65031192Antwortzeit
Wir antworten in der Regel innerhalb von 24 Stunden an Werktagen auf alle Anfragen.
Durchschnittliche Antwortzeit: 6-12 Stunden
In der Praxis bewiesen
Keine Theorie: Hier sind Schwachstellen, die wir in produktiver Software für Healthcare und kritische Infrastruktur gefunden und verantwortungsvoll offengelegt haben.
gematik lib-vau / lib-vau-csharp
VAU-Handshake führt nur 2 von 6 vorgeschriebenen Server-Schlüssel-Prüfungen aus
Eine fehlende Server-Authentifizierung in einem Protokoll-Client: genau die Klasse von Trust-Boundary-Designfehler, die ein Architecture Review vor der Implementierung abfangen soll.
gematik Authenticator
Hijacking des Authentifizierungsablaufs
Client-Authentifizierungsabläufe in der deutschen Telematikinfrastruktur: eine Designannahme darüber, wer am anderen Ende eines Kanals steht, die nicht gehalten hat.
OHIF Viewer
OIDC-Token-Diebstahl durch extern kontrollierte URL
Von der CISA veröffentlicht. Verarbeitung von Authentifizierungs-Token in einem webbasierten DICOM-Viewer: wie sich Session- und Token-Entscheidungen an der Grenze zwischen Gerät und Browser auswirken.
DCMTK storescp
OS Command Injection durch Platzhalter-Substitution
OS Command Injection über eine als vertrauenswürdig behandelte Netzwerkschnittstelle: was passiert, wenn Eingaben an einer Trust Boundary als harmlos angenommen werden.