Pocket

Vuls大好き皆さんお久しぶりです!第10回目となるVuls祭りに参加してきました。ちなみに「Vuls祭り行ってきた」ブログは5年ぶりとなります。第6、7、8、9回はコロナもあってなかなか参加人数が限られていましたが、久しぶりのオフラインイベントということで100名近く参加されておりました。

さて、今回は脆弱性の管理のリスク評価からSSVC、VEX、AIまでがテーマでした。数々の基調講演をメモしてきましたので、まとめていきたいと思います。

[2019/06/17]Vuls祭り#5で運営委員長とLTしてきました!


イベント概要

https://vuls-jp.connpass.com/event/327031/

  • タイムテーブル


リスクアセスメントツールの根柢思想

情報セキュリティを運用していく中で、ISMSの仕組みがある。このISMSを実施する上で、ISに技術者は集中していて、管理にはあまり意識を払っていない。ISMSの中ではPDCAのモデルが例示されているが、これは理想のマネジメントではない。

また、マネジメントを回すためにISMSで重要とされているものがリスクアセスメントである。ただ、このリスクアセスメントは決して正解がなく、複数の組織で従来の情報を中心としたCIAに基づくモデルで適当に運用されているように見える。

「歯ブラシとダイヤモンドを同じ熱意で守れば、少しの歯ブラシとそれ以上のダイヤモンドを失うだろう」という言葉が昔は好きだったが、この言葉が語られたのは1989年。奇しくもセキュリティクリアランスにまつわる議論を米国でしていた時だ。この頃と今の環境は大きく異なってしまった。情報中心のリスク分析は困難でありえる。

このリスク分析手法はISMSの中で正攻法で語られている。ただし、今の環境にそぐわないように思う。情報セキュリティーと呼ばれる分野には、大別して情報コントロール、サイバーセキュリティー、内部不正があり、それぞれことなる地平で捉えなければならないのに、情報資産を中心に据えたリスク分析で無理に全体を評価してしまっている。

リスクアセスメントツールは、脅威に特化しサイバーセキュリティーだけのリスク分析を目指した。サイバーセキュリティーに関しては、管理策が固定化できる部分があり、管理策の積み上げを満点として逆算でリスクを推定するモデルを考えた(逆算方式)。

ただし、そのモデルが効果を発揮するためには、管理策の充実が必要である。そのため、さまざまな手法で具体的な管理策を積み上げた。特に、『前始末』の内容は管理策として気にしたポイントだ。マネジメントの観点から見ても、早期対応は後の対応よりも何倍も効率的。

リスクアセスメントツールもまた、担当者の感覚に依存してしまう部分もある。事実に近づけることを評価し、レッドチームや外部評価も(幾分の信用性の問題はあっても)併用し、事実に近づける施策をとっている。

脆弱性情報対応の現実 

脆弱性とは、システムやネットワークにおけるセキュリティ上の弱点を示す。具体的には、CVE番号、ポート番号での脆弱性アタック、デフォルトのパスワードが設定されたままの認証システムなどが該当する。しかし、管理策の弱点や設定ミスも脆弱性の一種であり、CVE番号だけでは対応しきれない部分も多く存在する。

脆弱性に対する適切な対応には、最新情報の収集が不可欠。X(旧Twitter)などのソーシャルメディアでは、脆弱性が話題になることがあり、JPCertやGitHubも有用な情報源となる。特に、GitHubで、エクスプロイト(exploit)に関する情報を得ることができる。しかし、ネット上には誤った情報も多く存在するため、信頼性のあるソースから情報を取得することが重要。

脆弱性対応のプロセスにおいては、トリアージ(優先順位付け)が鍵となる。脆弱性がビジネスにどのような影響を与えるかを考慮する必要がある。そのため、可用性や機密性に特に注意を払い、影響範囲を正確に評価することが求められる。

EASM(External Attack Surface Management)やCSPM/SSPM(Cloud Security Posture Management/SaaS Security Posture Management)などあるが、製品や脆弱性を追う前に地を固めること。


脆弱性管理のパラダイムシフト – VEXの理論と実践

福田さん!みんな知っているTrivy開発者。現在はUAEに住んでおり、アクアセキュリティ社で開発を行っている。

年間2万件にも及ぶ脆弱性情報をすべて確認することは現実的ではなく、ビジネスに直接影響を与えるものに絞ったスキャンが必要。たとえば、CVSSの基本値に基づいて深刻度が低い脆弱性を無視することも一つの選択肢だが、SSVCを用いてより詳細なリスク評価を行うことが求められる。

脆弱性情報は大量に存在するが、その中から本当に重要なものを見つけるのは容易ではない。SBOM(ソフトウェア部品表)を組み合わせて検出することが可能だが、ノイズが含まれることも多く、取り除くことができれば、管理は非常に楽になる。

VEX(Vulnerability Exploitability eXchange)は、脆弱性のステータスや影響範囲を正確に伝えるためのフォーマットを提供し、不要なノイズを取り除くことができる。VEXの適用フローは、試算情報と脆弱性データベースを組み合わせることで、最適な結果を導き出す。

しかし、VEXの適用には課題も多く、特にソフトウェアの比較や依存グラフへの適用が困難。また、VEXの配布先や探し方もまだ確立されておらず、これからの発展が求められる。

VEXのフォーマットにはCycloneDX、CSAF、SPDX、OpenVEXなどがあり、JSON形式で3つの重要な要素(脆弱性ID、ステータス、プロダクト情報)を記載することが求められる。OpenVEXやvexctlなどのツールを使ってVEXを生成することが可能だが、開発者であってもVEXの生成は難しく、多くの課題が残っている。

最後に、VEXの課題として、ソフトウェアの比較が難しく、バージョンの違いを正確に把握するための仕様が不足していることが挙げられる。依存グラフの適用も困難であり、VEXの配布先や探し方が確立されていないのでVEX Hubを開発したとのこと。


VexLLM: LLMを用いたVEX自動生成ツール

脆弱性が多すぎて管理が難しいので新しいツールを開発した。脆弱性の中でも、実際には影響を与えないものが多く含まれていることがある。たとえば、脆弱性スコアが9であっても、すぐに焦る必要はない。

新ツールでは、VEXや.trivyignoreを活用して、不要な脆弱性情報を抑制できる。さらに、OpenAIなどのLLM(大規模言語モデル)を利用して、OpenVEXや.trivyignoreファイルを自動的に生成するVexLLMを開発した。

このツールを使用することで、不要な脆弱性情報が減少し、より効率的にセキュリティ管理がしやすくなる。

今後は、Trivyのプラグインとして統合し、TrivyのCLIと密接に連携させることで、さらに使いやすく改善していく予定。


「残業?来週でOK?」金曜午後の脆弱性対応判断に使えるSSVCのデモ

Vulsのニキ神戸さん。脆弱性対応のリスク評価手法について、SSVC(Stakeholder-Specific Vulnerability Categorization)フレームワークが注目されている。このフレームワークは、リスク、脆弱性、脅威、影響を4つの段階で評価し、優先順位を付けるための強力なツール。

近年、ランサムウェアなどのサイバー攻撃が増加し、脆弱性の数も年々増加している。そのため、どの脆弱性に対応すべきか、特に金曜日の夕方に緊急の脆弱性が報告された場合、即座に対応することが非常に困難。「ビールを飲みたかったけど、緊急対応で無理だった…!!!」という状況も珍しくはない。

CVSSスコアで脆弱性の深刻度を示すことは一般的だが、スコアが高いものだけを優先することは困難。たとえば、スコアが低くても攻撃に使用される脆弱性が存在するため、単にスコアに基づいて判断することはリスクが伴う。

無料で使える脅威情報としてはCISA KEY、Vluncheck KEV、EPSS(Exploit Prediction Scoring System)などのツールと連携することで、リスク評価をより的確に行うことができる。たとえば、EPSSは30日以内に脆弱性が実際に攻撃に使用される可能性を予測し、スコアを上昇させる。

実験を行ったが、「immediate」や「out-of-cycle」のカテゴリーに該当する脆弱性に絞ることで、効果的に対応できることが確認された。

セキュリティの専門知識がない担当者でも、脆弱性に対して適切に対応できる仕組みが整う。SSVCを活用することで、リスクを総合的に判断し、組織の脆弱性対応能力を向上させることが期待される。

https://vuls.biz/blog/articles/20240822a/


脆弱性検知を支える技術

 

CPE(Common Platform Enumeration)は、ソフトウェアやハードウェアなどのプラットフォームを識別するための名称。CPEは、part、vendor、product、versionといった要素で構成されており、NVD(National Vulnerability Database)などはCPEと脆弱性情報を紐づけて公開している。

しかし、CPEを利用した脆弱性検知には多くの課題がある。たとえば、CPEのマッチングでは、適切なCPEを記述しているつもりでも、ルールを理解していないとCPEの比較に失敗することがある。プロダクト名が雑だったり、NVDのバージョン表記が複雑だったりすることで、識別が困難になるケースもある。また、期待通りのCPEが書かれていない場合もあり、脆弱性の検知が不十分になることがある。

さらに、NVDの更新遅延問題もある。脆弱性情報の解析が遅れると、毎日110件以上の新しいCVEが発表される中で、最新の脆弱性情報に追いつくことが難しくなる。この点において、CISA Vulnrichmentが発表され、NVDの代わりになるかと期待されたが、現状では厳しいとのこと。

話は変わってOSS版Vulsは、脆弱性DB周りの変更やリファクタリングを行い、検知能力を向上させるために、バージョンアップしている。継続的に進化し、脆弱性検知の精度を向上している。


まとめ

脆弱性対応に関するリスク評価からSSVC、VEX、AIまでの内容は非常に濃厚でした。自分はセキュリティエンジニアではありませんが、SREとしてどこまでを守備範囲としてカバーすべきか、改めて考えさせられました。また、脆弱性検知自体はできているものの、その運用が非常に大変であるという現状があり、今後はSSVC、VEXなどのトリアージによって対応が必要な脆弱性がより少なくなる未来が見えました。まずはSSVCとVexLLMは触ってみたいと思います!

イベントの皆さんお疲れ様でした!!!むちゃくちゃ勉強になったのと、また次回も参加します!!ありがとうございました!

Pocket


adachin

1989年生まれのFindy/SRE。ホスティングから大規模なアドテクなどのインフラエンジニアとして携わる。現在はサービスの信頼性向上、DevOps、可用性、レイテンシ、パフォーマンス、モニタリング、オブザーバビリティ、緊急対応、AWSでのインフラ構築、Docker開発環境の提供、IaC、新技術の検証、リファクタリング、セキュリティ強化、分析基盤の運用などを担当している。個人事業主では数社サーバー保守とベンチャー企業のSREインフラコンサルティングやMENTA/TechBullで未経験者にインフラのコーチング/コミュニティマネージャーとして立ち上げと運営をしている。また、過去「脆弱性スキャナVuls」のOSS活動もしており、自称エバンジェリスト/技術広報/テクニカルサポート/コントリビュータでもある。

0件のコメント

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください