重要
年末年始休業 2023年12月29日～2024年1月3日
開発をしていると、開発対象のプロダクトが依存する外部パッケージの脆弱性報告を見ることが日々あります。CI/CDを動かしたところ、npmパッケージのバージョンが古いという指摘と「CVE」で始まる番号とが表示された、ということは、開発者の多くが経験していることでしょう。こういった脆弱性を放置していると、セキュリティ問題が発生したときに怖いものです。そこで、なるべく早く対応して、不安をなくしたいところです。
ところで、脆弱性対応はどのパッケージから・どのタイミングで行えばいいのか、その判断に迷っている開発者も多いのではないでしょうか。
多くの組織で行われているのは、脆弱性のレベル・影響・対応優先順位・対応方法を知りたい開発者がセキュリティ担当者に都度尋ねて判断をしていくという方法です。セキュリティ担当者は、開発者から脆弱性を内包するシステムの詳細をヒアリングしたうえで、開発者に回答するか、あるいは開発者と一緒に対応を考えていくことになります。
すると、
といった問題が起こりがちです。なかなか話が進まなかったり結局対応が行われなかったりすることは人的リソースの無駄ですが、セキュリティ担当者に実装を説明するために何時間も資料を書く羽目に遭ったり、ミーティングも1時間〜2時間を費やしたりしますが、これらの工数も見過ごせません。
そこで、脆弱性対応の判断と実施に人手と時間を最小限にすることが課題として浮かび上がってきます。そして、この課題を解決するには、事前に判断手順を決めておくことと、その判断手順通りに実行していくと関係者の間で合意することが必要です。
では、その判断手順はどのように決めていけばよいのでしょうか。
脆弱性対応の判断指標を算出する方法として、CVSS（Common Vulnerability Scoring System）と呼ばれるものがあります。
CVSSは、様々な条件をもとに脆弱性の深刻度を算出する方法で、2005年にv1が公開されて以来広く用いられ、2015年にほぼ現行となるv3が公開されています。多くの脆弱性情報には、CVSS v2・CVSS v3で算出した数値が記載されています。
CVSSでの深刻度は10.0までの数値で表現され、一般的には7.0以上であると危険、9.0以上であると特に危険であると考えられています。たとえば、OpenSSLのX.509証明書検証箇所におけるバッファオーバーフローの脆弱性CVE-2022-3602は深刻度が9.8と算出されたことから、多くのOpenSSL利用者が対応に追われました、また、2021年の年末から2022年の年始にかけて世界を震撼させ、やはり多くの開発者が対応に追われたApache Log4jの脆弱性「Log4Shell」ことCVE-2021-44228の深刻度は、10.0と算出されました。
ところで、Log4Shellへの対応は急を要するものであったことはすぐに知られましたが、それぞれのサーバーにあるLog4jの対応可否や要否、順序には頭を悩まされた方も多かったことでしょう。
CVSSでは基本評価基準・現状評価基準・環境評価基準という3つの基準で脆弱性を評価します。そして、IPAによる解説では、このうち環境評価基準について「脆弱性に対して想定される脅威に応じ、製品利用者毎に変化」すると説明されています。
これは、CVSSの深刻度として発表された数値は本来固定的に扱われるものではなく、自組織の状況に合わせて調整されるものだということを意味しています。
しかし、それぞれの組織で環境評価基準をもとに改めてCVSSの深刻度を評価することは困難です。なぜかというと、開発者・セキュリティ担当者とも、深刻度を改めて算出するに足る情報を持っていないからです。開発者はどのような実装をしているかは分かりますが脆弱性のレベルが分からず、セキュリティ担当者は脆弱性のレベルは分かりますがどのような実装をしているかは分かりません。
実際のところは、環境評価基準をもとに改めてCVSSの深刻度を算出したうえで評価している組織は、ほとんどないと思われます。
CVSSが持つこのような問題を解決するために、意思決定を行うための仕組みとして2019年に米カーネギーメロン大学ソフトウェア工学研究所から提案されたのがSSVC（Stakeholder-Specific Vulnerability Categorization）です。
SSVCには、意思決定を行うための仕組みに特化したいくつかの特徴があります。
SSVCではあらかじめ、サプライヤー・デプロイヤー・コーディネーターの3つのステークホルダーが定義されており、ステークホルダーごとの決定木が提案されています。
サプライヤーはソフトウェアベンダー、デプロイヤーはソフトウェアパッケージを利用して開発する人、コーディネーターは多数の組織の脆弱性対応を統制するステークホルダーを想定しています。
SaaSを開発している場合は、デプロイヤーの決定木を使うことが多いと思われます。
SSVCは意思決定を行うための仕組みを目指しているため、決定木として表現することができるという特徴を持っています。以下は、CERT/CCのDryad SSVC Calc App（後述）をもとに作成した、Deployer（前述の通り、ソフトウェアパッケージを利用して開発をする人を、SSVCではDeployerと分類します）のための決定木です。
SSVCが決定木であり算出方法ではないということは、質問に答えていくことで誰でも脆弱性への対応を決定していくことができるということを意味しています。前述のDryad SSVC Calc AppのDeployer決定木を見ると分かりますが、以下の設問に対してあらかじめ選択肢が用意されています。
そして、決定された意思もまた4つのうち1つに決まります。
具体的な対応時間は各組織で決めることになりますが、これは開発組織の状況次第ですので、運用しながら調節するとよいでしょう。
デモンストレーション環境として、CERT/CCによるデモサーバー『Dryad SSVC Calc App』
が用意されているので、簡単に試すことができます。
ただし、デモンストレーション環境だからでしょうか、期待した動きをしないことも多く、バギーなところがあるようです。
なお、Githubにソースコードがあるので、修正してプルリクエストを出すことや、フォークしてカスタマイズすることも可能です。
CERT/CC Demo Serverを実際に試してみた方は、その簡単さに驚かれたかもしれません。
実際、弊社でもSSVCの簡単さに驚き、脆弱性対応に組み込んでみようと考えました。
そのときの目標は、以下の通りです。
以下では、SSVCを使った弊社における脆弱性対応の流れを紹介していきます。
SSVCを使った弊社における脆弱性対応手順は、4ステップと簡単です。
いくらSSVCでは意思決定が簡単だといえど、すべての脆弱性をSSVCにかけることは現実的ではありません。ですから、適用対象の脆弱性を何らかの形で洗い出しておくことが必要になります。
もっとも簡単で一般的なのは、CVSSの深刻度を使うことです。CVSSの深刻度7.0以上は一般的に危険度の高い脆弱性です。深刻度9.0以上になると騒がれることも多く、この段階の脆弱性については緊急対応を検討したことがある人も多いと思います。
弊社では、この洗い出しにSnykを使っています。サービスがすべてクラウド上にあるので、認証が通っていなくても攻撃可能なものをリストアップすることとしています。
したがって、Synkで危険度が高いと表示され、かつ、認証が通っていなくても攻撃可能な脆弱性をSSVCにかける対象とします。
深刻度の高い脆弱性を洗い出したら、それらをSSVCの決定木で意思決定にかけていきます。できるだけ「ありもの」を使うべく、デモンストレーション環境ではありますが、弊社ではCERT/CCのデモサーバーである『Dryad SSVC Calc App』をそのまま使うことにしました。
まずはDryad SSVC Calc Appを開きます。そして、ステークホルダーの決定木として「Deployer-v2.0.0」を選択します。これは前述の通り、SSVCではステークホルダーによって決定木に違いがあり、ソフトウェアを使う開発者は「デプロイヤー」が最も近いと考えられるためです。
そして、以下の設問に順に答えていきます。
決定木の全体を見ても分かる通り、設問はいずれも選択式なので判断が属人化しにくく、明確にできます。
SSVCで意思決定した対応方針は記録しておきます。
現時点での弊社の開発組織は小規模なので、実のところ判断が属人化するリスクは極めて小さいのですが、開発組織が成長すると、SSVCでの意思決定を実施する人も増えてくるはずです。選択肢の解釈を揃える必要も出てきます。そのとき、どのように判断したのか・なぜそのように判断したのかといった記録が重要になってきます。
意思決定ができたら、あとは対応を実施していくだけです。脆弱性管理の判断基準はすでに定められていますから、「なぜこの対応をいますぐする必要があるのか」という問いには答えられますし、急な対応があっても、そういった対応が起こりうることは開発組織内で共有されていますから、脆弱性対応がきっかけとなって万が一のことが起こったとしても、迅速な対処が可能です。
弊社では以上のような脆弱性管理をはじめました。SSVCそれ自体はとてもよく考えられたもので、はじめることそのものに困ったことはなかったのですが、実際にはじめてみると、細かい困りごとが出てきました。以下では2点を紹介します。
開発環境に依存する点として、弊社ではSnykを使っていますが、Snykが同じパッケージの脆弱性でも複数のIDを割り当てることがあります。前述の通り、SSVCは現時点におけるネットワークの露出度など、脆弱性を持つコンポーネント（パッケージ）がどこでどのように使われているか次第で意思決定が変化してくるため、弊社ではいまのところ、いちばん緊急性の高い値を採用することにしました。たとえば「defered」と「scheduled」であれば「scheduled」を採用する、といった具合です。
また、脆弱性の中には、いわゆる「ゼロデイ」のような、解決策がないものもあります。弊社ではいまのところ、解決策がないものは、Criticalなものでない限りはSVCCにかける対象から外す判断をしています。スタートアップとして重視しているのはあくまで「迅速な意思決定」です。多くの組織では、既知・未知を問わず脆弱性が100%なくなることはないという前提のもと、脆弱性を回避・緩和するために多層防御を入れているはずです。それらを信頼せず、解決策がないものに時間を費やすことで、事業としてやるべきことや本来できるはずのセキュリティ対策を怠るのは、本末転倒です。
今回は、できるだけ工数をかけずにはじめるためDryad SSVC Calc Appを使って手動で運用することにしましたが、将来はCI/CDに組み込むなどの応用が考えられます。
また、Dryad SSVC Calc AppでJSONで記述した決定木を読み込むことができることからも分かるように、決定木のカスタマイズ次第では、ソフトウェアの脆弱性対応にとどまらず、組織の情報セキュリティ全般に応用することも考えられます。
弊社では、SSVC（Stakeholder-Specific Vulnerability Categorization）を使って、ソフトウェアの脆弱性対応にかかる意思決定を少ないリソースで迅速に意思決定し、遂行する仕組みを構築しました。
脆弱性情報に付随するCVSSの深刻度などから、意思決定を必要とする脆弱性をリストアップして、それをSSVCをベースとした手順で処理していきます。すると、脆弱性対応の要否や期限を誰でも明確に判断し、説明できるようになります。すると、従来のような、脆弱性対応の要否や期限をセキュリティ担当者と相談しながら決めることで消費される時間を大幅に削減することができるので、開発者が、最低限の人的リソースで対応できるようになります。
すなわち、開発業務にSSVCを取り入れることで、結果として開発者はより本来の業務に集中できるようになりますが、これは、弊社のビジョンでもある「業務が効率化・なくなる気持ち良さを世の中へ」にも通じる取り組みでもあります。
弊社の取り組みが、ご覧いただいたみなさまにとって「業務が効率化・なくなる気持ち良さ」をもたらすものとなれると幸いです。
