脆弱性管理の「もやもや」を解消するポイントとは？　識者や担当者の議論に学ぶ、脆弱性管理体制構築のヒント：増え続ける脆弱性とどう向き合うか

ラック 井上圭氏

　「2019年頃は脆弱性管理というと、一般に、ソフトウェア資産を把握してそれに対する脆弱性情報を収集し、対応の判断を下し、計画を立てて対応していく、という作業を指していました。しかし最近は状況が変わり、単に脆弱性があるものを直すだけでなく、企業の存続を左右するようなリスクには早々に対応していく、という意味合いを持つようになっています」（井上氏）

　これに伴って注目されるようになったのが、脆弱性の「トリアージ」というキーワードだ。

　ありとあらゆる脆弱性に対応するのは、工数面でも、予算の問題からも非現実的だ。そこで、ビジネスリスクや対象システムの資産価値などを踏まえて優先順位を付け、リスクの高いものから対処するようになっている。日本セキュリティオペレーション事業者協議会（ISOG-J）からは「脆弱性トリアージガイドライン作成のための手引き」という文書も公表されている。またCVSS（Common Vulnerability Scoring System）の他、KEV（Known Exploited Vulnerabilities）やEPSS（Exploit Prediction Scoring System）といった指標が出され、SSVC（Stakeholder-Specific Vulnerability Categorization）のようなフレームワークも整備されてきた。

　ただ、井上氏は「正直、こういう話はよく聞きますし、示された通りにやれば回るのかもしれません。しかし実際のところ、本当にできているのでしょうか？」と、BoFの趣旨に立ち返って会場に問い掛けた。

　井上氏はさらに、今まさにあちこちでささやかれ始めている「SBOM」（ソフトウェア部品表）にも言及した。

　SBOMは開発、利用しているソフトウェアに含まれているOSS（オープンソースソフトウェア）やサードパーティー製のライブラリ、ソフトウェアなどを一覧表にし、管理できるようにしたものだ。ソフトウェアサプライチェーンの脆弱性管理の観点から、注目を集めるようになっている。

　2021年、「Apache Log4J」の脆弱性が判明した際には、「果たして、うちのシステムはこの脆弱性の影響を受けるのかどうか」を確認するため、多くのセキュリティ担当者が右往左往した。知らないうちにアプリケーションに組み込まれているケースもあったため、対応は困難を極めた。

　こうしたいきさつから、モノ作りの世界におけるハードウェアの「部品表」と同じように、ソフトウェアの中に含まれる「部品」を把握し、誰が開発したものか、脆弱性の影響を受けるのかといった事柄をすぐに把握できるようにしようという意図でSBOMが注目されている。

　だが井上氏は、部品表が当たり前にあるモノ作りの業界とは異なり、ソフトウェア業界ではどこまでSBOMが求められているのか、そして本当に有効性があるのかどうかには疑問が残ると述べた。

　「自動車業界とソフトウェア業界とでは、SBOMに対する渇望度が違います。自動車業界ではもともと部品表は当たり前のようにやってきたこともあり、ライセンス管理も含めたSPDX形式を策定し、SBOMを使おうという機運は高まっています。しかし、ソフトウェア業界ではまだそこまででもありません」（井上氏）。開発の現場を見ると、取りあえずビルドし、リリースしてから「あれ、バージョンは幾つだっけ？」という場面も珍しくない。

　一方、サプライチェーンリスクを懸念する経済産業省は、少なくとも政府に納品されるソフトウェアに関しては、SBOMも含めた脆弱性管理を進め、自己認証あるいは第三者認証を求める規制を検討している。さらに、EU（欧州連合）のサイバーレジリエンス法（CRA）に見られる通り、グローバルでもSBOMの採用に関する議論が本格化している。

　こうした法規制では「セキュアにビルドを行い、CI/CD（継続的インテグレーション／継続的デリバリー）サイクルの中でチェックを求めるといった要件が出ています。しかし、これらを満たすには運用だけでは対処できません。その前の開発段階から、脅威モデリングなどに取り組まないといけない時代が到来しつつあります」（井上氏）。そして、その意味でDevSecOps的なアプローチに取り組んでいく必要があるとした。

　大手SIer（システムインテグレーター）の中には「SBOM、やっています」と宣言しているところもある。だが井上氏はあらためて「私たちは、今、この状況でSBOMに対応できるのでしょうか。そもそもSBOMも整備しておらず、リリース時にQA（品質保証）を実施して『こんなコンポーネントを使っています』という情報を出す程度であれば、対応は難しいのかなと思います」と率直な思いを吐露した。

　SBOMに関する議論はまさに進行中ということもあり、SBOMを整備し、DevSecOpsを実現していくには、どのタイミングで何をすればいいのか、要件や定義はまだまだ曖昧だ。

　「何をどこまでやればいいのかが不明なまま話が進んでいますが、この状態で『やれ』と上から言われても、実際にはやれないように思うのです」（井上氏）というのが、現場の率直な思いかもしれない。

　これを受けて会場からは、「運用があまりにも開発者の献身に頼っていることもあり、SBOMはそもそも人間に運用可能なのか、たとえ始めても歯抜けのリストになって期待した結果が得られないのではないかと思います」「会社としてはSBOMを取得するようにルールを定めていますが、脆弱性管理という観点では必ずしもSBOMではなく、脆弱性スキャンでも十分に思います」といった声が上がっていた。

「人」の脆弱性に起因するインシデントも多数、組織に適した管理体制が必要に

　さまざまな企業のインシデント対応やフォレンジック調査を支援してきたYONAの代表取締役社長、三国貴正氏は、実際に起きているインシデントと脆弱性管理という、切っても切れない二者の関係性について、自らの経験を基に説明した。

　三国氏は年間百件以上ものインシデント対応を支援してきた。一口にインシデントと言っても、不正アクセスをはじめ、情報漏えいやランサムウェア（身代金要求型マルウェア）感染、サイト改ざんやペイメントアプリの改ざん、botネット、そして内部不正など多種多様だ。

YONA 代表取締役社長 三国貴正氏

　これらセキュリティインシデントの原因として、端末のOSやアプリケーション、ネットワーク機器が搭載するソフトウェアの脆弱性が悪用されるケースが多いのは周知の通りだ。三国氏はさらに、開発用フレームワークや、広義のサプライチェーンに含まれるであろうSaaS（Software as a Service）の設定やOSSの脆弱性が悪用されるケースがある他、「人」の脆弱性も存在するとした。

　その上で「これらの脆弱性全てを網羅的に管理するのは非常に難しい。従って、その組織に適した脆弱性管理を行っていくことが望ましいと考えています」と述べた。

　では、「組織に適した脆弱性管理」とはどのようなものだろうか。三国氏は、実際にインシデントに直面した企業の例を挙げ、そのポイントを説明した。

　1つ目の例は、パンの製造、販売、小売を手掛ける従業員50人程度の規模の製造業だ。

　規模は小さいが、販売や仕入れ、人事管理、顧客管理などさまざまな側面でITを活用しているこの企業では、フィッシングメールからのマルウェア感染、そして、複数の社員で運用していた共有SNSアカウントの乗っ取りといった被害に直面した。まさに「人」の脆弱性が悪用されたケースといえるだろう。

　2つ目の例は、SaaSをフルに活用している150人規模のサービス業だ。中核業務は全てSaaSで行い、ファイルサーバなどは社内に持たない構成とすることで、ランサムウェア感染によるリスクを小さく抑えていた。だが、クラウドの設定ミスにより意図せず情報を公開してしまうインシデントが起こってしまった。また社内の人物がサポート詐欺に引っ掛かり、画面に表示していた業務情報が漏えいしたかもしれないという懸念もあった。これも、ソフトウェア脆弱性というよりも、人の脆弱性や設定ミスが招いたものといえるだろう。

　3つ目の例は、500人規模のソフトウェア受託開発企業だ。さまざまな開発、検証環境を用意して運用していたが、その開発環境が侵害されるインシデントが起こった。「本番環境とは異なり、アップデートをせずに開発環境を構築し、しかもたまたま、外部に公開していたタイミングで侵入されてしまいました」（三国氏）。また、クラウドのアカウント情報や鍵情報をハードコードしてしまい、自ら脆弱性を作ってしまうパターンもあったという。これもどちらかといえば、人の脆弱性に起因するものと分類できるだろう。

　4つ目の例は、数千人規模のサービス業で、IT資産管理ツールやEDR（Endpoint Detection and Response）などさまざまな製品も導入していた。その都度、セキュリティルールも追加していたというが、「実際の運用が回っておらず、ルールが徹底されずに穴があちこちに生まれてしまい、そこからランサムウェア感染が起きました」（三国氏）。関係会社、協力会社を踏み台にして侵入される状況もあった。

　こうした事例が日々起こっている一方で、ソフトウェアの脆弱性は毎日のように報告されており、CVE（Common Vulnerabilities and Exposures：共通脆弱性識別子）で採番されたものだけでも3万件近くに上っている。

　三国氏は「これらを全て調査し、対応の判断を下すとなると膨大な時間がかかり、非常に困難です。自分たちにとって重要な脆弱性は何かを検討する必要もある上に、いわゆる『ゼロデイ脆弱性』の存在もあります」とし、あらためて、組織に適した脆弱性管理体制を構築、運用していく必要に迫られているとした。

　三国氏が紹介した実際のインシデントの例を見ると、特に人やアクセス制御、設定不備に起因するものが多い。「ソフトウェアの脆弱性について修正対応していくことも重要ですが、それだけでは不十分であり、サプライチェーンを意識した上でITガバナンスを強化していくことが重要です」と三国氏は述べ、定期的にリスクを評価し、責任分界点とインシデント発生時の役割を明確化し、体制を整えていく必要があるとした。

　一方で、ランサムウェアに関しては、少し前に話題になった脆弱性が悪用されて攻撃を受ける「Nデイ」的な事例も非常に多い。つまり「脆弱性対応はスピードが命」といった側面があるのも事実であるとし、いわゆるASM（アタックサーフェスマネジメント）やCTEM（継続的脅威エクスポージャー管理）といったソリューションにも目を向けるべきだとした。

　こうした三国氏の話を踏まえ、井上氏はあらためて「全部を均等にやるのは無理ですよね。限られたリソースを一番やられそうなところ、一番弱くなりそうなところに割くために、リスク分析や脅威モデリングのようなことも必要ではないかと思いました」とコメントした。

　発表を受けて会場からは「人の脆弱性をつぶすのは難しく、どういう働き掛けをしていけばよいのか、あらためて難しいと感じた」という声が上がっていた。これに対し、やはり原点に立ち返り、「自社は組織としてどうあるべきか」という戦略を決めることが重要であり、「詳しい人がいなくて分からない」という場合は、外部の専門家に頼ることも必要だろうとするコメントもあった。

社内以上に説明と合意形成が求められる、MSPならではの脆弱性情報管理

　最後にハートビーツの伊藤俊一氏が、顧客に代わってインフラの保守、運用を担うMSP（マネージドサービスプロバイダー）の立場から、どのように脆弱性情報管理に取り組んでいるかを紹介した。

　ハートビーツでは、300システム、8000台のサーバを保守、運用している。「多様なお客さまのクラウドやOSを対象に、さまざまな組み合わせで運用しているため、脆弱性管理はかなり大変です」（伊藤氏）。通常の運用作業に加え、数多くの組み合わせを見ながら脆弱性情報を収集し、アップデート対応の可否まで判断する必要があるため、非常に大変な作業だという。

　ハートビーツではそこを根性に頼るのではなく、仕組み化、自動化を進めている。Red Hatなどのベンダーが提供するCVEのデータベースからセキュリティアドバイザリー情報を収集し、フィルタリングした上で、CVSSのスコアや各OSの対応状況などとともにBacklogで一元管理する仕組みを構築している。各脆弱性にどのような対応を取っていったかもIssueとして記録し、管理する仕組みだ。

　こうした仕組みで顧客システムの脆弱性管理が行えているユニークな要因の一つが、もともと、運用を目的とした「エージェント」を導入済みであることだ。

ハートビーツ 伊藤俊一氏

　「エージェントの機能の一つとして、サーバのバージョン情報を一括で取得する仕組みを追加しています。そこで取ってきたデータを基に、脆弱性情報それぞれについて該当するお客さまを調査し、対応する仕組みを作っています」（伊藤氏）

　こうした仕組みは非常に合理的に見え、効率的に脆弱性管理が行えそうに思える。だが実際にはなかなか難しい部分も多いそうだ。

　一つは、脆弱性のトリアージだ。自社システムの場合でさえ、「脆弱性対応のためにパッチを当てたい」というと、「どのような影響があるのか、サービス停止は困る」といった声が出てくる。ましてや運用をアウトソースしている顧客が相手となると、脆弱性の一つ一つについて影響範囲を調査していかなければならず、非現実的だ。

　そこでハートビーツでは、ある程度機械化して分析した上で脆弱性のトリアージを行っているという。トリアージの評価軸として用いているのは「緊急性」と「話題性」だ。

　緊急性については、攻撃区分や攻撃の容易さ、そして「現実的な攻撃シナリオ」を考えて判断している。「深刻度がHighでも、通常ならばデフォルト（既定）で有効になっていない機能であれば緊急度を下げたり、リモートからの悪用ができないローカルな脆弱性でも、簡単にインジェクション可能なものであれば緊急度を上げたりといった具合に、脆弱性ごとに現実的な攻撃シナリオを考え、調査しています」（伊藤氏）。現実的な攻撃シナリオを考える前提となるIT資産の把握、現状把握がブラックボックス化されておらず、エージェントを通して把握できていることも、その判断を妥当なものにしているといえるだろう。

　ユニークなのは、もう一つの指標である話題性だ。「攻撃の危険度だけではなく、その脆弱性に関するニュースがどんなサイトに載っているか、お客さまの目にどのぐらい留まるかも気にして判断しています。Yahoo!ニュースに掲載された場合、緊急度が高くなくても、『お客さまを安心させる』という意味で連絡を取り、対策することもあります」（伊藤氏）

　すぐに顧客に告知しない場合でも、社内だけで先に情報を共有しておき、顧客からの問い合わせがあれば即座に対応できる体制を取ることもあるという。

　こうして日々、脆弱性対応に取り組んでいるが、時には「次から次へと、何でこんなに脆弱性がいっぱい出るのですか。サービス停止をしたくないので、今は対応しなくてもいいのではないか」といった声が寄せられることもあるという。こうした顧客との「温度感のずれ」を埋めるために役立っているのが、トリアージの際に検討した「現実的な攻撃シナリオ」だ。

　「SSH（Secure Shell）の脆弱性について『攻撃条件に該当していないので緊急度は下がりますよ』『この攻撃手法については監視でチェックしており、もし攻撃があればすぐに気付けるので大丈夫ですよ』といった具合に、現実的な攻撃シナリオを基に連絡すると、説明しやすくなります」（伊藤氏）。逆に、緊急に対応が必要な場合も根拠を示すことで、合意を得て動きやすくなると説明した。

　「緊急性の判断をどのように行っているのか？」という会場からの質問に対し、「一人の判断ではぶれてしまう可能性があるため、複数の部署をまたいで、複数人でチェックする仕組みにしています」と伊藤氏は回答した。ただ、どうしても特定の人に頼る部分が出てしまうのは避けがたく、どのように均一な基準を設けていくかが課題だとした。

　また井上氏によると、業界全体を見渡せば、「MITRE ATT&CK」と「CVE-ID」をマッチングさせるといった形で、特定の領域に限ってある程度判断を自動化していく仕組み作りも進んでいるという。自動化が実現できれば、負荷が軽減され、脆弱性管理の見通しも明るくなるかもしれない。

　会場からは、「ASMを実施すると、リスクを受容して適用していないパッチがあるだけで、大幅に減点されてしまいます。そうではなく、適切な脆弱性管理をすることがきちんと評価されるような成功体験があればいいのかもしれません」というコメントもあった。

　自己認証や第三者認証など、自社の脆弱性管理体制や脆弱性管理の取り組みがビジネス上のインセンティブにつながるような仕組み、制度があれば、企業における脆弱性管理のモチベーションは高まっていきそうだ。