🛡️

脆弱性の早期検知と管理を内製化してみた

2023/12/07に公開

この記事は MICIN Advent Calendar 2023 の7日目の記事です。
前回は木南さんの『技術強化委員の取り組み』でした。

皆さんの組織では社内IT資産の脆弱性の情報収集や管理、どのように行っていますでしょうか?有償の脆弱性管理ツールを活用している組織もあれば、そういったツールを使用せずに深刻な脆弱性が広く知られるようになってから対応を検討する組織もあるかもしれません。今回は株式会社MICIN社内におけるIT資産(コーポレートIT&プロダクト)の脆弱性の早期検知と管理の内製化に焦点を当て、情報セキュリティ部の高橋がその取り組みについてご紹介します。

脆弱性管理システムの狙い

MICINでは2023年の1月から9月にかけて「脆弱性管理システム」の構築を進め、現在は改良を重ねながらシステムを使用した脆弱性検知・管理を運用しています。このシステムでは、一次情報を情報源として活用し、特に重大な脆弱性の早期検知と是正を目指しています。システムではアプリケーション名を使用し、そのアプリケーションと脆弱性情報を突合する仕様になっています。ただし、この仕様上、アプリケーション名に表記揺れがある場合、脆弱性を検知できない可能性があります。本システムで検知できない脆弱性については、日々の脆弱性に関する情報収集でカバーしています。(網羅的なものではなく、ベストエフォートで早期に検知できるように努めています)

"脆弱性管理システムの全体像"
脆弱性管理システムの全体像

脆弱性情報に関して、3つの脆弱性の一次情報を取得しています。コーポレートIT側のIT資産情報は、デバイス管理システムを介してアプリケーションの情報を収集しています。一方で、プロダクト側のIT資産情報は、GithubからSBOM(ソフトウェア部品表)の情報を収集しています。これらの情報はそれぞれログ収集基盤(SumoLogic)に集約され、社内で使用されているIT資産において深刻度の高い脆弱性を検知します。

脆弱性が検知されると、プロジェクト管理ツール(Jira)に自動的にチケットが起票されます。それと同時にチャットツール(Slack)を通じて情報セキュリティ部に通知が届きます。通知を受けた情報セキュリティ部では、脆弱性が対処が必要なものかどうかを調査し、自社に影響のある場合やリスクが受容可能でない場合、対処措置を講じます。是正処置が必要な場合は、バージョンアップデートやアンインストールなどの対応を依頼します。

ここからは脆弱性管理システムにおける、各フェーズの詳細について解説していきます。

1. 情報収集

脆弱性情報

情報源として、一般的に使用されている以下の3つのデータベースから脆弱性情報を収集しています。

名称 説明
National Vulnerability Database(NVD) NIST(アメリカ国立標準技術研究所)が管理している脆弱性情報データベース。CVE(共通脆弱性識別子)データを基にした脆弱性の詳細情報を提供し、CVSS(Common Vulnerability Scoring System)による危険度のスコアリングを実施しています。
Japan Vulnerability Notes(JVN) JPCERT/CCと情報処理推進機構(IPA)が共同で管理している脆弱性情報データベース。早期警戒パートナーシップに基づく情報や、海外CERT(Computer Emergency Response Team)等からの情報を公表しています。
(CVEが採番されずNVDで扱われないような、日本国内特有の製品に関する脆弱性をカバーする目的で収集しています)
Known Exploited Vulnerabilities Catalog(KEV) CISA(米国サイバーセキュリティ・社会基盤安全保障庁)が維持管理する、既に悪用が確認され、米国の連邦政府全体に重大なリスクをもたらすと評価された脆弱性のリスト。脆弱性対応において最優先で修正すべきものとされています。
(CVSSに依存することなく、危険度の高い脆弱性を検知するために収集しています)

"ログ収集基盤に保存された脆弱性情報の例"
ログ収集基盤に保存された脆弱性情報の例

IT資産情報

貸与されたPCはデバイス管理システムによって管理され、そのシステムを通じてインストールされたアプリケーションの情報を定期的に収集しています。MICINでは、Macの場合はJamf Pro、Windowsの場合はIntuneが使用されています。また、プロダクト側の情報収集においては、Githubの各リポジトリのプルリクエストがマージされるタイミングでGithub Actionsが起動されます。それによりtrivyを利用してSBOMファイルが生成され、そのファイルがログ収集基盤へ連携されるようになっています。

"ログ収集基盤に保存されたSBOMの例"
ログ収集基盤に保存されたSBOMの例

これらの脆弱性情報およびIT資産情報は、社内のログ収集基盤として使用している「SumoLogic」というSIEM(Security Information and Event Management)ツールに保存されます。

2. 判定

脆弱性情報は、自社に関係のないものやCVSSが低いものも含め、1日に平均して1500件ほど収集されます。しかし、これら全てを目視で確認することは現実的ではありません。そのため、脆弱性情報のフィルタリングとして、以下の2点を満たす場合に検知の対象としています。

  • 社内利用されている
  • 情報源がNVDまたはJVNで深刻度がCRITICALであるか、情報源がKEVの場合
SumoLogicサーチクエリの例
_collector="vulmanagement" 
//subqueryを使用しアプリケーション情報をサーチクエリに使用
[subquery: cat path://"【Windowsのアプリケーション情報のLookupTableのパス】"
//アプリケーション名を完全一致で検索するためにダブルクォートで囲む
| concat("\"",ApplicationName,"\"") as ApplicationName
//OS名についても検索対象とするため、手動で追加
| compose ApplicationName keywords] OR "\"windows_10" OR "\"windows_11"
//情報源がKEVの場合、CRITICAL扱いとする
| if(source matches "KEV","CRITICAL",cvss_severity) as cvss_severity
//CVE IDにNVDのサイトのリンクを付与
| tourl(concat("https://nvd.nist.gov/vuln/detail/",cve_id),cve_id) as cve_id_link
//深刻度がCRITICALでフィルター
| where cvss_severity matches "CRITICAL"
//必要な情報を抽出
| count by myDate,cve_id,cve_id_link,cpe_product,cpe_vendor,cvss_score,cvss_severity,cvss_Data_attackVector,source

チケット起票

脆弱性が検知されると、社内でプロジェクト管理ツールとして使用しているJiraのチケットが自動的に起票されます。

"脆弱性管理のダッシュボード画面(Jira)"
脆弱性管理のダッシュボード画面(Jira)

SumoLogicとJira Cloudのコネクションを作成することで連携できます。手順は以下の公式ドキュメントを参考にしました。
https://help.sumologic.com/docs/integrations/app-development/jira-cloud/

Jiraチケットが起票されると、連携しているSlackチャンネルに通知が届きます。

"脆弱性検知のSlackでの通知例"
脆弱性検知のSlackでの通知例

3. 対処

検知された脆弱性については、人手で詳細に調査し、総合的に対処が必要かどうかを判断します。調査の観点は以下の通りです。

  • 攻撃コードの存在有無
    • NVDの脆弱性詳細ページの「References to Advisories, Solutions, and Tools」にExploitのリンクの掲載が存在するか
    • Exploit-DBでのCVE番号の検索結果

"詳細ページにExploitのリンクが存在する例"
詳細ページにExploitのリンクが存在する例

  • 話題性
    • XでのCVE番号の検索結果
  • 自社への影響
    • 脆弱性の詳細情報から、脆弱性により脅威が生じる条件に該当するか確認
    • 脆弱性の詳細情報から、脆弱性により生じる脅威が許容できるか確認

対応が必要と判断された場合は、収集されたIT資産情報からどの端末やシステムに当該アプリケーションが導入されているかを調査し、関係者に是正を依頼して脆弱性を解消します。

"是正依頼の例"
是正依頼の例

脆弱性に関する日々の情報収集

アプリケーション名の突合ができない、深刻度がCRITICAL以外だが実影響のあるなど、本システムで検知できない脆弱性が存在します。そのような脆弱性については、以下の複数のセキュリティ団体やSNS、ニュースサイトから日々情報収集しています。

今後の課題

2023年9月に構築が一段落した本システムですが、運用の面では改善の余地が見受けられます。特に検知後に情報セキュリティ部にて手動で調査している部分については、トイルとなっているため、できるだけ自動化を進め、人間は情報を見て判断するだけの運用を目指したいと考えています。


MICINではメンバーを大募集しています。
「とりあえず話を聞いてみたい」でも大歓迎ですので、お気軽にご応募ください!
https://recruit.micin.jp/

株式会社MICIN

Discussion