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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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