Common Configuration Scoring Systemによるコードからクラウドまでのセキュリティ強化

独自の重大度スコアリングは、アプリケーションセキュリティチームに大きな負担をかけることが少なくありません。新しいベンダーを導入するたびに、独自の重大度フレームワークを評価し、ツール間で評価されたリスクを変換する必要があります。この負担をなくし、SDLC全体の構成に対する明確なセキュリティ評価をお客様に提供するため、SnykはコードからクラウドまでのセキュリティルールセットをCommon Configuration Scoring System（CCSS）に準拠させていきます。

Snyk Security Researchチームによる今回のアップデートを通じて、開発者とセキュリティチームの双方が、セキュリティ上の問題をより適切に評価、優先順位付け、トリアージできるよう支援し、より安全で効率的な開発ライフサイクルの実現を目指す取り組みを前進させます。

最新バージョンのSnyk Infrastructure as Code (IaC)であるIaC+では、ルールとルールの重大度をCCSSに基づいて評価します。これによりSnykは、技術的な重大度（CCSS）、脅威インテリジェンス、アプリケーションおよびビジネスのコンテキストに基づき、Infrastructure as Codeやクラウド構成のリスクをより正確にスコアリングしてお客様に提供できるようになります。

重大度とは？

Common Vulnerability Scoring System（CVSS）やCommon Configuration Scoring System（CCSS）などの業界標準フレームワークは、脆弱性をスコアリングするための有用な手法と、誰もが共通して使える言語を提供します。プロバイダーが独自のフレームワークを考案する必要がなくなり、利用者は変換の手間なくベンダーを直接比較できます。

簡単に言えば、こうしたフレームワークは複数の指標と一連の計算式を定義し、各指標の値を0～10のスコアに変換するとともに、低・中・高・重大に該当する重大度を割り当てます。

重大度レベルとスコア

Common Configuration Scoring Systemとは？

Common Configuration Scoring System（CCSS）は、米国国立標準技術研究所（NIST）によって作成されました。CVSSを基に、ソフトウェアのセキュリティ構成に関する問題に対応するよう改良されています。IaCの設定ミスは本質的にセキュリティ構成の問題であるため、CCSSを適用できます。

CCSSに準拠することで、先に述べた問題の多くに対処できます。CVSSを基にした、なじみのある用語、指標、計算式を使ってIaCの設定ミスにベクトルを割り当て、問題のスコアと重大度を判定できます。

そのためSnykでは、IaCの設定ミスに重大度を割り当てる従来のプロセスを置き換えられます。CCSS標準への移行により、ベクトル、スコア、重大度を表示し、学習の負担を大きく増やすことなく透明性を高めることもできます。これは、現在CVSS脆弱性について行っている方法と同様です。

CCSSベクターのビジュアル解説（近日公開）

上記の問題に対するCCSSベクトルは`AV:L/AC:H/Au:M/C:P/I:C/A:N/PL:U/EM:A`です。これにより、基本スコアは`8.3`、重大度は`High`となります。上の図には最初の6つの指標が示されていますが、残りの2つである`PL`と`EM`、つまり`Privilege Level`と`Exploitation Method`は表示されていません。これら2つの指標は重要な役割を果たす一方、基本スコアには影響しないためです。

`Privilege Level`は`User`、`Application`、`Root`、`Not Defined`のいずれかで、攻撃者が不正に取得し得るアクセス権限のレベルを示します。基本ベクトルと基本スコアでは、`PL`は利用者に追加情報を提供するものであり、特定の環境指標の計算に使用されます。

`Exploitation Method`は、基本指標の多くの値が`EM`指標の値に左右されるため、少し興味深い指標です。`EM`の値は`Active`または`Passive`です。`Active`の設定ミスは、AWS S3バケットが誰でも読み取り可能になっている場合や、デフォルトのrootユーザーパスワードが設定されたデータベースが公開されている場合のように、攻撃者に悪用される脆弱性を露呈させます。`Passive`の設定ミスは、許可された操作を妨げるものや、ディフェンダーの作業を困難にするものに分類されます。たとえば、APIログが無効になっている場合や、データベースのバックアップが十分な期間保持されない場合などです。`Passive`の設定ミスは通常、すぐに軽減できるエラーやポリシー違反です。一方、`Active`の設定ミスは、より複雑で、計画や分析が必要になることがあります。

SnykではCCSSをどのように導入したのか？

Snykには、IaCやクラウド構成のセキュリティを検査するための多数のセキュリティルールがあり、従来のプロセスで重大度を割り当てていました。CCSSベクトルを手作業で追加し、スコアを計算し、新しい重大度を導き出すのは、非常に骨の折れる作業です。スクリプトを使えば効率化できますが、判断能力には限界があります。幸い、より良い方法があります。

実装プロセスにAIを取り入れ、既存のルールセットをCCSS標準に準拠させる作業を効率化しました。独自の専門知識を反映したプロンプトでAIを活用することで、それぞれの設定ミスの重大度を一貫性と精度をもって判定できます。この進歩により、ユーザー向けのセキュリティ評価の透明性と信頼性が高まるだけでなく、開発者中心のセキュリティをリードするというSnykの取り組みも強化されます。

AI活用に関するこれまでの経験を生かし、CCSSの仕様をプロンプトにまとめ、調査に基づく追加のガイドラインを加えました。結果を分析したところ、重大度の内訳は次のように変化しました。

重大度別のルールの割合

そして、次のようになりました。

CCSSの重大度別ルールの割合

上のグラフは、従来のSnykの重大度評価が、CCSSと比べて大幅に保守的だったことを示しています。

重大度システムをCCSSに準拠させることで、ルールの重大度を再現可能な方法で判定できるだけでなく、Snykのリスクスコアなど、詳細な分析に役立つ貴重なコンテキストデータも保持できます。さらに、データセット全体の基本スコアの分布を分析すると、釣鐘型のパターンが見られます。これは0～10のスコアに期待される統計的分布と一致しており、AIを活用したバランスの取れた予測可能な重大度評価を実現するCCSSの信頼性を裏付けています。

基本スコアの分布

今後のSnyk IaCは？

セキュリティリサーチの最新情報や、CCSS重大度の展開については、updates.snyk.ioをご覧ください。

約20年にわたって使われているCommon Vulnerability Scoring System（CVSS）について詳しく知りたい方は、これまでに何度も、何度も取り上げてきた記事をご覧ください。

セキュリティリサーチのプロセスを強化する開発ツールとしてのAI活用については、こちらで解説しています。ベストプラクティスもご紹介しています。