STRIDE-Beispiel: ein Industrie-Gateway
Sytance · Aktualisiert
STRIDE umfasst sechs Bedrohungskategorien, mit denen untersucht wird, wie ein System angegriffen werden könnte. Das nachfolgende fiktive Industriegateway veranschaulicht für jede Kategorie ein Szenario mit einer vorgeschlagenen Maßnahme und einem Prüfkriterium. Die Beispiele beschreiben mögliche Angriffe und geplante Prüfungen.
Das Gateway und seine Vertrauensgrenzen
Ein Bediener greift über einen Browser auf die Verwaltungs-API des Gateways zu. Die API liest und schreibt einen lokalen Konfigurationsspeicher. Eine lokale Steuerung sendet Betriebsdaten an das Gateway, das Telemetriedaten an einen externen Dienst weiterleitet. Ein separater Updatedienst stellt Firmwarepakete bereit.
Die Verbindungen für Verwaltung und Telemetrie verwenden in diesem Beispiel TLS. Die Authentifizierung der Steuerungsschnittstelle und der Vertrauensmechanismus für Updates sind noch offene Entwurfsfragen. Ein Anschluss an ein lokales Netzwerk belegt für sich genommen weder die Identität noch die Berechtigung eines Absenders.
- Browser → Verwaltungs-API: Sitzungen, Statusabfragen und Konfigurationsänderungen.
- Verwaltungs-API → Konfigurationsspeicher: gespeicherte Einstellungen und Zugriff auf Geheimnisse.
- Lokale Steuerung → Gateway: Betriebseingaben aus dem Standortnetzwerk.
- Gateway → Telemetriedienst: Geräteidentität und Telemetriedaten.
- Updatedienst → Gateway: Paketmetadaten und Firmwareinhalt.
Identitätstäuschung an der Steuerungsschnittstelle
Ein Angreifer im Standortnetzwerk sendet Nachrichten, die angeblich von der lokalen Steuerung stammen. Vertraut das Gateway ausschließlich einer Quelladresse, können gefälschte Betriebsdaten in den Telemetriestrom gelangen.
Vorgeschlagene Maßnahme: Richten Sie eine Geräteidentität ein und überprüfen Sie sie, bevor Nachrichten angenommen werden. Unterstützt die Steuerung keine Authentifizierung, prüfen Sie andere Möglichkeiten zum Schutz der Schnittstelle und die verbleibenden möglichen Angriffe. Ein Netzwerksegment allein weist den Ursprung einer Nachricht nicht nach.
Prüfkriterium: Nachrichten mit einer nicht erkannten Testidentität werden abgelehnt, während Nachrichten der zugelassenen Steuerung weiterhin funktionieren. Erfassen Sie die Ablehnung und bestätigen Sie, dass der gefälschte Wert den Telemetriedienst nicht erreicht hat.
Manipulation der Firmware vor der Installation
Ein Angreifer ersetzt ein Paket, das über einen kompromittierten Verteilungspunkt bezogen wurde. Eine Transportverschlüsselung bis zu diesem Punkt würde nicht belegen, dass der Hersteller das Paket autorisiert hat.
Vorgeschlagene Maßnahme: Überprüfen Sie vor der Installation die Paketsignatur anhand eines autorisierten Vertrauensankers. Verknüpfen Sie die Prüfung mit den tatsächlich installierten Bytes und dem zulässigen Produkt. Legen Sie separat fest, wie mit älteren signierten Versionen und widerrufenen Signaturschlüsseln umzugehen ist.
Prüfkriterium: Ein verändertes Paket und ein mit einem nicht vertrauenswürdigen Schlüssel signiertes Paket werden vor der Installation abgelehnt. Danach muss sich das Gateway in dem festgelegten Betriebs- oder Wiederherstellungszustand befinden.
Nicht nachvollziehbare Konfigurationsänderungen
Ein autorisierter Bediener ändert das Telemetrieziel, doch der Datensatz enthält weder eine individuelle Identität noch das Ergebnis. Das Team kann die Änderung nicht zuverlässig zuordnen und nicht erkennen, ob ein Schreibvorgang erfolgreich war oder die Anfrage abgelehnt wurde.
Vorgeschlagene Maßnahme: Protokollieren Sie die authentifizierte Identität, Aktion, Zielressource, Zeit und das Ergebnis. Schützen Sie den Protokollzugriff und legen Sie das Verhalten bei vollem Speicher fest. Passwörter oder Zugriffstoken dürfen nicht protokolliert werden.
Prüfkriterium: Eine kontrollierte Änderung erzeugt einen entsprechenden Eintrag, ein unbefugter Benutzer kann ihn nicht bearbeiten und das Prüfverhalten bei vollem Speicher entspricht der dokumentierten Richtlinie.
Geheimnisse werden durch Konfigurationsabfragen offengelegt
Ein Statusendpunkt gibt das vollständige Konfigurationsobjekt einschließlich der Telemetrie-Zugangsdaten zurück. Ein Benutzer, der den Status einsehen darf, erhält Informationen, die seine Rolle nicht benötigt.
Vorgeschlagene Maßnahme: Geben Sie eine zweckgebundene Antwort ohne Geheimnisfelder zurück und erzwingen Sie Berechtigungen für Konfigurationsabfragen. Eine Verschlüsselung bei der Übertragung verhindert keine übermäßig umfangreiche Antwort.
Prüfkriterium: Prüfen Sie Antworten für jede unterstützte Rolle und bestätigen Sie, dass keine geheimen Werte in Antworten, Fehlermeldungen oder Protokollen erscheinen.
Eingabeverarbeitung bringt das Gateway an seine Grenzen
Ein Absender übermittelt übergroße oder wiederholte Nachrichten von der Steuerung. Verarbeitung und Zwischenspeicherung verbrauchen Ressourcen, die das Gateway auch für Verwaltung und Telemetrie benötigt.
Vorgeschlagene Maßnahme: Begrenzen Sie Nachrichtengrößen und Warteschlangen, validieren Sie Eingaben vor aufwendiger Verarbeitung und isolieren Sie kritische Abläufe. Legen Sie Grenzwerte anhand der gemessenen Kapazität und des erforderlichen Verhaltens des Produkts bei Überlast fest.
Prüfkriterium: Führen Sie in einer autorisierten Testumgebung die vereinbarten Überlastfälle durch und beobachten Sie Speicher, Warteschlangentiefe, Dienstverfügbarkeit und Wiederherstellung. Die Akzeptanzgrenzen ergeben sich aus den Anforderungen dieses Produkts; es wird keine allgemeingültige Rate angenommen.
Ein Benutzer mit Leserechten erreicht einen Schreibvorgang
Ein Benutzer kann sich anmelden und den Status einsehen. Er ruft direkt eine API zum Schreiben der Konfiguration auf und umgeht damit die Benutzeroberfläche. Prüft die API nur die Authentifizierung, erhält der Benutzer eine Berechtigung, die Administratoren vorbehalten ist.
Vorgeschlagene Maßnahme: Erzwingen Sie für jeden Schreibpfad serverseitig Berechtigungen für Aktionen und Ressourcen. Wenden Sie dieselbe Regel auf normale Anfragen, Massenoperationen und Wartungsendpunkte an.
Prüfkriterium: Direkte Schreibanfragen eines Kontos mit Leserechten schlagen fehl und die gespeicherte Konfiguration bleibt unverändert. Wiederholen Sie den Vorgang mit einem autorisierten Konto, um zu prüfen, ob die vorgesehene Aktion weiterhin gelingt.
Abdeckung und verbleibende Risiken
Die sechs Kategorien entsprechen den STRIDE-Definitionen von Microsoft. Die Angriffsszenarien und Maßnahmen hängen von der oben beschriebenen Gatewayarchitektur ab.
Ein reales Produkt kann mehrere Angriffsszenarien innerhalb derselben Kategorie aufweisen, und ein Angriff kann zu mehreren Kategorien passen. Die Analyse muss außerdem Schnittstellen für Herstellung, Wartung und Wiederherstellung einbeziehen, sofern das Produkt solche enthält.
Bewerten Sie nach Umsetzung und Prüfung einer Maßnahme die weiterhin möglichen Angriffe anhand der vereinbarten Risikokriterien. Die daraus folgende Entscheidung gilt für das analysierte Produktrelease.