よりリアルな攻撃で⾏うゲームデーで得たベストプラクティスとは ?

2022-11-02
ビジネス x クラウド

侘美 怜 (メドピア株式会社)

こんにちは、メドピア株式会社 SRE の侘美です。

サイバー攻撃が盛んな昨今、AWS 上にサービス構築し運用するために様々なセキュリティ対策を実施しているかと思います。今回はその中の一例として、メドピア株式会社 (以下、メドピア) で実施しているセキュリティインシデント対応ゲームデーについてご紹介いたします。


ゲームデー

ここで言うゲームデーとは、AWS Well-Architected フレームワーク セキュリティの柱 の中で次のように紹介されているイベントを指します。

ゲームデーは、シミュレーションや演習とも呼ばれ、現実的なシナリオでインシデント管理計画や手順を練習するための体系的な機会を提供する内部イベントです。

メドピアではこのベストプラクティスを参考に、何度かゲームデーを開催してきました。その際に得たノウハウや課題、実際の攻撃シナリオ例などをご紹介いたします。


ゲームデーの概要

メドピアでは下記のようにゲームデーを開催しています。

対象サービス

ゲームデーを開催する度に、対象とする自社サービスを選定しています。主にビジネスインパクトの⼤きいサービスを対象に実施することが多いです。

参加者

  • サービスのビジネスメンバー + 管掌役員
  • サービスの担当エンジニア数名
  • SRE 数名

また、シナリオ作成・攻撃者役・イベントの運営として SRE 1 名が主催しています。

ゲームデーに利⽤する環境

ゲームデーではそのサービスのステージング環境 (テスト環境) を利⽤します。 メドピアではステージング環境は本番環境と同一の構成にしているため、ユーザーに影響なく本番環境と同じ構成を利用した訓練を実現することができます。

攻撃シナリオ

攻撃シナリオは実際にサービスに含まれる脆弱性を利用し、現実的に起こり得るシナリオを作成します。

もちろん、攻撃可能な脆弱性は気付き次第即修正を行っていますので、そのままの状態で攻撃できることはありません。
なので、ゲームデー用にステージング環境に少し脆弱性を追加したり、ログイン情報等が流出した体をとる場合もあります。

ゲームデー当⽇の流れ

ゲームデーは抜き打ちではなく、時間を指定して開催しています。
日時の予告はしていますが攻撃内容や想定シナリオは関係者にも一切伏せられています。
アラートが鳴らない内容のものであれば事前に攻撃をすませています。
開始時刻になったらシナリオに沿ってインシデント発生を通知し、参加メンバーによる調査が行われます。
参加メンバーは設定された終了時刻までに中間報告として調査で判明した被害や攻撃などをレポートします。
最後に振り返り会を実施し、攻撃シナリオの解説やゲームデー中に見つかった課題、今後の対応などをディスカッションして終了となります。


攻撃シナリオ例

過去に社内で開催したゲームデーを⼀例として紹介します。

  • 環境 : ステージング環境 
  • 参加者 : サービス責任者 + ビジネスサイド 4 名、担当役員、サービス担当エンジニア 3 名、SRE 4 名 
  • 実施時間 : 3 時間

攻撃シナリオは次の通りです。

図 1. 攻撃の概要図

① 協業会社の社員 (= 攻撃者) を誤って Slack にゲストユーザーではなく通常のユーザーとして登録してしまう。
攻撃者は Slack の過去の投稿を検索し GitHub の Personal Access Token を入手。

② 攻撃者は取得した Personal Access Token を利用して、GitHub のプライベートリポジトリをクローリングし、SSH 鍵およびデータベース接続情報を入手。
再度 Slack 上の投稿を検索し、上記 SSH 鍵で接続可能な一時的に検証目的で作成された Amazon EC2 インスタンスの IP アドレスや使用するキーペアの情報を取得。

図 2. うっかりインターネットに開放した EC2 インスタンスを作成してその情報を Slack に書き込んだエンジニアの図

③ 攻撃者は取得した SSH 鍵と EC2 の情報を利用し、検証用に一時的に構築された EC2 インスタンスへ接続。

④ 攻撃者が検証⽤ EC2 インスタンス上からネットワーク的に接続可能な範囲を探索し、⼊⼿した鍵で接続可能な EC2 インスタンスを探索。サービスのインスタンスを発見し侵⼊に成功する。バックドアの設置も⾏う。

⑤ 攻撃者が GitHub 上から取得したデータベース接続情報に合致する Amazon RDS が無いか探索。 RDS を発⾒し、接続に成功する。 ユーザー情報が格納されたテーブルを発⾒し、ユーザー情報を抜き出す。

⑥ 攻撃者が抜き出したユーザー情報の一部を記載の上、Twitter 上でメドピアの社長を含む社員数名に DM で犯行声明及び身代金要求を送信。

当日の様子

攻撃役が関係者 Twitter に DM を送信、程なくして社内の Slack で共有されゲームデーが開始されました。ちなみに、ゲームデー用のチャンネル以外では【訓練】を文頭につけることで、非参加者が混乱しないよう配慮しています。

当⽇の様⼦

今回はあえて CTO 不在の中で開催し、不在時の体制などの確認も兼ねることになりました。

当⽇の様⼦

順調に調査が進んでいきました。

当⽇の様⼦

当⽇の様⼦

エンジニアによる調査以外にも、役員と事業責任者によりこの後の対応も協議されていました。

当⽇の様⼦

最終的にはサービスをメンテナンス画⾯に切り替え、制限時間までに判明した事柄を中間報告として報告書にまとめてこの⽇のゲームデーは終了となりました。


ゲームデーのメリットや現状の課題

リアルな攻撃を模したゲームデーを開催することには以下のようなメリットがあると考えられます。

  • 各種脆弱性の評価を改める機会になる
  • 特に単体では攻撃に利⽤できないが、他の脆弱性と組み合わせることで被害が拡⼤するもの
  • ログの保存や監視・検知等の不⾜部分が浮き彫りになる
  • 緊急時のプレイブックや連絡・情報共有の⼿段が正常に機能するかの試験になる
  • エンジニアメンバーの調査スキルの訓練になる

⼀⽅で次のような課題もあることがわかりました。

  • エンジニア以外にビジネスサイドや役員まで巻き込んでの開催が望ましいが、開催の調整が困難
  • 攻撃シナリオがサービス固有のものになるので他サービスで使い回すことが困難
  • 参加メンバーを変えて開催したいが、サービスが改善され脆弱性が塞がれるとシナリオを再利⽤できない

攻撃シナリオの作成⽅法

このようなリアルな攻撃シナリオを準備するためには、脆弱性やサービスの構成に対する深い理解が必要となってきます。 私がゲームデー⽤の攻撃シナリオを作成する場合、まずは以下の情報を整理して攻撃シナリオに利⽤できそうなものを検討しています。

  • サービスに関わる流出する可能性がある情報を整理
    • IAM ユーザーのクレデンシャル
    • GitHub の Personal Access Token
    • 管理画⾯へのログイン情報
  • 流出経路としてあり得るものを整理
    • Slack からの流出
    • Amazon S3 バケットや SaaS の権限設定ミスからの流出
    • フィッシングサイトや悪意をもって改変された OSS からの流出
  • 侵⼊経路になりえそうなものを整理
    • インターネットに開放された SSH ポート
    • 意図せずパブリックになったバケット
    • 不必要なサーバーから RDS への経路

これらの脆弱性のうち攻撃可能なものが放置されているケースはほぼ無いと思いますが、現状の構成にいくつかの設定ミスや新規の脆弱性が追加されることで攻撃が成⽴してしまうことは⼗分にあり得ると思います。

 サービスの既存の脆弱性 + ゲームデー⽤に追加で混⼊させた脆弱性を⽤いて攻撃シナリオを作成することになるでしょう。


まとめ

ゲームデーを開催することで、脆弱性の確認や調査スキルの向上の訓練だけでなく、指揮系統や連絡⼿段等のプレイブックの確認など、実際のインシデント対応さながらの訓練を⾏うことで気づける課題がいくつもあります。 簡単なシナリオかつ少⼈数の参加者からでも効果はあるので是⾮開催をおすすめいたします。


builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

筆者プロフィール

侘美 怜
メドピア株式会社 SRE / セキュリティ テックリーダー

2019 年に⼊社後、モダンかつセキュアなインフラ構築やデプロイパイプラインの作成、AWS Organization を利⽤した複数アカウントのセキュリティ管理などに従事してきました。

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する