Vertrauensgrenzen und Isolation: Welche Komponente darf auf welche Daten und Funktionen zugreifen?
07 / ARCHITECTURE REVIEW
Product Security Architecture Review
Sicherheitsdesign für Embedded-Systeme, Software und Plattformen
Wir prüfen, ob die Sicherheitsarchitektur Ihres Produkts unter den vorgesehenen Angreiferannahmen trägt. Vertrauensgrenzen, Identitäten, Privilegien, Schlüssel und Wiederherstellung werden zusammen betrachtet – vor der Implementierung oder bei grundlegenden Änderungen.
Prüfumfang
Die Sicherheitsentscheidungen im Zusammenhang prüfen.
Identitäten und Berechtigungen: Wo wird ein Zugriff entschieden und wo wird diese Entscheidung durchgesetzt?
Kompromittierung: Wie weit reichen die Rechte eines übernommenen Geräts, Clients, Dienstes oder Administrators?
Schlüssel und Signaturen: Wer erzeugt, verwendet, rotiert und widerruft Schlüssel?
Boot, Updates und Recovery: Welche alternativen Wege können die vorgesehenen Prüfungen umgehen?
Fehlerfälle und Wiederherstellung: Was passiert bei Ausfällen, verlorenen Schlüsseln oder zurückgesetztem Zustand?
Beispielhafte Fragestellungen
Vom Gerät bis zur eigenständigen Plattform.
Embedded-System
Boot und Recovery müssen dieselben Sicherheitsregeln durchsetzen. Wir prüfen, wie Boot-ROM, Bootloader, Firmware, Secure Element und Update-Dienst zusammenarbeiten und welche Rechte nach einer Kompromittierung verbleiben.
Softwareplattform
Eine Fernwartungsplattform darf einen kompromittierten Kundenaccount nicht zum Zugang zu weiteren Kunden machen. Wir untersuchen Mandantentrennung, administrative Rechte und die Autorisierung zwischen Plattform und Zielsystemen.
Kryptografische Anwendung
Eine Verschlüsselung schützt nur innerhalb ihrer Annahmen. Wir untersuchen, wer Schlüssel und Klartext erreichen kann und ob Kontowiederherstellung oder Schlüsselwechsel die vorgesehenen Schutzgrenzen umgehen.
Zusammenarbeit mit Engineering
Von der offenen Frage zur begründeten Entscheidung.
Sicherheitsfrage festlegen
Welche Entscheidung steht an und welche Schutzwirkung muss das Produkt erfüllen?
Architektur nachvollziehen
Wir besprechen Datenflüsse, Zuständigkeiten, Angreiferpositionen und Abhängigkeiten mit Ihrem Engineering-Team.
Annahmen prüfen
Wir untersuchen Missbrauchsszenarien und Fehlerfälle. Wo nötig, klären wir einzelne Fragen an Code oder Prototypen im vereinbarten Umfang.
Entscheidungen festhalten
Sie erhalten priorisierte Designänderungen und einen Prüfplan für Fragen, die erst an der Implementierung beantwortet werden können.
Hilfreich sind Architekturunterlagen, Datenflüsse, Rollenmodelle und bereits getroffene Sicherheitsentscheidungen. Vollständige Dokumentation ist keine Voraussetzung; fehlende Zusammenhänge erarbeiten wir im vereinbarten Umfang mit Ihrem Team. Für Implementierungsfragen können Codezugang oder Prototypen nötig sein.
Ergebnis
Konkrete Änderungen und nachvollziehbare Gründe.
- Bewertung der vereinbarten Sicherheitsfragen mit nachvollziehbarer Begründung
- Dokumentierte Angreiferannahmen und relevante Vertrauensgrenzen
- Konkrete Designänderungen mit Priorität und technischen Konsequenzen
- Klare Trennung zwischen geprüften Aussagen, offenen Fragen und verbleibenden Risiken
- Gezielter Prüfplan für Code-Reviews, Prototypen oder spätere Sicherheitstests
- Technische Ergebnisbesprechung mit Ihrem Engineering-Team
Wann der Review passt
Bevor Änderungen teuer werden.
- Neue Produktgeneration oder neue Plattform
- Änderung an Identität, Berechtigungen oder Mandantentrennung
- Neues Provisionierungs-, Signatur- oder Updateverfahren
- Entscheidung über Secure Element, Isolation oder Schlüsselverwaltung
- Fernwartung, administrative Zugänge oder neue Integrationen
- Wiederkehrende Befunde, deren Ursache im Design liegt
Architekturreview und Sicherheitstest ergänzen sich.
Ein Architekturreview bewertet das Design und seine Annahmen. Er ersetzt keinen Nachweis, dass die spätere Implementierung diese Regeln tatsächlich durchsetzt. Die Ergebnisse zeigen, welche Codepfade und Systemzustände anschließend gezielt geprüft werden sollten.
Welche Sicherheitsentscheidung steht bei Ihnen an?
Beschreiben Sie Ihr Produkt, den Entwicklungsstand und die offene Frage. Wir klären mit Ihnen, welche Unterlagen und welcher Prüfumfang dafür sinnvoll sind.
Auf Wunsch zuerst NDA.