Security by Design の強化を目指す米国政府：メモリセーフな開発言語とは？ – RSA Con

RSAC: Decoding US Government Plans to Shift the Software Security Burden

2024/05/07 InfoSecurity — RSA Conference 2024 において、Security by Design の強化を目指す、米国政府の計画に対する分析が提供された。このイベントにおいて、米国 CISA の Senior Technical Advisor である Bob Lord は、ソフトウェア・セキュリティに関して受け入れられている、常識を克服することが急務であると述べている。

Bob Lord は、ソフトウェアの脆弱性が悪用された場合において、被害者を責めることに焦点が当てられがちであることを指摘している。たとえば、パッチ適用が十分でなかったという批判や、多要素認証 (MFA) が導入されていなかったという指摘である。

しかし、2023年に発表された米国政府の  National Cybersecurity Strategy では、ソフトウェア。メーカーに対して、これまでよりも多くの責任を負わせることで、このバランスの是正が試みられている。

米国政府関係者とサイバー・セキュリティの専門家たちは、この転換を実現するための２つの重要な方法について、カンファレンスの中で議論した。

Memory Safe Coding 言語の実装

数多くの分析により、深刻な脆弱性の約３分の２は、バッファオー・バーフローなどのメモリ安全性の問題であることが実証されている。たとえば、Microsoft の脆弱性において、その 70％ はメモリの安全性に起因するものである。

これらの脆弱性は、C/C++ コーディング言語が、ソフトウェア開発に広く使用されていることから生じている。そして、C/C++ には、メモリ問題に対するガードレールや安全性のメカニズムがない。

米国 DARPA の program manager である Dr Dan Wallach は、「毎年、私たちは、同じ問題を目の当たりにしている」と述べている。

C/C++ 言語への依存を減らすという試みの一環として、2024年2月にホワイトハウスは論文を発表し、技術業界に対して Memory Safe Coding 言語の採用を促している。

しかし、Dan Wallach は、C/C++ への依存を無くすことは容易ではない。特に代替となる Memory Safe Coding 言語の実行速度は遅く、より多くのメモリを使用することになると認めている。

幸いなことに、2000年代半ばに開発された Rust プログラミング言語は、他の言語のようなパフォーマンスのトレードオフがない。そして、このコンパイラがメモリ・セーフティを保証しているため、現在では C 言語に代わる実行可能な選択肢となっている。

Rustコーディングの実装方法

Rust の人気が高まっているとはいえ、現在の C 言語への依存度を考えると、Rust を広く実装することは大きな挑戦となるだろう。

そのために、ソフトウェア・メーカーとしては、開発者を Rust で書けるように再教育する必要が生じるが、そのためのインセンティブも必要となる。

Bob Lord は、「私たちは、ソフトウェア・プロバイダー自身に、より多くを要求をする必要がある」と述べている。また、Lord と Wallach は、メーカーが自社のソフトウェアを、メモリ・セーフにするためのロードマップも提示している：

• メモリ・セーフ言語を実装する段階を明確にする。
• 重要なマイルストーン、たとえば、メモリ・セーフ言語のみでコードを記述する期日を設定する。
• Rust でコードを書くための開発者トレーニング計画を策定する。
• C/C++ の依存関係に対処する計画を立てる。
• 定期的なアップデートを行うための、透明性のある計画を立てる。
• CVE プロセスにコミットし、脆弱性について可能な限り透明性を確保する。
• メモリ・セーフ言語の実装経験を、他の組織と共有する。
• CEOが計画に署名し、意図を示す。

ソフトウェア製造業者における責任への取り組み

RSA の別セッションでは、米国政府が手動することで、ソフトウェア・セキュリティの責任を効果的に製造業者へと移し、Security by Design を実践していく方法について、パネリストが議論した。

Office of the National Cyber Director (ONCD) の補佐官である Nick Leiserson は、「現在のユーザー負担のコストの一部を、開発者が負担することを確実にしていくことだ」と、ホワイトハウスの目標について述べている。

現時点においては、エンドユーザーによる潜在的な訴訟から、メーカーを保護するための、限定された責任を取り込んだソフトウェア・ライセンスが広く使用されている。したがって、安全なソフトウェア開発のためのインセンティブも存在しない。

Nick Leiserson は、このような契約の運用に取り組むためには、法改正が必要であることを認めている。いまの米国政府は、ソフトウェア特有の性質に対応する責任制度の、最善な適用を理解するための広範なプロセスを進めている。彼は、「私たちは、責任のための責任を求めているわけではない」と強調している。

カリフォルニア大学バークレー校法学部の James Dempsey は、このような責任体制を構築するために、政府が取るべき４つのステップを示している：

• 法的な枠組みの特定
• 注意基準を制定
• セーフハーバーの構築
• オープンソース・ソフトウェアへの対応

Nick Leiserson は、「政府が求めているのは厳格な責任体制ではなく、製造業者のインセンティブ構造を変えるような体制である」と付け加えている。

エコシステム全体からのインセンティブ

Bob Lord は、「ソフトウェア・メーカーの行動を変える鍵はインセンティブであり、さまざまな形でもたらされるはずだ」と、Infosecurity の取材で強調している。

最初の段階は、セキュアなソフトウェア開発における「良い」ものを、政府が明確にすることから始まる。それをエンドユーザーにとっての、セキュリティの結果の良し悪しのベンチマークとして使用することである。

この点において、ソフトウェア企業が「抜本的な透明性」に取り組むことを、同氏は望んでいる、つまり、自社のセキュリティ・プログラムや、機能すること、機能しないこと、問題の根本的な原因の分析を含む、脆弱性の完全な開示について語ることである。

それは、Bob Lord が「要求信号」と表現したもの、つまり、顧客が「優れたもの」を顧客が理解する道筋であり、その原則に従ってソフトウェアを構築するよう求めることに、結びつけられる必要がある。彼は、「それを調達プロセスの一部として、顧客により開始される必要がある」と述べている。

Bob Lord は、ソフトウェア開発者が、メモリ・セーフ・プログラミング言語を使用するよう訓練されるためには、インセンティブも重要だと付け加えている。そこには教育制度も含まれるため、この点でカリキュラムのスピードアップには、時間が必要だとしている。

しかし、ソフトウェア・メーカーが、自社のプログラマーに対して、メモリー・セーフ・コードの書き方を要求するようになれば、その達成は早まるだろう。

かれは、「採用担当者が C/C++プログラマーという求人を出している限り、大学は合理的な行動をとり、それを考慮に入れるだろう」と説明している。

今年の RSA Con は、話題が盛り沢山という感じですね。この Security by Design は、とても興味のある試みであり、オープンソース・コミュニティにインセンティブを提供できるという点で、限られた選択肢の１つではないかと思っています。どんどんと、注目が集まると良いですね。よろしければ、Security by Design で検索も、ご利用ください。