去る2021年12月10日。Apache Log4jの脆弱性がセキュリティ界隈で大きなニュースになったことをご存知でしょうか。この脆弱性は、攻撃も非常に容易で、危険性もとても高いため、数多くの企業が緊急脆弱性対応を余儀なくされました。この記事を読まれている方の中には「対応が大変だった」と感じている方もいらっしゃるかもしれません。
Visionalでは、全13プロダクトの緊急脆弱性対応を7時間で実現しました。
全国の警察施設のセンサーで観測された攻撃数のグラフを見ますと、攻撃が増え始めたのが2021年12月12日頃です。それより2日前に、プロダクト開発部が13部門もある中で、全部門の回答が7時間で出そろったのですから、爆速対応と言っても過言ではありません。
これは、セキュリティ室とプロダクト開発部が一丸となって成し遂げた快挙です。
…恥じらいもなく厚顔で申し上げましたが、2年前までは事業部とのコミュニケーションにつまづき、対応完了まで数週間かかることもありました。
本日はみなさまに、どのようにしてこのような緊急脆弱性対応体制を作り上げてきたのか、ご紹介したいと思います。
緊急脆弱性対応にかかわらず「多くの部署を巻き込んで円滑に仕事を進めるにはどうすれば良いのだろうか？」という課題感をお持ちの方にも、ぜひ読んでいただければ幸いです。
▼目次
緊急なのに連絡が遅くなってしまうジレンマに苦しんだ過去
緊急脆弱性対応とは、セキュリティリスクの高い脆弱性が報告された場合に、それについて迅速に対応することを指します。お客様に安心安全なサービスを提供する上で、緊急脆弱性対応の体制構築は非常に重要です。
Visionalの場合、全社横断組織であるセキュリティ室が脆弱性情報のセキュリティリスクを評価し、リスクが高いと判断した場合は、Slackのエンジニア向けチャンネルで連絡して、プロダクト開発部に確認と対応を進めてもらいます。
セキュリティ室では「連絡内容」について、２つの面で悪戦苦闘してきた過去がありました。
１つ目は「この脆弱性は本当に、開発を中断してまで確認するべきものなのか？」ということです。
例えば、Apache HTTP Serverで緊急性の高い脆弱性が報告されたことがありましたが、そもそも使っていないのであれば、この脆弱性に起因するリスクは存在しないですよね。
無駄な確認依頼をしてしまわないか、いつも苦心してました。
２つ目は「最新バージョンへのアップデートの他に、脆弱性対応方法は無いのか？」ということです。
公表されている脆弱性への対応方法のほとんどが最新バージョンへのアップデートですが、現実のプロダクト開発では、アップデートによる影響範囲が広く検証に時間がかかることがあります。
以前報告されたGitの脆弱性では、最新バージョンへのアップデートができない場合、credential helperの無効化が緊急緩和策として考えられました。
非現実的な緊急対応方法をご案内しても、プロダクト開発部が混乱するだけ。 緊急緩和策の考案に時間がかかっていました。
確認依頼で一難、対応依頼でまた一難。連絡内容の作成に、丸一日かかってしまうこともありました。連絡に丸一日かかっていては、すでに攻撃されてしまうかもしれない。緊急と銘打っているというのに、これでは本末転倒ではないか。あまりの不甲斐なさに、非常に悔しい思いをしました。
プロダクト開発部へ迅速に連絡する。 あるべき姿に向けて、わたしたちは動き出しました。
解決に向けた３つの取り組み
１．連絡を「確認依頼」と「対応依頼」で分ける
連絡内容作成の内訳を見ますと、脆弱性対応方法の調査と精査に時間をかけていることがわかりました。難しくて伝わらない表現になっていないか、誤解を招く表現になっていないか、対応方法に不足はないか…鬼のような添削をしすぎて、時間がかかってしまっていたのです。
そこで、連絡を「確認依頼」と「対応依頼」で分けることにしました。
まずは「確認依頼」を連絡し、プロダクト開発部の皆さんが確認作業をしている間に「対応依頼」の文章を作成することで、スピーディーな連絡が可能となりました。
２．ツールを用いて確認依頼の精度を上げる
構成を自動スキャンすれば、脆弱性のあるライブラリを使っているかどうかがわかり、無駄な確認依頼を防げるのではないか。
そのような発想のもと、「yamory（ヤモリー）」という脆弱性管理クラウドで、セキュリティリスクの高い脆弱性が報告された場合に、各プロダクトにおけるライブラリ利用の有無を調べることを始めました。
「yamory」の活用により、Slack連絡時に「@here」だけではなく、具体的にプロダクト開発部の責任者の方にメンションを付け、確認依頼の精度を上げることができるようになりました。
３． 信頼関係を築くための「対話」を増やす
わたしたちはこの2年で、プロダクト開発部との信頼関係構築に力を入れてきました。
脆弱性対応と新機能開発。どちらも「お客様へよりよいサービスを提供する」という目標に向かっているのですが、業務時間の使い方が大きく変わりますので、どうしても主張が異なるケースが多いです。
対立構造ではなく、互いの主張を聞き入れ、よりよい落とし所を考えていく。
その文化醸成が必要だと考えました。
具体的な動きとしては、わたしたちが検出した脆弱性を報告する際は、一方的に報告書を提出するだけではなく、必ず「どのように対応していくのかを一緒に考える」という場を設けました。
この場を設定することで、プロダクト開発部の皆さんは「このような攻撃や被害があるのか、考えもつかなかった」となりますし、わたしたちセキュリティ室は「急いで開発しなければならない機能があるのか、人的リソースが足りてないのか、考えもつかなかった」となるわけです。
「いやはや、お互い大変ですねぇ」という気持ちが芽生え、一気に打ち解けます。
そうすると、いつのまにか「対立」ではなく、お互いに良い落とし所を考えるための「対話」に頭を使い出します。
この「対話」を地道に2年間続けてきたからこそ「ああ、セキュリティ室が緊急って言ってるから、動こうか」となっていただけたのです。
わたしたちも「きっとプロダクト開発部のみなさんがすぐに駆けつけてくれる」と信じて連絡できるのです。
地道な取り組みが花開いた瞬間と今後の展望
これら3つの取り組みを地道に2年間続けた結果、Apache Log4jの緊急脆弱性対応を7時間で実現し、連絡に丸一日かかっていた頃に比べて、大きく前進することができました。副次効果として、Log4jに関するお客様からのお問い合わせにも迅速に回答でき、安心を届けることができました。
しかしながら、まだまだこれらの取り組みは発展途上だと思っています。「これは本当に全プロダクト開発部に連絡するべき緊急脆弱性だ」と言える確度を上げていきたいです。
引き続き、緊急脆弱性対応をはじめとしたプロダクトセキュリティの強化を推進してまいります。
Visionalのセキュリティ室では、プロダクト開発部の皆さまとの「対立」ではなく「対話」を心がけ、よりよい落とし所を考えることを大切にしています。
力を貸していただける方、一緒に取り組んでみたいと思った方からのご応募をお待ちしております。
最後までお読みいただき、ありがとうございました。
