公開日2018年12月19日こんにちは!トレンドマイクロの宮林です。2018のインシデントレスポンス関係のセッションに参加しましたので、内容についてご紹介いたします。参加した(しようとした)セッションは下記となります。Forensics(残念ながら中止に...)SEC371については、講師の方がプレゼンテーションをして多数の参加者が拝聴するというセッションではなく、ビルダーズセッションといって、AWSの講師の方お一人と参加者数名がテーブルを囲んでディスカッションする少人数グループセッションでした。最初に参加者全員で簡単な自己紹介をしたのですが、CSIRTやSOCで働いている方がほとんどだったように思います。Responseは切実な課題なのだろうなと伺い知ることができました。監査を実施することもできるが、これらのあるがままの利用を推奨していませんでした。1つ1つを確認しようとするととても大変な作業(寝られない状況)になるからです。それなら、それらのログの一部を自動的に分析するGuardDutyを有効にして、ある条件を満たしたときSNS等で通知したり、Lambdaと連携して対象インスタンスのスナップショットを取得して、対象インスタンスを隔離して、新しいインスタンスを作成(スケール)したりすることも可能だ、ということをお話されていました。インシデントの発見を自動化して、AWSで稼働しているシステムはそのままに、何かしらの脅威が見つかったときに詳細な調査をすればよいのではないか、ということをお話されていたように思います。Forensicsについてはテーマ外だったので深く言及されていませんでしたが、インスタンス隔離が簡単にできるという点と、各種ログに加えてスナップショットやメモリダンプを取得できれば、証拠保全ができますので、後日詳細な調査するための材料を揃えるのは比較的容易なのではないかと感じました。AWSのスナップショットや各種ログはOSとは関連性のないところに保管されていると思いますので、攻撃者によって改変される心配がまずないと言えるかと思います。攻撃者の中にはログを削除し痕跡を残さないようにすることを常套手段にする者もいる為、Forensicsをされる方にとってはクライアント端末の調査をするよりはAWS環境上の準備されたインスタンスの方が調査しやすいのではないかと思われます。Responseに戻させて頂くと、ディスカッションを通じて、監視を自動化することを推奨されているように聞こえました。確かに、各種ログを全てリアルタイムで目視確認することは現実的ではありませんし、重大なアラートがあったとしても予めLambdaでインスタンスを隔離してさらに新しいインスタンスをスケールすることが定義できていれば、(もちろん条件/要件にもよりますが)すぐに誰かが対応しなくても、事業の継続とインシデントレスポンスに必要な情報の保全はできるかと思います。なるとインシデントのトリガーが課題になるのではないかと思います。Security)も使ってインシデントを検出して、通知等の連携をすることも大事な要素になると考えています。Securityで検出したイベントの管理が実現できるようにしていくものと思います。Hub発表時の写真です。わかりづらいですが当社のロゴも画面右下の方にございます)最後にAWSでのインシデントレスポンスはどうなっているのだろうか、と思いセッションに参加させて頂いた結果、AWSの機能(GuardDutyなど)を中心にインシデントに実際に気付く手段は用意されていることを改めて確認することができました。Hubを通して当社含むAPNパートナー製品のログも管理ができるようになり、インシデントに気付く手段は今後も増えていくものと考えられます。当社製品との連携もお試し頂きまして、みなさまのAWS環境を守るお手伝いをさせて頂ければと存じます。reserved.sXpIBdPeKzI9PC2p0SWMpUSM2NSxWzPyXTMLlbXmYa0R20xk。