はじめに

今回レポートするのは1月15日に開催されたSHIFT EVOLVE『インシデント対応の最適解ってなんだろう (AWSぶっちゃけ討論会 vol.2) 』についてです。

今回は、サイバー演習、組織づくり、障害対応と教育、セキュリティ分野でのAIの使い方などの内容でした。
普段からインシデント対応に携わっていない方にも学びのある内容になっております。
YouTubeでも公開しておりますので、ぜひご覧ください。

インシデント対応の最適解ってなんだろう (AWSぶっちゃけ討論会 vol.2)

パネルディスカッション『インシデント対応の最適解ってなんだろう』

ここからは、当日のセッション内容をまとめていきます。

『インシデントに対応するための取り組み。障害訓練ってどうやるの？』

草間さん「災害の避難訓練と同じで、訓練しているかどうかで、本番で発生したときに初動が速くなるかどうかが変わってきます。」

土佐さん「障害訓練は2019年から毎年10月に行っています。きっかけは、2018年の年末に本番システムを止めてしまうという大障害を起こしてしまったことです。
具体的には全社障害訓練用に専用環境を用意し、そこに攻撃をします。基本的にAWSではなく、自分たちに非がある種類の訓練を行っています。
攻撃のログに気がつけるか、セッションを奪ってみるなどを発生させています。
日付のみを公開し、誰が巻き込まれるか、何が対象の攻撃かは伏せています。
シナリオはセキュリティチームやCISO、CSIRTが考えています。
実際にやってみると、防御のどの部分が弱いのかというのが見えてきます。
面白いのは攻撃のカテゴリーに内部不正もあるのですが、内部不正を疑う攻撃の場合は、お互いに疑心暗鬼になります。
行動履歴はドキュメントにまとめて記録に残しています。」

草間さん「こういう内容は本を読むとだいたい同じ内容になるのですが、実践しきれているケースはなかなかなく、凄いことだと思います。」

土佐さん「実際にやってみると、インシデントに気がつけないことがあります。その場合は、プランB（代替の訓練プラン）を発動させて後続の訓練を行えるようにしています。」

『大規模インシデント発生時のメディア対応の社内体制ってどうしてる？』

大瀧「セキュリティインシデントが起きると、攻撃を受けた被害者であっても、周りから責められたりしますね。」

土佐さん「メディア対応としてはマニュアルを用意しておいて、それに沿った対応を行うようにしています。」

『いざインシデントが起こったら…どう対応している？』

土佐さん「コミュニケーションツールにWAR Room（インシデント対応用のグループ）を作成しています。ドキュメントとして報告用のテンプレートを用意しておき、インシデントが発生すると、入力しなくてはいけない内容がわかるようになっています。」

草間さん「インシデントコマンダーはSREチームの誰か、CSIRT、PSIRTの誰かが選任されるケースなど、ケースバイケースです。」

土佐さん「私たちの組織ではエンジニアの中から委員会を作っています。委員会で曜日ごとの担当を決めています。委員会は任期制にしています。リーダーのみずっと同じで、メンバーは半年ごとの入れ替わり制です。
この仕組みにしてよかったことがあります。普段自分が担当していない他のプロダクトのことを知れる機会があるという点、初動対応の仕組みをメンテナンスできるという点、障害対応を行うことによりエンジニアとしてのスキルがあがる点です。
最初は、メンバーの入れ替わりを行いませんでした。ベテランだけで固めていたんです。やはり、ベテランは初動が速いしメンタルも強い。
しかし、他のメンバーが育たないという問題がありました。任期制にして、メンバーを育てられるようになりました。」

『オススメの監視方法、予兆の掴み方を教えて！』

草間さん「監視したい内容をPagerDutyに入れてください。」

土佐さん「Datadogでメトリクス監視やログの監視を行い、AWS SIEM（※SIEM on Amazon OpenSearch Service）を使い、横断的にログ分析ができるようにしています。」

草間さん「アノマリーディテクション（異常検知）系のAIは引き続き重要だと考えています。内部犯なのか、外部犯（例えばシステムへの侵入など）なのか示唆を得るために、AIが活用され実装は進んでいます。また、生成AIはインシデントが発生したときのコミュニケーションをスムーズにするのに使えると考えています。インシデントが発生したとき、各方面から進捗などの問い合わせが頻繁にくるようになりますが、その部分を生成AIを使い、答えさせるという使い方ができます。」

土佐さん「正規のアカウントからのログインだったとしても、実は攻撃者だったりすることがあります。そのようなケースを見つけるためにサードパーティの製品を使っています。自分たちでもログから不正な動きを検知するために機械学習を使用しています。」

草間さん「今はルールベースの自動化が多いですが、AIエージェントの活用が活発になっていくと、AIで障害の切り分けだったり、報告だったりが行われ始めていくと考えています。」

土佐さん「脆弱性診断も社内でできるようにしています。リリース前の各工程でセキュリティレベルを上げられるようにしています。」

視聴者からの質問

『ビジネス継続性を重視してfail openで対応することを基本方針としているところがほとんどではないか。しかし、セキュリティ要件が高まる中で、これが結果として重大なインシデント拡大やレピュテーションリスクにつながる可能性も。fail open, fail close(※)の判断軸を教えて。具体的にあらかじめリスク許容度の明確化など、やるべきことがあればそれも聞きたい。』

土佐さん「重大なセキュリティインシデントが発生した場合は、システムを落として対応するレベルも想定しています。」

『セキュリティは「狼少年的なビジネス」だと思いますが、どう思いますか？』

草間さん「ベンダー側からはホラーストーリーからの方が実感しやすいため、推しやすいです。」

大瀧「お客様の費用感やどこを守りたいのかはそれぞれ異なるため、『こういうことが発生する可能性は想定できますが、ここまではやる必要ないですよね』というところから入ります。全てを守るという提案をするようなコンサルタントはなかなかいないですね。」

土佐さん「占いでセキュリティツールを導入するのは経営層を説得するのが難しいため『〇〇という脅威を発見します。』というストーリーを作り、説得しています。」

LT『AWSマルチアカウント統制環境のすゝめ』

本番・ステージング・開発など用途ごとのAWSリソースを1つのAWSアカウントで管理してしまうと、権限の設定が煩雑になります。
今回は、複数のAWSアカウントを使用して、用途ごとにAWSリソースを分けるためのAWSサービスであるAWS Control Towerを紹介しました。
また、一段掘り下げて、シングルアカウント／マルチアカウントのメリット・デメリットをそれぞれ紹介し、なんでもマルチアカウントにすればよいわけではないということを解説していました。

下記は、AWS Control Towerシリーズのブログです。
AWSマルチアカウント統制環境の構築（AWS Control Tower シリーズ vol.1
ガードレールの設計（AWS Control Tower シリーズ vol.2
組織単位（OU）の設計（AWS Control Tower シリーズ vol.3
組織間でのAWSアカウントの移行（AWS Control Tower シリーズ vol.4

参加した感想

個人的なことですが、今回のぶっちゃけ討論会3日前に、情報処理安全確保支援士の「実践講習A」を受けていました。
CSIRTの責任者としてセキュリティインシデントに対処することを想定したシナリオが設けられており、CISOへ発生したセキュリティインシデントの概要や、インシデントにより何が起きると予測できるか、外部公開はどこまで行うか、今後の行動などを報告することを実践するワークショップでした。
今回の内容と重なっていた部分があり、個人的にはホットな内容となっていました。
会社でこのようなセキュリティインシデントの報告＋サイバー演習を受けられる機会が定期的にあるのが羨ましかったです。
毎回シナリオを準備するだけでも時間のかかる作業だろうなと思いました。
こういったシナリオは攻撃方法を知らないと作れないですね。
貴重なお時間をありがとうございました。

お問合せはお気軽に

SHIFTについて（コーポレートサイト）

SHIFTのサービスについて（サービスサイト）

SHIFTの導入事例

お役立ち資料はこちら

SHIFTの採用情報はこちら