[レポート]基調講演2:実践的で賢明なインシデント対応計画 – CODE BLUE 2020 #codeblue_jp

CODE BLUE 2020で行われた「基調講演2:実践的で賢明なインシデント対応計画」というセッションのレポートです。
2020.10.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

今回はCODE BLUE 2020で行われた以下のセッションのレポートです。

基調講演2:実践的で賢明なインシデント対応計画

インシデント対応の取り組みの成否は、セキュリティインシデント発生以前に組織が行う計画にかかっている。セキュリティインシデントに先立ち質の高い対応計画を作成することは、組織が成功の重要な要因を考慮し、組織と顧客への影響を最小限に抑えるために専門的かつ効果的に対応する準備ができていることを意味する。この基調講演では、組織や業界に特化したインシデント計画を作成するのに役立つ重要な検討事項にスポットを当てるとともに、セキュリティ侵害やランサムウェアへの対応で直面する一般的な問題についても議論する。

Presented by : ラス・ロジャーズ - Russ Rogers

レポート

(途中からです)

  • インシデントレスポンスのタイムライン
    • Compromise
    • Response
    • Tactical Recovery
      • C2の接続の特定
      • 侵入されたユーザーのクレデンシャルを特定
      • どのようなアセットが使われていたか確認
      • 攻撃者をはじき出す
    • Strategic recovery
      • 長期的な戦略での対応
      • ロギングや検知・ブロッキング
  • 質問
    • どのようにして侵入したのか
      • どのようなベクトルがあったか
    • なぜ気づかなかったのか
      • いつから侵入していたのか
      • どこまで侵入されたか
    • いまその攻撃者が何をしているのか
      • どんなかアカウントやデータにアクセスしているか
    • どんなマルウェアを利用しているか
      • システム管理のバイナリを区別しないといけない
    • 知財などが実際に盗まれたか
  • 伝統的な対応
    • DFIR: Digital Forensics Incident Response
    • Deep forensics
    • 管理において攻撃者を特定するだけでなく法的措置を取る必要がある
    • このやり方はコストと時間がかかる
    • ただ非常に詳細な情報を取得できる
  • IR: Incident Response
    • 2-3週間かけて実施
    • 攻撃者が使ったものを確認していく
    • ここでのゴールはkey indicatorsを早く特定すること
    • ロックダウンすること
    • 業務再開を早くできる効果がある
  • どちらをやるのがいいのか?
    • リスクベースで判断する
    • 速さが必要なのか
    • コンフィグレーション関連の問題として判断してロックダウンをしていく
  • 侵入の検知
    • 非常に重要
    • すぐに気づくには、ネットワークの通常の状態を把握しておく必要がある
      • アプリやネットワークを利用している時間など
    • 今から準備することが必要
      • 侵入されてもよりよく対応できる
      • 効果的に気づくことができる
      • 対応時に過去のデータがないと何が起きたかストーリーをたてられない
      • データが保存されていれば対応のステップで活用できる
  • 何が通常なのか
    • ワークステーションのベースライン
    • サーバーコンフィグのベースライン
    • Windows Serverの通常の状態はなにか
      • どのような設定がされているか
    • サーバーのオペレーションが始まるとどうなるのか
    • 許可されているアプリのリスト
      • 一時的な許可もあるかもしれない
    • どのようなアクセスが外部からあるか
      • IPやネットワーク
      • 何時に接続があるのが通常7日
    • Adminのアカウント、クラウドのアカウントなど
    • 信頼関係は?
      • パートナーは
      • 子会社は
      • 一方通行の信頼か、双方向か
      • パートナーのドメイン管理者はこちらのシステムに来れるのか
      • この信頼関係を利用して侵入してくる可能性もある
      • このようなシステムに対して脆弱性診断をする
    • 重要システムは
      • オペレーション・ビジネスのために重要なシステム
      • どんなデータがあるのか
      • ネットワークのどこにあるのか
      • 誰がアクセスできるのか
  • 3つのデータ
    • 様々な情報をすべてまとめてデータベースにする
      • 何が他と違っているかがわかるようになる
    • 正常な状態を把握していても量は多い
      • 何が興味深いのかわからない
      • 見つけるのは大変
      • 単一のシステムから取ると何がユニークか分かりづらい
    • 単一のコンピュータからはもっと難しい
      • どのように利用されているか
  • ユニークを見つける
    • 不審なログイン
    • 時間
    • バイナリデータ
    • adminツール
    • 不審なユーザ
  • Persistence?
    • 再起動したら再度起動するものもある
    • スタートアップのタスクやスケジュールタスクを確認
  • 攻撃者のツール
    • ツールを置く場所を限定する
    • 検出されることを避けたいため
    • 攻撃者はツールを同じディレクトリに起きがち
    • 4つのシステムに侵入したら全て同じディレクトリにツールを置く
    • ツールはダウンロードできるものを使う事がある
      • Metasploit / Mimikatzなど
    • 例外はランサムウェア
  • セキュリティツール
    • アンチウイルス
    • EDR
      • 特別な特権を無効化したり
      • 単一のダッシュボードにまとめて把握することができる
    • 未知のもの、ATPの場合
      • サービス・バイナリコードをほかとは違うことを特定する
  • 永続性をハント
    • サービス
    • スケジュールタスク
    • カーネルモジュールを確認
    • どのように攻撃者が返ってくるか確認
    • 正常な状態を把握していれば判断しやすい
  • 正常時
    • まったく侵入されないことはない
    • 攻撃者は進化している
    • より早く検知する必要がある
    • どのC2と通信するのか

感想

インシデントレスポンスの基本的な考え方や実践方法が詳しく解説されたセッションでした。

普段から様々なことを収集・モニタリングしていないと異常を検知したり判断できないのはまさにそのとおりですね。

正常時からきちんと対策をしていきましょう!