英国 NCSC 「許容できる脆弱性」と「許容できない脆弱性」を分ける方法... (2025.01.28)

こんにちは、丸山満彦です。

1年前の話なのですが、気になったものを見つけたので、備忘録...

英国のNCSCが、許容できる脆弱性と許容できない脆弱性を分ける方法についての報告書を公表していました...

脆弱性が生まれにくい開発エコシステムの構築ということは重要ですよね...

ということで、NCSCが、OSや開発フレームワークの提供者、開発者が、よりセキュアな環境を標準で提供・利用するよう促すために、「許容できる脆弱性」と「許容できない脆弱性」をわける方法を考えたようです。「許容できない脆弱性」を根絶し、「許容できる脆弱性」については緩和策や監視等による実務的な対応をしていくことによって、限られたリソースによる適切解を求めようとするもののようです...

で、「許容できない脆弱性」とは何か？が重要となるわけですが、「適切な対策が講じられていれば防げるはずの基本的な欠陥」という感じですね...「許容できる脆弱性」とは、「ゼロデイ脆弱性や、技術的・経済的制約により完全対処が困難な欠陥」となります。

この二つをわける指標として考えられたのが、コスト、認知度、技術的実現可能性の３つです。

---

1. コスト：直接コスト（ライブラリのライセンス取得など）と間接コスト（コーディング／再コーディングに必要な追加時間など）を含む。

2. 認知度：その緩和策がどれほど広く知られ、理解されているか。

3. 技術的実現可能性：実現可能性分析では、緩和策の成功可能性と達成の容易さを評価する。これには、緩和策の長所と短所の評価、および緩和策の技術的要件や前提条件（ハードウェアサポートなど）の評価が含まれる。

---

コストがかからず、認知度も高く、技術的実現可能性が高い脆弱性があれば、「それはあかんやろ」ということになるのに対し、コストもかかるし、あまり知られていないし、技術的な対応が難しいというものであれば、「そりゃしゃーないなぁ」ということになるという感じですかね...

興味深い内容で、紹介していなかったようなので、1年前！ですが、紹介です...

● NCSC

・2025.01.28 A method to assess 'forgivable' vs 'unforgivable' vulnerabilities