この記事はコインチェック株式会社（以下、コインチェック）のアドベントカレンダー23日目（シリーズ1）の記事です。
https://qiita.com/advent-calendar/2024/coincheck
コインチェック セキュリティ部の喜屋武です。
本記事では、暗号資産交換所への脅威にどういったものがあるのか、脅威モデリングのフレームワークを用いて考えてみたいと思います。
なお、本記事中で実施する脅威モデリングは、筆者が本記事を執筆するにあたり試験的にシミュレートしたものであり、実業務の中で脅威モデリングを行った結果ではないことを注記しておきます。
1. 脅威モデリングとは
脅威モデリングとは、システムを構成する様々な要素に対し、潜在的な攻撃手法や脆弱性を洗い出すと同時に、それらが引き起こしうるリスクを評価しながら、最適な対策を検討するプロセスのことを指します。これを開発や設計の初期段階から行うことで、リリース後に「ここが抜け穴だった」という発見を最小限に抑え、問題が顕在化する前に効果的な防御策を講じることができるとされています。
本来は、開発や設計の初期段階から脅威モデリングを行うことで、リリース後に発覚するセキュリティ上の抜け穴を最小限にすることが目的です。しかし、一般的な事業会社では、セキュリティ専門家が最初からプロジェクトに参画していることは少なく、開発や設計の段階から脅威モデリングの手法を用いることは難しい会社が大多数だと思います。
とはいえ、すでに稼働中のシステムに対しても脅威モデリングを行うことも有効です。稼働中のシステムに脅威モデリングを適用することで、導き出されたリスクに対して実装済みの対策を当てはめ、攻撃手法や脆弱性への対策の漏れがないかを客観視することができ、対策の網羅性を確認することができます。
2. STRIDEのフレームワークに当てはめて考えてみる
実際に脅威モデリングを行う際は、補助してくれるツールを活用したり、フレームワークを用いて実施するのがおすすめです。Microsoft Threat Modeling Toolは、DFDをもとに潜在的な脅威を自動的に提示してくれるため、初心者にとっても分かりやすいツールです。
脅威モデリングでは、脅威を網羅的かつ体系的に洗い出すために、いくつかの代表的なフレームワークが存在します。その中でも有名なのが、Microsoftによって提唱された「STRIDE」モデルと、「PASTA」と呼ばれる手法です。
STRIDEは「Spoofing（なりすまし）」「Tampering（改ざん）」「Repudiation（否認）」「Information Disclosure（情報漏えい）」「Denial of Service（サービス拒否）」「Elevation of Privilege（権限昇格）」の頭文字を取ったもので、これら6種類の脅威カテゴリを基準として脅威を体系的に識別します。STRIDEは比較的シンプルで、初学者や非セキュリティ専門家にも理解しやすくなっています。
PASTAは脅威モデリングの手法のひとつです。PASTAはビジネスリスクやアーキテクチャ的要因、実際の攻撃パターンなどを包括的に考慮することで、より現実的かつ戦略的なセキュリティ強化につなげることを狙いとしています。
今回は、以前発表した下記の資料中に記載の簡単なシステム構成をベースに、STRIDEを用いてどういった脅威があるのかを簡単に洗い出しみたいと思います。
脅威モデリングに限らず、脅威を洗い出す際には、何を守りたいかを最初に定義しないと内容が発散してしまいがちになります。今回は、守りたい対象を、ユーザーから預かっている暗号資産と定義して脅威モデリングの脅威の識別を行ってみます。
- Spoofing（なりすまし）
- 脅威例：攻撃者が正規ユーザーを装ってログインし、ユーザーアカウントから資産を不正送金する。
- 考えられる原因：
- 弱いパスワードやパスワードリスト攻撃によるアカウント乗っ取り
- MFA（多要素認証）の未実装や回避手段セッションハイジャック（盗聴したセッショントークンによる不正アクセス）
- ユーザーへのフィッシング攻撃
- 対策案：
- 強力な認証・認可スキーム（パスワードポリシー、MFAの必須化、レートリミット、パスキー）
- セキュアクッキー・HTTPSによるセッション保護
- 不審なログイン試行のモニタリングとアラート
- Tampering（改ざん）
- 脅威例：攻撃者がシステム間の通信（APIリクエスト）を改ざんし、本来許可されていない量の資産の送金トランザクションを実行する。
- 考えられる原因：
- HTTPSで保護されていない通信路適切な署名やリクエスト検証が行われていないAPIエンドポイント
- 対策案：
- 通信路の暗号化(HTTPS/TLS)
- APIリクエストへの署名・検証機能の実装（HMAC、JWT署名）
- サーバーサイドでのパラメータバリデーション徹底
- Repudiation（否認）
- 脅威例：ユーザーを装った攻撃者が「自分はそのトランザクションを行っていない」と主張し、後から送金や取引を否認できてしまう。
- 考えられる原因：
- 適切な監査ログが残っていないログの改ざん対策が不十分
- 対策案：
- 不可逆的な監査ログの保存(改ざん困難なストレージやブロックチェーン技術の活用)
- ログイン時・トランザクション実行時の強固な本人確認
- 行動履歴を参照しやすいUIやアラート機能の提供
- Information Disclosure（情報漏えい）
- 脅威例：データベースへの不正アクセスやAPIの脆弱性（SQLインジェクションなど）によって、トランザクションの署名に関する情報が外部に漏れてしまう。
- 考えられる原因：
- データベースやAPIへの不正アクセス入力値検証不備によるインジェクション攻撃
- バックエンドと署名を行うシステム間通信の暗号化不足
- 対策案：
- 入力値検証・プリペアドステートメントによるインジェクション対策
- アクセス制御とIAM（Identity and Access Management）の厳格化
- 機密情報暗号化（秘密鍵・トークン類の保護）
- Denial of Service（サービス拒否）
- 脅威例：DDoS攻撃によって取引所サイトやAPIが過負荷状態になり、ユーザーの正当なリクエストを処理できなくなる他、ブロックチェーンネットワークとの同期やトランザクションのブロードキャストが行えなくなる。
- 考えられる原因：
- 大量の無効リクエストを捌けないスケーリング不足キャパシティプランニングの不備
- 対策案：
- CDNやWAF(Web Application Firewall)のDDoS対策機能によるトラフィック軽減
- オートスケール機能や負荷分散で高可用性を確保攻撃兆候を検知し、IPブロックやレートリミットを適用
- Elevation of Privilege（権限昇格）
- 脅威例：一般ユーザー権限しかないはずの攻撃者が、アプリケーションやシステムコンポーネントの脆弱性を突いて管理者権限を取得し、ユーザーデータ改ざんを行う。
- 考えられる原因：
- サーバーサイドの認可チェック不足アプリケーションサーバーや運用ツールの脆弱性悪用
- 対策案：
- ロールベース・ポリシーベースのアクセス制御（RBAC/ABAC）の徹底
- 管理者機能への多要素認証と追加認可
- システムやミドルウェアの定期的なパッチ適用と脆弱性スキャン
以上はSTRIDEモデルに基づく脅威識別の一例です。今回は筆者が簡単にSTRIDEの各脅威モデルに対する脅威と対策を考えてみました。
3. まとめ
実際には、システムで利用するプロトコルやサービス、外部連携や内部者リスク、クラウド環境特有のセキュリティ要件など、さらに多くの観点から脅威を洗い出す必要があります。脅威をリストアップした後は、各脅威についてリスク評価（発生可能性や影響度の推定）を行い、優先度を決めて対策を講じていく必要があります。
今回はSTRIDEをベースに考えましたが、PASTAなどのアプローチや、OWASPのガイドライン、MITRE ATT&CKフレームワークなどを併用することで、より現実的な脅威分析が可能となるでしょう。
すでに稼働中のシステムであっても、脅威モデリングを実施することで、新たな攻撃手法への対策や既存対策の見直しに役立てることができます。
以上が、暗号資産交換所への脅威をSTRIDEに当てはめて考えてみた一例です。今回はあえて、暗号資産特有の、秘密鍵の管理に関する脅威については直接論じてはいません。
しかしながら、こう見てみると、暗号資産交換所も暗号資産特有の秘密鍵の管理に関わらず、一般的なサービスとして晒されている脅威への対策も行わなければならないことが分かると思います。
コインチェックのセキュリティ部では絶賛採用活動中です。ブロックチェーンに限らず通常の脅威への対策も行わなければならないため、ブロックチェーンの経験がない方でも問題なく、ご応募お待ちしております。
