訓練が始まったのは10月末のとある週末。茂岩CISO率いるセキュリティチームが異常に気付いたきっかけは、ログイン状況の監視ツールが発したアラートだった。「訓練があることは知っており、ある程度心構えはあった。前職では不正ログインの疑いがあるときの対応も経験していたので、アラートを見て『あ、こういうのが来たか』という感じだった」(茂岩CISO)
次に取り組んだのは、セキュリティインシデントの発生を発令し、関係者を集め「何が起きたのか」「どんな情報が漏えいした可能性があるか」を突き止める作業だ。
Webサイトからの顧客漏えいが起きた場合、原因はいくつか考えられる。1つ目は「リスト型攻撃」だ。他の事業者から漏れたアカウント情報を元にアクセスが試行され、もしユーザーがパスワードを使い回している場合には不正アクセスを許してしまう。
2つ目は、今回のシナリオで採用したフォーム改ざんだ。ユーザーが入力した情報がそのまま攻撃者に渡ってしまうもので、最近では、この手法を用いたクレジットカード番号の漏えいが多発している。
3つ目はWebアプリケーションの脆弱性を突かれるなどしてインフラに侵入され、データベース内の情報が丸ごと抜き取られるパターンだ。
今回はフォーム改ざんによる漏えいという設定だったが、原因を突き止めるにはやはりログがものをいう。残念ながら訓練の前提条件が行き渡らず、多田さんたちが要望に応じて提供を考えていたログ、つまり状況証拠を出すところまではシナリオは進まなかった。ただ、原因を分析するところまでは進められたという。
「例えば、大量のログイン試行失敗のログがあれば、リスト型攻撃の可能性が高まる。そんな風に、原因を取捨選択するための試行錯誤を進めるところまではできた」(多田さん)
21年の訓練経験が役立った場面もあった。前回の障害訓練では、システム側の障害情報と、経営層が受け取った脅迫という情報がリンクするまでにやや時間がかかる課題が浮かび上がった。一方22年の訓練では、部門の壁を越えての情報共有ができたという。
「訓練ということもあるが、セキュリティインシデントに対応しているところに、営業側に問い合わせが入っているという情報がシームレスに入ってきた。それを受けて『どのような問い合わせがどのくらい届いているのかを調べよう』というサブタスクを立ち上げ、違和感なく取り込めた」(茂岩CISO)
新設した障害ブリッジも役立ったという。すでに活用が始まっており、社内でも「何かが起きたら集まり、関係者と直接話ができる場所」と認識されていたことから、コミュニケーションの場として活躍した。Slack上にありとあらゆる障害情報を取り込むチャンネルを立て、全社員がそれを自然に参照する形にしていたことも功を奏した。
一方、部門間コミュニケーションが進んだゆえにさまざまな情報が目に入ってしまい、つい脱線してしまいそうになることもあったという。「『ユーザーがビットコインで身代金を支払ってしまったけれど、その補償ってうちがすべきなんだろうか』といった話が横で始まって、ついついかき乱されてしまうこともあった」(茂岩CISO)
前回の反省を踏まえ、調査や対応に当たる現場のエンジニアや担当者が、集中を乱されずに作業を進められる方法も実践した。
システム障害など思わぬ事態が発生した時の「あるある」として、エンジニアが現場で作業しているところに偉い人が乗り込んできて「いったいどうなっているんだ」と口を挟んでくるトラブルが挙げられる。障害対応に集中したいのに手を止めざるを得なくなり、余計に復旧が遅れてしまうといった残念な結果になりがちだ。一方freeeは今回、それを避ける工夫を実践していたという。
「Google Meetを、メインのものと、調査項目ごとのサブグループと複数作成して使い分けた。それぞれに『何時になったら報告ね』と作業時間を決めて調査対応を進め、時間になったら集まって情報を確認し『じゃあ、次はこれをやろう』と意思決定をしてまたばらけるプロセスを何クールか繰り返した」(茂岩CISO)
茂岩CISOなど統括する立場の人間は障害ブリッジに残り、何かあれば手元にある情報で説明を行うことで、作業担当者が集中して業務に当たれる環境にした。
「担当を分担し、それぞれ分離して作業する一方で、一定期間ごとに『Sync』と呼ぶ情報を同期するポイントを作りましょう──というのが、前回の訓練からのフィードバック。これは障害ブリッジの設計にも役立っており、巨大なモニターを複数置いて、複数の会議を切り替えながら話ができるようにした」(多田さん)
Copyright © ITmedia, Inc. All Rights Reserved.
Special
PR