脅威モデリングSTRIDE/DREAD

EXCEL

脅威モデリング STRIDE/DREAD を活用した実践的セキュリティ対策

STRIDE/DREADに基づいた脅威モデリングは、システムの脆弱性特定と対策優先順位付けに不可欠である。

脅威モデル

システム設計初期段階で脅威モデリングを導入し、潜在的な脆弱性を特定する。データフロー図 (DFD) を用いてシステムコンポーネント、データフロー、信頼境界を可視化し、STRIDEカテゴリ (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) に基づき脅威を列挙する。

例として、Webアプリケーション、バックエンドAPI、データベース、オブジェクトストレージを含むシステムを想定する。

  • Spoofing (なりすまし): APIキー/トークンが漏洩し、攻撃者が正当なサービスになりすます。
  • Tampering (改ざん): Webサイトのパラメータが改ざんされ、不正な操作が行われる。データベースのデータが不正に変更される。
  • Repudiation (否認): 監査ログが不十分で、不正操作を行ったユーザーを特定できない。
  • Information Disclosure (情報漏洩): データベースの機密データが、SQLインジェクションや設定不備により外部に漏洩する。
  • Denial of Service (サービス拒否): APIエンドポイントへの過負荷攻撃やリソース枯渇により、サービスが利用不可になる。
  • Elevation of Privilege (特権昇格): 低権限ユーザーが脆弱性を悪用し、管理者権限を獲得する。

これらの脅威に対し、DREAD評価 (Damage, Reproducibility, Exploitability, Affected users, Discoverability) を適用し、各脅威のリスクレベルを数値化して対策の優先順位を決定する。例えば、SQLインジェクションによる機密情報漏洩は、高いDamageとExploitabilityを持つため、優先的に対処すべき脅威となる。

攻撃シナリオ

上記脅威モデルに基づき、認証情報窃取から機密データ流出に至る攻撃シナリオを構成する。これはMITRE ATT&CKフレームワークのタクティクスとテクニックを応用したキルチェーンとして表現できる。

graph TD
    subgraph 偵察 (Reconnaissance)
        A["ターゲット情報収集: ドメイン, IP, メールアドレス"]
    end
    subgraph 初期アクセス (Initial Access)
        B["フィッシング/XSSによるユーザー認証情報窃取"] --> C["Webアプリケーションへの不正ログイン"]
    end
    subgraph 実行/永続化 (Execution/Persistence)
        C --> D["脆弱なAPIエンドポイント特定/悪用"]
    end
    subgraph 特権昇格/防御回避 (Privilege Escalation/Defense Evasion)
        D --> E["バックエンドサービスAPIキー/シークレット漏洩"]
    end
    subgraph 資格情報アクセス (Credential Access)
        E --> F["クラウド環境アクセス: IAMロール乗っ取り"]
    end
    subgraph 影響 (Impact)
        F --> G["機密データ流出/改ざん"]
    end

    style A fill:#fff3cd,stroke:#e0a800,stroke-width:2px
    style B fill:#d1ecf1,stroke:#007bff,stroke-width:2px
    style C fill:#d1ecf1,stroke:#007bff,stroke-width:2px
    style D fill:#d4edda,stroke:#28a745,stroke-width:2px
    style E fill:#d4edda,stroke:#28a745,stroke-width:2px
    style F fill:#f8d7da,stroke:#dc3545,stroke-width:2px
    style G fill:#f8d7da,stroke:#dc3545,stroke-width:2px

このシナリオでは、攻撃者はまずターゲットの情報を収集し（A）、フィッシングやクロスサイトスクリプティング（XSS）を通じて正当なユーザーの認証情報を窃取する（B）。窃取した認証情報でWebアプリケーションに不正ログインし（C）、その後、アプリケーション内の脆弱なAPIエンドポイントを特定して悪用する（D）。この悪用を通じて、バックエンドサービスが使用するAPIキーやシークレット情報を漏洩させ（E）、最終的にクラウド環境のIAMロールを乗っ取ることで（F）、機密データの流出や改ざんを実行する（G）。

検出/緩和

上記の攻撃シナリオに対し、多層防御の観点から検出と緩和策を導入する。

  • 初期アクセス: WAFによるXSS対策、MFA強制、セキュアな認証基盤の利用。
  • 脆弱なAPIエンドポイント悪用: APIゲートウェイによるレートリミット、入力検証、OWASP API Security Top 10に基づく脆弱性対策。
  • 認証情報漏洩/特権昇格: 最小権限原則の徹底、定期的な脆弱性スキャン、SAST/DASTによるコード分析。
  • データ流出: データベース監査ログ、SIEM連携による異常検知、データ分類と暗号化。

暗号やプロトコルの誤用例と安全な代替

暗号化やプロトコルは正しく実装しないと、重大な脆弱性となる。

誤用例

  • 古い/安全でないハッシュ関数の利用: MD5やSHA1は衝突攻撃のリスクが高く、パスワードハッシュには不適切である。

    # NG: MD5ハッシュの利用 - 衝突攻撃に弱い
echo "password123" | md5sum

  • 平文での機密情報送信: HTTPプロトコル上での認証情報や機密データのやり取り。

    # NG: HTTPで機密情報を送信 - 中間者攻撃で窃取されやすい
curl http://example.com/login -d "username=admin&password=secret"

  • ハードコードされた鍵/証明書: アプリケーションコード内に秘密鍵やパスワードを直接記述する。

    # NG: 秘密鍵のハードコード - ソースコードが漏洩すると全ての機密情報が危険に晒される
SECRET_KEY = b'Sixteen byte secret key for AES'

  • 不適切な暗号モード: AESのECBモードは、同じ平文ブロックが同じ暗号文ブロックになるため、パターンが残りやすい。

    # NG: AES-ECBモードの使用 - パターンが残るためデータ構造が推測されるリスク
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.backends import default_backend
key = b'Sixteen byte key'
cipher = Cipher(algorithms.AES(key), modes.ECB(), backend=default_backend())
# ...暗号化処理...

安全な代替

  • 現代的なハッシュ関数: パスワードハッシュには、ソルトとストレッチングを伴うArgon2, bcrypt, scryptを使用する。データ整合性確認にはSHA256, SHA3。

    # OK: SHA256ハッシュの利用 (パスワードにはArgon2/bcryptを推奨)
echo "password123" | sha256sum

  • TLS/HTTPSの強制: 全ての通信にHTTPS (TLS 1.2/1.3) を適用し、HSTS (HTTP Strict Transport Security) を有効にする。

    # OK: HTTPSで機密情報を送信 - 通信が暗号化され、中間者攻撃が困難になる
curl https://secure.example.com/login -d "username=admin&password=secret" --HSTS

  • 鍵管理システム (KMS) の利用: シークレットはKMS (AWS KMS, Azure Key Vault, HashiCorp Vaultなど) から動的に取得する。環境変数も一時的な代替策だが、KMSが推奨される。

    # OK: KMSまたは環境変数から鍵を取得 - コードと鍵の分離
import os
# 実際にはAWS KMS, Azure Key Vault, HashiCorp Vaultなどから取得することを推奨
# api_key = get_key_from_kms("my_app_api_key_id")
api_key = os.getenv("APP_API_KEY", "default_safe_value")
if api_key == "default_safe_value":
    raise ValueError("API Key not found in environment variables.")

  • 認証付き暗号 (AEAD): AES-GCMなど、機密性だけでなく完全性と認証を提供するモードを使用する。

    # OK: AES-256-GCMモードの使用 - 機密性、完全性、認証を提供
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.backends import default_backend
import os

# 鍵はKMSやシークレットマネージャーから安全に取得することを想定
key = os.urandom(32) # デモ用、実運用ではKMS等を利用
iv = os.urandom(12)  # GCMではIVはNonceとして使用、繰り返し利用しない

cipher = Cipher(algorithms.AES(key), modes.GCM(iv), backend=default_backend())
encryptor = cipher.encryptor()
# 追加認証データ (AAD) は暗号化されないが、認証タグに含まれる
encryptor.authenticate_additional_data(b"version_1.0_user_id_123")
ciphertext = encryptor.update(b"this is a secret message") + encryptor.finalize()
tag = encryptor.tag

print(f"Ciphertext (Hex): {ciphertext.hex()}")
print(f"Authentication Tag (Hex): {tag.hex()}")

鍵の生成にos.urandom()を使用しているが、これはテスト目的であり、実運用ではKMSなどのセキュアな鍵生成・管理機構を利用すべきである。

運用対策

鍵/秘匿情報の取り扱い

鍵や秘匿情報のライフサイクル管理はセキュリティの根幹をなす。

  1. 鍵管理システム (KMS) の利用:
    • 全ての暗号鍵、APIキー、シークレットは、AWS KMS, Azure Key Vault, Google Cloud KMS, HashiCorp Vaultなどの専用サービスで管理する。これにより、鍵の生成、保存、利用、ローテーション、破棄を一元的に、かつセキュアに実行できる。
    • 根拠: 平文での保存やハードコードを排除し、鍵のライフサイクルを自動化・監査可能にするため、運用の安全性と効率性を確保する。
  2. 鍵のローテーション:
    • 定期的な鍵のローテーションポリシーを確立する (例: 90日ごと、または年1回)。鍵が漏洩した疑いがある場合は即座にローテーションを実施する。
    • 注意喚起: ローテーションを怠ると、万が一鍵が漏洩した場合の影響範囲が長期化・拡大し、対策コストが増大する。
  3. 最小権限の原則:
    • 鍵へのアクセス権限は、必要なユーザーやサービスアカウントにのみ付与し、その権限を最小限に制限する。例えば、暗号化のみを許可し、復号化は特定のサービスのみに限定する。
    • 根拠: 攻撃者がシステムに侵入しても、鍵への不正アクセスや悪用を困難にし、被害範囲を限定する。
  4. 監査と監視:
    • KMSの操作ログ (鍵の作成、利用、削除、アクセス試行) を常時監視し、SIEM (Security Information and Event Management) と連携して異常なアクセスパターンや失敗した試行をリアルタイムで検知する。
    • 注意喚起: ログが適切に収集・分析されていなければ、鍵の不正利用を検知できず、攻撃の兆候を見逃す可能性が高まる。

現場の落とし穴

セキュリティ対策には技術的な課題だけでなく、運用上のリスクも伴う。

  • 誤検知と可用性のトレードオフ:
    • WAFやIDS/IPSの厳しすぎるルールは、正当なユーザーアクセスをブロックし、サービスの可用性を低下させる可能性がある。チューニング不足は運用負荷を高め、アラート疲労を招く。
    • 対策: リスクベースアプローチでルールのバランスを取り、A/Bテストや監視体制を整備して影響を最小限に抑える。
  • 検出遅延と攻撃の隙:
    • SIEMへのログ転送遅延や、複雑すぎる相関ルール、アラートの優先順位付けの不備は、攻撃の検出を遅らせる。攻撃者はその間に内部で横展開を進める。
    • 対策: ログのリアルタイム転送を徹底し、優先度の高いアラートは自動化された応答フローと連携させることで、平均検知時間（MTTD）を短縮する。
  • セキュリティ設定の陳腐化:
    • システムやアプリケーションの更新、新規サービス導入時にセキュリティ設定が見直されず、古い設定が残存することがある。これは新たな脆弱性の温床となる。
    • 対策: CI/CDパイプラインにセキュリティレビューを組み込み、定期的なセキュリティ監査と設定レビューを義務化する。
  • シャドーITと非管理アセット:
    • 部門や個人がIT部門の承認なしに導入するサービスやデバイスは、セキュリティポリシーの適用範囲外となり、重大なセキュリティホールとなる。
    • 対策: 定期的な資産棚卸し、CASB (Cloud Access Security Broker) の導入、セキュリティ意識向上トレーニングによって、非管理アセットのリスクを低減する。

まとめ

脅威モデリングSTRIDE/DREADは、開発ライフサイクルの早期に潜在的なセキュリティリスクを特定し、効果的な対策を講じるための不可欠なプロセスである。技術的な対策だけでなく、鍵管理、最小権限の原則、厳格な監査、そして運用上の落とし穴に対する認識と対策が、システムの堅牢性を維持するためには不可欠である。セキュリティは一度きりの活動ではなく、システムの変化と脅威環境の進化に対応する継続的なプロセスとして取り組むべきである。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました