[レポート]会場参加型リアルタイムインシデントレスポンスなチョークトーク – Amazon Security LakeとJupyterノートブックでサイバーセキュリティを強化する #AWSreInvent #SEC318

気がついたらインシデントレスポンスに参加していたセッションのレポートです。めっちゃためになるぞ!
2023.12.27

こんにちは、臼田です。

みなさん、re:Invent 2023楽しかったですか?(挨拶

今回は下記のセッションのレポートです。このチョークトークセッションはとにかく楽しいです!

後ほど詳しく説明しますが、チョークトークに参加している全員が多数決で、実際に発生しているインシデントに対して調査方針を決めながら進んでいくインシデントレスポンスのセッションです!調査の際にどのように考え進めていけばいいかを実践的に学べます。

SEC318 | Fortify cybersecurity with Amazon Security Lake and Jupyter notebooks

This chalk talk explores the combination of Amazon Security Lake and Jupyter notebooks for investigating security events. Explore the process of aggregating security logs into a centralized repository and using Amazon SageMaker and Jupyter notebooks for live incident response. See the construction of a Jupyter notebook as well as running queries, analyzing data, and completing the incident response cycle. By integrating code, analysis, and documentation, this approach streamlines incident response and enhances security capabilities. Join this talk to discover the power of Amazon Security Lake and Jupyter notebooks in effective security event investigation.

SEC318 | Amazon Security Lake と Jupyter ノートブックでサイバーセキュリティを強化する

このチョークトークでは、セキュリティ イベントを調査するための Amazon Security Lake と Jupyter ノートブックの組み合わせについて説明します。 セキュリティログを集中リポジトリに集約し、Amazon SageMaker と Jupyter ノートブックをライブインシデント対応に使用するプロセスを調べます。 Jupyter ノートブックの構築、クエリの実行、データの分析、インシデント対応サイクルの完了をご覧ください。 このアプローチは、コード、分析、および文書化を統合することにより、インシデント対応を合理化し、セキュリティ機能を強化します。 このトークに参加して、効果的なセキュリティ イベント調査における Amazon Security Lake と Jupyter ノートブックの力を発見してください。

要約

全員参加型のインシデントレスポンスちょーたのしい。

チョークトークは現地でしか味わえないので来年是非参加してみてください。

レポート

セッション会場に着くと、すべての座席にこれが置かれていました。この段階で何かを察します。

はじまりました。

アジェンダはさっぱりしてます。

  • インシデントレスポンスツール
  • ライブインシデントレスポンス
  • まとめ

分析のアーキテクチャはこんな感じ(ぶれててすいません)。Amazon Security Lakeで保存したデータにAthenaからクエリをかけるんですが、クエリはSageMakerのノートブックから実行します。

なんでノートブック(Jupyter notebooks)を利用するのか、いろいろメリットはありますが、作業をいろいろしながら調査したり情報をまとめるのに結構向いています。

インシデントレスポンスのライフサイクルはこんな感じ。

まずインシデントが発生する前にしっかり準備して、インシデントが発生したことを検知して調査、封じ込め・根絶・復旧を行って、事後対応をしてまた備えるという流れです。これはNIST SP800-61で定義され日本語版もありますので見てみてください。

早速ライブインシデントレスポンスの開始です。

今回のインシデントレスポンスは会場全員で意思決定します。途中で赤か青の選択肢を提示するので、会場のみんなでどちらにするか札を上げて選びます。多数決で進行していきます。だから、2色の札を配布しておく必要があったんですね。

インシデントの概要から。アクセスキーが外部公開されていることをTrusted Advisorのアラートで気づきます。どうやらいろいろやられてしまっている様子。

このJupyter notebookではインシデントレスポンスのために必要な手順や実行コマンドがまとまっています。このノートブック通りに調査を進めていきます。

ノートブックを使ういいところは、手順書として作り込んで置けること、Markdownでいい感じにリッチな表現などが簡単に使えること、そして直接コマンドを実行して、その結果も合わせて保持できることなどがあります。

まずは今回のアクセスキーを利用してAthenaでクエリをかけてみます。クエリはCloudTrailのログから実行した内容を確認するもの。ログ自体はAmazon Security Lakeが収集しています。

クエリを実行した結果が表示されました。スクロールしていくと、IAMに関するアクティビティがいろいろあることがわかります。

ホワイトボードに整理していきます。どうやら漏洩したアクセスキーから権限昇格され、新しいユーザーが作成され、そちらでもアクセスキーが作られています。

それでは次のアクセスキーを調べていきます。同じようにクエリコマンドを実行すると、今度はRunInstanceを実行してEC2インスタンスをたてています。おやおやおや〜これはやられていますね!

と、ここで選択肢です。更にCloudTrailのログを調べていくか、それともこのEC2インスタンスを調査するか?

会場はさらなるログの調査を選択します。

他にもログを辿っていくと、S3バケットも作られていれば新たなアクセスキーも作られています。やりたい放題ですね!全体感が見えてきてこちらの選択肢が正解だったかも?

ここでも選択肢。調査を継続するか、封じ込めを行うか。

一旦封じ込めを行います。

アクセスキーを無効化し、削除していきます。どんな時でも無効化から入る、大事ですね。

少し話はそれますが、こんな時に利用するノートブックはGithubにも上がっているのでぜひ活用してください。

EC2のフォレンジックも行っていきます。EC2は消さないでまずはAMIを作成して保全をしましょう。

そしてその証跡をスクショして、ノートブックに作業履歴として保存します。これもノートブックのいいところ。

なんやかんや他にも色々ありましたが、板書はこんな感じ。

シナリオとしてはこんな感じになっていました。途中で攻撃者が作ったアクセスキーを削除して調査のじゃまになるログを残したりしていました。

参考情報のリンクが色々あります。

まとめ

会場参加型のインシデントレスポンスはちょー面白かったです。用いた手法もリンクも参考になるのでぜひ活用してください。

そして、参加する機会があったら絶対に参加しよう!(今回はセッション概要からはこうなるとは分からなかったので注意)