STRIDEの事例：産業用ゲートウェイ
Sytance · 更新日
STRIDEでは、6つの脅威カテゴリを使って、システムがどのように攻撃され得るかを検討します。以下の架空の産業用ゲートウェイの例では、各カテゴリについて、提案する対策と試験基準を添えたシナリオを示します。これらは、起こり得る攻撃と計画中の試験を説明するものです。
ゲートウェイと信頼境界
オペレーターはブラウザーからゲートウェイ管理APIを呼び出します。APIはローカル構成ストアを読み書きします。ローカルコントローラーは運用データをゲートウェイに送り、ゲートウェイはそのデータをリモートサービスに転送します。別の更新サービスがファームウェアパッケージを供給します。
この例では、管理接続とテレメトリー接続にTLSを使用します。コントローラーインターフェースの認証と更新の信頼メカニズムは、引き続き設計上の未決事項です。ローカルネットワークに接続されていることだけでは、送信者のIDや権限は確立されません。
- ブラウザー → 管理API：セッション、ステータス要求、構成変更。
- 管理API → 構成ストア：保存済みの設定とシークレットへのアクセス。
- ローカルコントローラー → ゲートウェイ：サイトネットワークからの運用入力。
- ゲートウェイ → テレメトリーサービス：デバイスIDとテレメトリーデータ。
- 更新サービス → ゲートウェイ：パッケージメタデータとファームウェアの内容。
コントローラーインターフェースでのIDなりすまし
サイトネットワーク上の攻撃者が、ローカルコントローラーからのメッセージであるかのように装ったメッセージを送信します。ゲートウェイが送信元アドレスだけを信頼する場合、偽造された運用データがテレメトリーストリームに入り込む可能性があります。
提案する対策：デバイスIDを確立し、メッセージを受け入れる前に検証します。コントローラーが認証に対応できない場合は、インターフェースを保護する他の方法と、なお可能な攻撃を評価してください。ネットワークセグメントだけではメッセージの送信元を証明できません。
検証基準：未認識のテストIDからのメッセージは拒否され、承認済みコントローラーからのメッセージは引き続き機能すること。拒否の記録を取得し、偽造値がテレメトリーサービスに到達しなかったことを確認します。
インストール前のファームウェア改ざん
攻撃者が、侵害された配布ポイントから取得したパッケージを置き換えます。そのポイントまでの通信を暗号化しても、製造業者がパッケージを承認したことは証明できません。
提案する対策：インストール前に、承認された信頼アンカーを使ってパッケージ署名を検証します。検証対象をインストールするバイト列と許可された製品に結び付けます。古い署名済みバージョンと失効した署名鍵を別途どのように扱うか決定してください。
検証基準：改ざんされたパッケージと信頼されていない鍵で署名されたパッケージが、インストール前に拒否されること。拒否後、ゲートウェイは規定された運用状態または復旧状態を維持する必要があります。
追跡できない構成変更
認可済みのオペレーターがテレメトリーの送信先を変更しますが、記録には個人を識別できる情報も結果もありません。チームは変更の実行者を確実に特定できず、書き込みが成功したのか、リクエストが拒否されたのかも区別できません。
提案する対策：認証済みID、操作、対象、時刻、結果を記録します。ログへのアクセスを保護し、ストレージが満杯になったときの動作を定めます。パスワードやアクセストークンはログに記録しないでください。
検証基準：管理された変更に対応する記録が作成され、未認可ユーザーがその記録を編集できず、ストレージ満杯時の監査動作が文書化されたポリシーに一致すること。
構成の読み取りによるシークレットの露出
ステータスエンドポイントが、テレメトリー認証情報を含む構成オブジェクト全体を返します。ステータスを閲覧できるユーザーが、自分の役割では必要のない情報を受け取ります。
提案する対策：目的に必要な応答だけを返し、シークレットフィールドを除外して、構成の読み取りに権限を適用します。通信経路を暗号化しても、過剰なデータを返す問題は解決しません。
検証基準：サポートされている各役割の応答を調べ、シークレットの値が応答、エラー、ログに含まれないことを確認します。
入力処理によるゲートウェイのリソース枯渇
送信者が、サイズの大きいメッセージやコントローラーメッセージの繰り返しを送ります。解析とバッファリングが、管理やテレメトリーにも必要なゲートウェイのリソースを消費します。
提案する対策：メッセージサイズとキューに上限を設け、負荷の高い処理の前に入力を検証し、重要な処理を分離します。測定した容量と過負荷時に製品が満たすべき動作に基づいて上限を設定してください。
検証基準：認可された試験環境で合意した過負荷ケースを実行し、メモリ、キューの深さ、サービスの可用性、復旧を観察します。合格上限はこの製品の要件に基づきます。普遍的なレートは想定しません。
読み取り専用ユーザーによる書き込み操作
ユーザーはサインインしてステータスを確認できます。そのユーザーがインターフェースを迂回して構成書き込みAPIを直接呼び出します。APIが認証だけを確認する場合、そのユーザーは管理者に限定された権限を得ることになります。
提案する対策：すべての書き込み経路で、サーバー側に操作権限とリソース権限を適用します。通常のリクエスト、一括操作、保守エンドポイントにも同じルールを適用してください。
検証基準：読み取り専用アカウントからの直接書き込みリクエストが失敗し、保存済みの構成が変更されないこと。認可済みアカウントでも繰り返し、意図した操作が引き続き成功することを確認します。
対象範囲と残留リスク
6つのカテゴリは、MicrosoftのSTRIDE定義に基づいています。攻撃シナリオと対策は、上記のゲートウェイアーキテクチャに基づいています。
実際の製品では、1つのカテゴリに複数の攻撃シナリオが含まれることがあり、1つの攻撃が複数のカテゴリに該当することもあります。製品に製造、保守、復旧のインターフェースが含まれる場合、分析ではそれらも対象にする必要があります。
対策を実装して試験した後、合意したリスク基準に照らして、なお可能な攻撃を評価します。その判断は分析対象となった製品リリースに適用されます。