こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
インシデント対応には、様々な専門分野の知識を必要とし、様々な分野のトレーニングを継続的に受ける必要があります。
本書は、セキュリティ侵害を試みる攻撃者の活動に対し、日常的に予防・検知・対応を行う実務家によって書かれた実務家のための書籍で、2022年1月に発売されました。 今回は訳者の石川 朝久 氏をお招きし、本書の概説をしていただいたのち、実践的な技術の学び方や本書に関連する技術の学び方などをお話しいただきます。
また、ブルーモ証券の取締役CTOの小林 悟史 氏、バックエンドエンジニアの下村 拓 氏にも事例講演としてご発表いただきます。
会の様子
セッション1 〜『詳解 インシデントレスポンス』で学び倒すブルーチーム技術〜
ランサムウェアをもとにした事例研究と本の全体感の紹介
ランサムウェアによる攻撃が発生して3台の被害端末が暗号化されていることが判明し、最低限の処理が済んでいるという事例を題材にインシデント対応に関する話がありました。
まず、インシデント対応をする前にはProcess/People/Technologyの「備え」が重要だという話がありました。
具体的には、指揮命令系統やチームへの連絡係を事前に決めておくことなどが挙げられているということです。
次にトリアージパートとして、目に見える被害はないが同じセグメントにいるなど技術的・論理的に考えて被害を受けた可能性があるサーバの取り扱いにまつわる問題(=スコーピング問題)の話がありました。
こういったときはトリアージを実施するということで、具体的な技術としてWMICやPowerShell、サードパーティ製品などが書籍内で紹介されているということです。
次に保全パートの話がありました。
本の中では、法医学の文脈にあるロカールの交換原理が紹介されているということで、状況に応じてデータの保存手法や保全対象を選定する必要がある*1ということでした。
続いて、解析パートの話がありました。
解析パートでは、ネットワーク・端末間の分析*2と端末・端末のアーティファクト分析*3が紹介されているということです。
最後に改善パートの話がありました。
解析が終わった後は影響範囲と根本原因が判明した後のアクションが記載されているということで、本書では脅威ハンティングなどの手法が紹介されているそうです。
さらなるブルーチーム技術の向上方法
更にブルーチーム技術を上げたいときの方法として、
- 技術を磨く(学習向けのイメージを使って分析練習を行うか、ラボ環境を構築して攻撃→分析を行う)
- 技術をアップデート(DFIR Summitをはじめとしたカンファレンスやブログなどの情報をキャッチアップする)
- 関連技術を学ぶ(Linuxやモバイル・フォレンジック、クラウドフォレンジックといった関連書籍を読む)
の3つが紹介されていました。
セッション2〜東証障害報告書を読み解く〜
障害当日に起こったこと
最初に障害自体の説明がありました。以下、経緯を常体かつ箇条書きで整理していきます。
- 7:04 : NAS1号機でメモリ故障が発生して異常発生のアラートが鳴った。さらに、NAS2号機への切り替えが起きなかった
- 7:06 : 一部端末で売買管理画面、運用管理画面へログイン不可となる
- 7:10 : 富士通に連絡
- ~7:30 : 処理されるべきバッチ処理が行われていないことを確認
- 7:37 : 障害対策本部の設置
- 8:00 : 証券会社から注文が送られてきて受付は正常に処理できたが、売買管理や運用管理画面の操作はできない
- 8:37 : 全銘柄の売買停止を通知
- 8:54 : 証券会社とArrowheadとのロードバランサの接続を強制遮断
- 9:00 : 証券会社との接続は切ったものの、約定処理などは停止できなかった
- 9:11 : 相場情報配信側のロードバランサも切断
障害の原因(NAS1号機からNAS2号機に切り替わらなかった理由)
パニック通知電文受信時のon_panic設定が間違っていたことが障害の根本原因だったという話がありました。
これは、途中でNetAppの仕様変更が入ったことに追従できていなかった(デフォルトの仕様変更があったことに気が付かなかった)が故に発生したということです。
調査委員会の見解
調査委員会としては、誤った仕様変更をしてしまった富士通の責任は重いと考えつつも、テストケースを作れなかった東証の責任も一定数あると判断したそうです。
一方で事故当日の対応に関しては妥当だったという判断をしたということでした。
再発防止策としては、高可用性を堅持しつつ、障害回復力を高めていくことが上げられたそうで、NASをはじめとしたあらゆる機器の点検や切り替え手段のマニュアル整備、網羅的なテストの実施、市場停止や市場再開のルール整備が挙げられたそうです。
セッション3〜ブルーモのインシデントレスポンス〜
ブルーモでは、疑わしき以上は全て報告することと意思決定は全て文書化することが基本ルールとしてあるそうで、そのうえでレスポンスフローを整備したということです。
具体的には、
- 手動アラートによるフィルタリングと集約で判断フローを単純化し、Slack Workflowで自動化
- 判断できる人間が捕まるまでエスカレーションし続ける
- 異常時はチャンネルを自動作成して、ストック情報とフロー情報を分けて整理
- ST環境で1週間実験
という部分を工夫したということでした。
インシデントレスポンスを整理したことで、
- 金融関連かつ少人数の条件でも実践可能なフローは作れる
- フローを可能な限り単純にしてドキュメント化しても浸透はしない
- 業務プロセスの導入やヘンコではドキュメント化に加えて実体験とFBの繰り返しが重要
という学びが得られたということです。
Q&A
セッションの後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。
インシデントレスポンスを的確に行うための事前準備を知りたい
- 訓練や教育を重視している。もしこれが起きたら？という観点でディスカッションを頻繁に行っている
- 障害対応にまつわるいろいろなソースを事前にキャッチアップしておく
- 事故が起きたときに元気になる人を大切にしている
- 意思決定をなるべく早く行えるようにする
インシデントレスポンス未経験者はどう本を読んだらいいか？
- まずは保全の部分を読んでほしい。そのうえで解析パートを読んでもらえるとよい
インシデントレスポンスであったベースラインの把握に効果的な方法はあるか？
- 毎週定期的に監視して差分をチェックする
会全体を通した感想
セッション1でインシデントレスポンスの話を聞きながら、自分が経験した大きな障害である東証の障害を思い描いていたら、次のセッションで東証の障害の話が出てきてめちゃくちゃ驚きました笑
インシデントは起こる前提で日頃からどのように準備していくのか？という部分は非常に重要なので、そこにまつわる体系的な整理や実践事例が聞けてよかったです。
