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

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

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

X ポスト » | Facebook シェア » | はてブ »

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。 

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

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

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

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

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

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

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

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

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

• 各種脆弱性の評価を改める機会になる

• 特に単体では攻撃に利⽤できないが、他の脆弱性と組み合わせることで被害が拡⼤するもの

• ログの保存や監視・検知等の不⾜部分が浮き彫りになる

• 緊急時のプレイブックや連絡・情報共有の⼿段が正常に機能するかの試験になる

• エンジニアメンバーの調査スキルの訓練になる

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

• エンジニア以外にビジネスサイドや役員まで巻き込んでの開催が望ましいが、開催の調整が困難

• 攻撃シナリオがサービス固有のものになるので他サービスで使い回すことが困難

• 参加メンバーを変えて開催したいが、サービスが改善され脆弱性が塞がれるとシナリオを再利⽤できない

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

• サービスに関わる流出する可能性がある情報を整理

  • IAM ユーザーのクレデンシャル

  • GitHub の Personal Access Token

  • 管理画⾯へのログイン情報

• 流出経路としてあり得るものを整理

  • Slack からの流出

  • Amazon S3 バケットや SaaS の権限設定ミスからの流出

  • フィッシングサイトや悪意をもって改変された OSS からの流出

• 侵⼊経路になりえそうなものを整理

  • インターネットに開放された SSH ポート

  • 意図せずパブリックになったバケット

  • 不必要なサーバーから RDS への経路

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

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

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