今、米国のサイバーセキュリティ当局を中心に、製品の開発段階でセキュリティを確保しようとする取り組み「セキュア・バイ・デザイン」と「セキュア・バイ・デフォルト」が進んでいる。製品から脆弱性を取り除くための“戦術”の内容を見てみよう。
この記事は会員限定です。会員登録すると全てご覧いただけます。
IT製品やサービスにおけるセキュリティ対策の責任をメーカーやベンダーに移すという意欲的な取り組みが、2023年4月13日に大きく盛り上がった。米国と英国、カナダ、ドイツ、オランダ、オーストラリア、ニュージーランドのサイバー当局が製品の設計と初期設定において安全性を確保するための推奨事項と戦術を同日発表した(注1)。
米国サイバーセキュリティ社会基盤安全保障庁(以下、CISA)と英国をはじめとする6カ国がまとめたセキュア・バイ・デザインの原則は、バイデン米政権が最近明らかにした「国家サイバーセキュリティ戦略」の裏付けとなるものであり(注2)、より具体的な行動指針となっている。
セキュア・バイ・デザインの原則には、ソフトウェアやインフラの設計に関する技術的な推奨事項や既定のセキュリティ対策のベストプラクティスなど、CISAや他のサイバー当局がこれまで共有してきた多くの推奨事項が含まれている(注3)。
テクノロジー部門に大きな責任を課す法律や規制を、すぐ簡単に施行できるわけではない。今のところ、この原則を実現する執行のメカニズムは存在しない(注4)。
この取り組みを推進するCISAは、全てのメーカーやテクノロジーベンダーに対して、顧客が次の3点を実施しなくても良いように製品を製造することを強く推奨している。
「現状は設計上の脆弱(ぜいじゃく)性があり、常に弱点が存在する状態だ」とCISAは述べる。意義ある変化を達成するためには、メーカーとITベンダーが設計と開発のプログラムを改革し、セキュリティの優先順位を高める必要がある。「セキュア・バイ・デザインの実践によってのみ、私たちは問題の発生と修正という悪循環を打破できる」とCISAはこの国際共同ガイダンスの中で述べている。
セキュア・バイ・デザインの開発には設計や開発などの各プロセスに多大な資源を投入する必要があることをCISAは認めている。メーカーは広い範囲にわたって脆弱性を排除するために、開発に使うプログラミング言語をよりセキュアな設計のものに移行し、魅力的だが攻撃を広げる可能性がある機能よりも、顧客を保護する機能を優先するよう求められている。
CISAは国際共同ガイダンスで「悪意のある攻撃者が脆弱性を利用するという永続的な脅威を終わらせる唯一の解決策はない。設計上安全な製品であったとしても完璧とは言い切れないため、脆弱性を抱え続けることになる。しかし、多くの脆弱性は比較的小さな根本的原因によるものだ。セキュア・バイ・デザインの原則は開発コストを増加させるかもしれないが、長期的にはメンテナンスやパッチのコストを下げる可能性もある」と述べる。
国際共同ガイダンスで概説されたセキュア・バイ・デザインの“戦術”は以下の通りだ。
1.Rust、Ruby、Java、Go、C#、Swiftなどのメモリ安全性の高いプログラミング言語
2.細かいメモリ保護を可能にする安全なハードウェア基盤
3.商用、オープンソース、サードパーティー開発者によるライブラリ、モジュール、ミドルウェア、フレームワークなどの安全なソフトウェアコンポーネント
4.クロスサイトスクリプティング攻撃を避けるために、ユーザー入力を自動的にエスケープするWebテンプレートフレームワーク
5.SQLインジェクション攻撃を避けるためのパラメータ化されたクエリ
6.静的および動的アプリケーションセキュリティテストを実行して、エラーが発生しやすいプラクティスを発見する
7.ピアレビューを実施する
8.ソフトウェアBOM(sBOM)の整備や管理(注5)
9.法的な問題を恐れずにセキュリティ研究者が脆弱性を報告できる脆弱性開示プログラム
10.侵入経路や既知の脆弱性リストを含む脆弱性情報詳細の把握
12.1つの制御システムが侵害されても全体に影響しないような、真相防御の原則に従って設計されたインフラ(注6)
13.CISAのサイバーセキュリティ性能目標を満たす対策と実践
国際共同ガイダンスによると、テクノロジーベンダーは安全な設定を初期設定の基準にすべきであり、顧客が初期設定から逸脱した場合、侵害の恐れが高まることを明確にすべきだ。セキュア・バイ・デザイン原則の基準を満たす製品は、最も重要なセキュリティコントロールを自動的に有効にし、追加費用なしで顧客がセキュリティコントロールを使用し、さらなる設定を実現する機能を提供する。
「セキュリティ設定の複雑さを顧客に押し付けてはならない」とCISAは国際共同ガイダンスの中で述べている。
国際共同ガイダンスによると、追加のセキュリティ設定は「新しい車にシートベルトが備わっているように」製品に初めから含まれるべきであり、高級オプションとして販売されるべきではない。
こうした考え方「セキュア・バイ・デフォルト」の“戦術”は以下の通りだ。
13.デフォルトの共通パスワードの廃止
14.特権ユーザーに対する多要素認証の義務化(注7)
15.アプリケーション群へのシングルサインオンの適用
16.顧客に高品質の監査ログを追加費用なしで提供すること
17.認証されたプロファイルに対する推奨ロールとそのユースケースの提示
18.後方互換性よりもセキュリティを優先すること
19.ハードニングガイドのサイズを一貫して縮小すること
20.セキュリティの設定に起因するユーザーエクスペリエンスへの負荷の評価
CISAはメーカーとITベンダーに対して、自社製品のセキュリティ対策の結果に責任を持つように働きかけている。
国際共同ガイダンスでCISAは次のように述べている。「IT部門はセキュア・バイ・デザインやセキュア・バイ・デフォルトの実践の重要性を強調する購入基準を策定するために権限を持つべきだ。企業は、技術サプライヤーからセキュア・バイ・デザインやセキュア・バイ・デフォルトの実践を採用するためのロードマップとともに、内部統制に関する透明性の確保についてもメーカーに期待する必要がある」
(注1)CISA, partner agencies unveil secure by design principles in historic shift of software security(Cybersecurity Dive)
(注2)NATIONAL CYBERSECURITY STRATEGY(The White House)
(注3)CISA aims for target rich, resource poor sectors in rollout of security basics(Cybersecurity Dive)
(注4)How will the government enforce the national cyber strategy?(Cybersecurity Dive)
(注5)What to know about software bill of materials(Cybersecurity Dive)
(注6)Explore CISA’s 37 steps to minimum cybersecurity(Cybersecurity Dive)
(注7)CISA demystifies phishing-resistant MFA(Cybersecurity Dive)
(初出)Explore the core tactics of secure by design and default
© Industry Dive. All rights reserved.