SRB、SOC、IRGの三位一体で進める顧客案件のセキュリティ確保

電通総研は2024年の社名変更を機に、長年展開してきたシステムインテグレーション事業にコンサルティングとシンクタンク機能を組み合わせ、人とテクノロジーの力で新たな価値の創出や顧客体験の向上に取り組んでいる。

その価値の一つがセキュリティだ。サイバー攻撃の横行を背景に顧客側のセキュリティ意識も高まっており、システム開発に当たっては、情報漏洩や不正アクセスを受けることのないよう一定水準のセキュリティを満たすことが望まれるようになった。

こうした状況を踏まえ電通総研では、コーポレート本部 サイバーセキュリティ推進部が中核となって、各プロジェクトで開発するシステムのセキュリティ確保に取り組んできた。「電通総研で開発するシステムのセキュリティリスクをプロジェクト毎に受容できるレベルまで低減することが目標です」（小笠原氏）

具体的には、要件定義・設計の段階でセキュリティチェックを行い、被害の未然防止を図るSRB（Security Review Board）、クラウド環境を中心に問題の早期検知に取り組むSOC（Security Operation Center）、万一セキュリティインシデントが発生した際に速やかに対応にあたり、被害を最小化するIRG（Incident Response Group）という取り組みの三位一体で、システムのリリース前から運用フェーズまで、ライフサイクル全体でセキュリティの確保に努めている。

顧客システムに影響を与えない「ソフトウェア手動登録機能」を評価しFutureVulsを採用

取り組みの一つが、システムに含まれる脆弱性の管理だ。以前はSRBのレビュー段階で利用が想定されているソフトウェアをヒアリングで把握し、オープンソースのVulsを用いてプロジェクトごとに個別にCVEベースで脆弱性を通知するほか、影響度の高い脆弱性は全社的に周知する活動を行っていたが、徐々に課題を感じるようになった。

「個別周知においては過去に実施したSRBのレビュー段階でのソフトウェア情報を元にしていたため、実際にインストールされているソフトウェア情報を一元的に管理できていませんでした。また、Vulsによるスキャンは定期的に実施していたため、タイムリーに通知できていないことも課題でした」（福山氏）

2021年にApache Log4jの脆弱性が公表された際には多くの企業が右往左往したが、多数の顧客案件を抱える同社も例外ではなかった。「社内のさまざまな担当者に『このプロジェクトではLog4jを使っていますか』と聞いて回る作業が発生し、多大な手間がかかりました。」（柴田氏）

顧客の要望に応じて継続的に改修を加えつつ、セキュアなシステムを顧客に提供し続けるには、それぞれの顧客システムの中でどのようなソフトウェアが使われているかをバージョンとともに整理し、最新の脆弱性情報と突き合わせていく必要がある。同社はそれをより少ない負荷で実現する手段として、FutureVulsのCSIRTプランを採用した。 以前からオープンソースのVulsを使っていたことも理由の一つだが、最大の決め手は、顧客のシステムに影響を与えずに脆弱性管理が行えることだった。

「自社のシステムとは異なり、お客様の環境に勝手にスキャナを入れて検査するわけにはいきません。このため、ソフトウェアのバージョン情報を手動で登録し、脆弱性を検出できる機能を持つ製品を探しました」（福山氏） 制限なく柔軟にソフトウェア情報を手動登録できる上に、スキャナを用いた検査でも、スキャナ自体が軽量で、サーバやアプリケーションの動作に影響を与える恐れが少ないことも評価のポイントとなった。

さらに、PoCを通してFutureVulsに触れる中で浮上したさまざまな要望へも速やかに対応してもらえる点に好感を抱いた。「『この情報が表示されているともっと使いやすい』『メールやSlackだけでなくMicrosoft Teamsへの通知にも対応してほしい』といった我々の要望をすぐにくみ取り、素早く対応してもらえて助かりました」（福山氏）

Teams通知の実現に当たっては電通総研も検証に協力したが、このプロセスを通して改めて、国内ベンダーならではの良さを感じているという。「海外ベンダーの場合、要望を出しても反映されるまで長い時間がかかることが珍しくありません。すぐに対応してくれるフューチャーの姿勢に、大きな信頼を寄せています」（小笠原氏）

模擬訓練や勉強会を実施し、SSVCベースの脆弱性管理プロセスを軌道に乗せる

電通総研は2023年7月から、FutureVulsを用いたSSVC（Stakeholder-Specific Vulnerability Categorization の略で、脆弱性の悪用状況やシステムの露出度等から各脆弱性の対応方針を計算するフレームワーク）に基づく脆弱性管理のプロセスを定め、インシデントレスポンスを担うIRGの脆弱性管理チームの取り組みの一つとして実施している。

まずプロジェクトチームからFutureVuls利用に関する申請を提出し、SSVCも含めた初期設定を行う。FutureVulsでは、脆弱性が検出されると、サーバごとに脆弱性単位でタスクが作成され、そのタスクに対してSSVCのレベルに応じた対応期限が自動で設定される。脆弱性管理チームでは全プロジェクトのタスクの対応期限切れチェックを行うが、SSVCで「Immediate」と評価される脆弱性が未対応かつ対応期限を過ぎていた場合、個別にTeamsで通知し、対応を促すプロセスだ。

あくまで顧客のシステムであることを踏まえ、脆弱性管理チーム側が強制的にバージョンアップやパッチ適用を行うことはない。ただ、通知から一定期間を経ても対応が進まない場合は、部長クラスも交えて依頼することで脆弱性対応を促進してきた。この結果、「Immediateのタスク全体」に占める「未対応のタスク」の割合が、導入当初から80%以上削減されるまでに改善されている。 FutureVuls導入に当たっては、電通総研独自の工夫を行った。

たとえばプロジェクトチームにかかる負担を減らすため、資産情報の手動登録を選択した場合は、過去のSRBのレビュー情報を元に脆弱性管理チーム側で導入時の登録作業を肩代わりした。さらに、手動登録ではなくスキャナを利用すれば、システムにアップデートが入った際にも資産情報の更新作業が自動化されることを伝え、徐々にスキャナ採用の割合を高めてきた。いまでは手動登録とスキャナがほぼ半々の比率となっている。

また、インシデント対応訓練と同じように、緊急・重大な脆弱性への対応も訓練してみようというアイデアに基づき、Spring4Shellの脆弱性を想定して模擬訓練を実施した。「当時はFutureVulsの展開途上ということもあり、どのように情報収集からトリアージ、現場での対応を進めていくか、フローを確認してみようと考えました」（福山氏）。実際に試すことで、グループ横断での検索機能やオーガニゼーショントピックを用いた個別周知の方法などを確認し、手応えを感じたという。さらに、フューチャーから講師を招き、脆弱性管理に関する勉強会も開催している。

プロジェクトチームの脆弱性管理意識向上

FutureVulsの導入によって、各システムで使われているソフトウェアの利用状況を把握し、SSVCという一つの物差しに基づいて脆弱性への対応方針を定め、そのうえでどの程度対応が進んでいるかまで可視化できるようになった。

「各プロジェクトチームも、脆弱性情報を一元管理できるようになり、さらにSSVCによって優先度を付けて判断できるようになりました。また、『こういった脆弱性にはどう対応したらいいですか』といった問い合わせも、以前に比べて増えています。脆弱性管理チームが脆弱性の対応状況をタイムリーに把握できるようになったことが、改善できたポイントだと思います」（福山氏） 顧客が脆弱性管理状況を尋ねてきた場合も、FutureVulsを用い、明示的なパッチ適用基準の元で実施していると説明できるようになった。

今後はFutureVulsに実装された、EPSS（今後30日以内に脆弱性が悪用される可能性を表す指標）の活用も視野に入れつつ、よりよい脆弱性管理のあり方を模索していく方針だ。 「勉強会での情報発信とプロジェクトチームからのフィードバックを取り込み、FutureVulsを利用した脆弱性管理の活動を改善し、SRB、SOC、IRGで連携しながら、セキュリティ意識の向上と電通総研が提供するシステムのセキュリティ品質向上を進めていきます」（福山氏）