CISAが事業者に要求する「セキュリティ・バイ・デザイン」、多要素認証の必須化やメモリセーフなプログラミング言語への切り替えなどを推奨【海外セキュリティ】

米国政府、セキュアな製品とサービスの提供を事業者に要求、将来的には法規制も

　米サイバーセキュリティ・インフラセキュリティ庁（Cybersecurity & Infrastructure Security Agency、以降CISA）のジェン・イースタリー（Jen Easterly）長官は、2023年2月27日にカーネギーメロン大学（Carnegie Mellon University、以降CMU）で行なった講演において、ソフトウェア製品やサービスなどを提供している事業者は、利用者がパッチを適用したり、セキュリティ機能を高価な付加機能として購入したりしなければならないなど、セキュリティの負担が利用者に課せられている現状を当然のこととせず、セキュアな製品やサービスを提供することにもっと力を入れるべきと述べました。いわゆる「セキュリティ（セキュア）・バイ・デザイン」や「セキュリティ（セキュア）・バイ・デフォルト」を事業者に要求するもので、この講演の2日後、同年3月1日付でバイデン政権が発表した「国家サイバーセキュリティ戦略（National Cybersecurity Strategy）」の内容を見越しての発言とみられます。

　講演の中でイースタリー長官は、自動車関連製造業者、特にエアバックの欠陥問題を起こしたタカタを例に挙げ、自動車部品の欠陥に対する責任は、たとえ運転手のミスによって欠陥が顕在化したとしても、その欠陥をもたらした生産者にあるのが一般的であるとし、その上で以下のように述べています。

　ソフトウェアの脆弱性を全て防ぐことは不可能でしょうが、私たちが毎月の「パッチチューズデー」を普通のこととして受け入れてしまっている事実は、私たちが事故境界線（accident boundary）上で危険な運用を積極的に行っていることを示す更なる証拠となっています。

　そして事業者側の対策として、イースタリー長官は既知のソフトウェア脆弱性の約3分の2がメモリの安全性に関わるものであることを踏まえて、RustやGo、Python、Javaのようなメモリセーフなプログラミング言語への切り替えを勧めています。また、デフォルトでのセキュリティの例として多要素認証（Multi-Factor Authentication、以降MFA）の必須化を挙げ、現在のMFAの利用者の割合を実例を以下のように挙げて紹介しています。

　イースタリー長官は、Appleの実績を賞賛する一方、TwitterとMicrosoftの数字は残念であるとしつつも、そのような数字でも正直に公開している両社の透明性については評価しているようです。

　また、CMUに限らず、大学関係者全般に向けて以下のような提案をしています。なお、これらの中にはCMUでは既に実践しているものもあるようです。

1. 大学の授業科目をメモリセーフな言語に移行
2. 全てのコンピューターソフトウェアのコースワーク（カリキュラム）の中にセキュリティを織り込む
3. オープンソースコミュニティへの貢献
4. 全ての開発者と全てのビジネスリーダーが（セキュアな方向に）切り替えてくれるのを手助けする方法を見つけて欲しい

　最後に聴講している学生たちに向けて以下のように訴えています。

　想像してください。今日お話ししたことが何一つ実現せず、セキュリティの負担が消費者に課され続け、技術メーカーは安全でない製品を作り続け、高価な付加機能としてセキュリティを売り続け、大学は安全でないコーディング手法を教え続け、我々が毎日利用しているサービスが脆弱なままという世界を。このような世界を、敵は注意深く観察し、決して変わらないことを望んでいるのです。

　世の中にはセキュリティをそもそも考慮していない「脆弱な」製品やサービスは確かに存在しており、イースタリー長官の主張はもっともなものではあります。しかし、自動車の例を出すのはあまりに極端で、そのレベルを要求する（ように見える）のは現実的には無理があります。もちろん、イースタリー長官としてはあくまで講演として分かりやすく説明するための例えだったのでしょうが、米国のサイバーセキュリティを所管する機関の代表者の発言だけに、不安を覚えた関係者は少なくないのではないかと思います。

　ちなみに、イースタリー長官の講演の2日後にバイデン政権が発表した「国家サイバーセキュリティ戦略」の3.3節「Shift Liability for Insecure Software Products and Services（セキュアでないソフトウェア製品およびサービスに対する責任の転換）」には以下のような記述があります。

　最先端のソフトウェア・セキュリティ・プログラムであっても、全ての脆弱性を防ぐことはできないことを認識する一方で、我々はソフトウェアの安全性を確保するための合理的な予防措置を怠った事業者に責任を負わせることを始めなければならない。ソフトウェアを作成する企業には技術革新の自由がなければならないが、消費者や企業、重要インフラの提供者に対して負うべき注意義務を果たせなかった場合には責任を負わなければならない。セキュアでないソフトウェアがもたらす結果に負担を強いられることが多いエンドユーザーや、商用製品に組み込まれるコンポーネントのオープンソース開発者ではなく、悪い結果を防ぐために行動を起こせる能力を最も持っているステークホルダーに責任を負わせる必要がある。そうすることで、より安全な製品やサービスを生み出すための市場が活性化し、イノベーションと、新興企業やその他の中小企業が市場のリーダーと競争する能力が維持されるであろう。

　政府は議会および民間セクターと協力して、ソフトウェア製品およびサービスに対する責任を確立する法律を策定する予定である。そのような法律はいずれも、市場力を持つメーカーやソフトウェア提供者が契約によって責任を完全に放棄することを防ぎ、特定の高リスクのシナリオにおいてソフトウェアに対するより高い注意基準を確立するものであるべきである。セキュアなソフトウェア開発のための注意基準を策定し始めるために、適用可能なセーフハーバーの枠組みの開発を推進し、ソフトウェア製品およびサービスをセキュアに開発・維持する企業を責任から保護する予定である。このセーフハーバーはNIST Secure Software Development Frameworkなど、セキュアなソフトウェア開発のための現在のベストプラクティスをもとにする予定である。また、これはセキュアなソフトウェア開発、ソフトウェアの透明性、脆弱性の発見のための新しいツールを取り入れながら、時間とともに進化していく必要がある。

　つまり、やみくもにソフトウェアやサービスの製造者責任を追及するのではなく、「悪い結果を防ぐために行動を起こせる能力を最も持っているステークホルダー（the stakeholders most capable of taking action to prevent bad outcomes）」を対象としているわけですが、その「行動を起こせる能力を最も持っているステークホルダー」をどのように定義するかは決して容易ではなく、これからどのような議論がなされるのか注視する必要があります。そして、この3.3節は以下のように結ばれています。

　セキュアなソフトウェア開発手法の採用をさらに促すため、政府は全ての技術のタイプおよびセクターにわたる協調的な脆弱性開示を推奨し、SBOMのさらなる開発を促進し、広く使用されている、または重要インフラを支えているサポート切れのソフトウェアがもたらすリスクを特定・軽減するプロセスを構築する予定である。また、民間セクターやオープンソースソフトウェアのコミュニティと連携して、連邦政府は、メモリセーフな言語やソフトウェア開発技術、フレームワーク、テストツールなど、セキュアなソフトウェアの開発への投資を継続する予定である。

　「セキュリティ（セキュア）・バイ・デザイン」や「セキュリティ（セキュア）・バイ・デフォルト」は当然求められるべきものであり、その要求レベルがどの程度になるかは別として、要求自体は今後ますます強くなっていくのは確実であり、今回のイースタリー長官の講演はそれを端的に示すものだったと言えるでしょう。

CISAの「既知の悪用された脆弱性カタログ」に2022年に追加された脆弱性

　本連載の2022年2月の記事でも紹介したように、CISAは連邦政府機関向けに2021年11月から「Known Exploited Vulnerabilities（既知の悪用された脆弱性、以降KEV）Catalog」を公開しています。これに対し、米国の脆弱性インテリジェンス企業VulnCheckは2022年にこのカタログに追加された脆弱性を分析した結果を自社のブログで公開しました。

　分析結果の主要なポイントは以下の通り。

• KEVカタログは311件のCVEで2022年を迎え、年末までに3倍近くに増え、合計868件に達した。
• 2022年の新規追加の大部分は新しい脆弱性のためのものではない。557件のCVEのうち、CVE-2022の識別子を使用していたのは17％のみである。追加された脆弱性で最も古いのは2002年のものである。
  

• CISAは2022年に93件のCVE-2022脆弱性をカタログに追加した。つまり、防御側のほとんどは毎週ほぼ2件の脆弱性が新しく公開されると予測できることになる。
• 新たに追加された557件のCVEのうち、EternalRomance、EternalBlue、EternalChampion、Shellshock、Heartbleed、EskimoRoll、Dogwalk、SpoolFool、Dirty Pipe、ProxyNotShell、Ripple20など、22件の名前のついた脆弱性が追加された。
• 2020年の初めから、VulnCheckは400以上の名前のついた脆弱性を追跡してきた。しかし、2022年には、KEVに追加されたCVEのうち、関連する名前があったのはわずか4％だった。残りの96％には名前がなかったが、世の中で広く悪用されるには十分なものであった。
• 2022年に、KEV（カタログに追加された脆弱性）はオペレーティングシステム、IoT、デスクトップアプリケーション、ウェブブラウザーに対して最も多く武器化された。
• VulnCheckは新たに追加された脆弱性のうち122件（22％）をランサムウェア攻撃での使用に関連づけた。
• 新たに追加された557件のうち、200件（35.9％）は初期アクセスの脆弱性であり、VulnCheckはクライアントサイド、ローカル、およびクレデンシャル攻撃よりも優先することを推奨している。
• 2022年に公開されたCVEに対するKEVエントリのおよそ11％は、周知のエクスプロイトまたはエクスプロイトの詳細が公開される前または公開された同じ日に追加された。しかし、ほぼ半数（48％）の脆弱性はカタログに追加されるまでに1週間以上かかっている。

　他にも興味深いのは、2022年に追加された557件の脆弱性が1年間で同じペースで追加されたのではなく、そのうちの約4割にあたる226件が2022年3月に追加されている点です。

　KEVカタログはあくまで米国の連邦政府機関を対象としたものなので、当然ながら、日本では広く使われていても米国では使われていない製品については載ることがないため、そのままでは日本の企業や組織における脆弱性管理に使うには十分とは言えませんが、それでも大いに参考になる情報であることは確かです。今回のVulnCheckの分析では今回紹介した以外にも様々な分析結果が紹介されていますので、KEVカタログを利用しているか否かにかかわらず、脆弱性管理に携わっている方には一読をお勧めします。