セキュア・バイ・デザインとは？

セキュア・バイ・デザインとは？

セキュア・バイ・デザインは、製品が市場に出る前に悪用される可能性のある欠陥を最小限に抑えることで顧客と一般の人々を保護するという明確な目的を持つという意味で、従来提案されてきた業界基準をはるかに凌駕しています。 これらの原則を採用する企業は、テスト、認証の安全対策、プログラミングのベストプラクティスの遵守に重点を置き、堅牢で回復力のあるソフトウェアおよびハードウェアソリューションを作成することになります。 

米国のサイバーセキュリティ・インフラセキュリティ庁 (CISA) の セキュア・バイ・デザインの誓約に署名した組織が率いる産業界のリーダーたちは、セキュア・バイ・デザインの原則を優先してより積極的かつ効果的なサイバーセキュリティを目指し、より安全なインフラストラクチャとアプリケーションを実現することで、 規制要件を満たすだけでなく、ユーザーとの信頼関係を構築し、すべての人にとってより安全なデジタル環境を育んでいます。 

関連項目: セキュア・バイ・デザインの誓約: より安全なデジタルの未来を創造するための取り組み

さまざまな業界団体や政府機関が、安全なソフトウェア開発方法論を推進するガイドラインやベストプラクティスを発表しています。 これらはセキュア・バイ・デザインのコンセプトに沿った原則を重視していることがよくあります。  

最近の顕著な例では、米国国立標準技術研究所 (NIST) と その他の米国機関が 2023 年 4 月に発表した「サイバーセキュリティ リスクのバランスの転換: セキュア・バイ・デザイン ソフトウェアの原則とアプローチ」と題する共同ガイダンス文書があり、ソフトウェア開発において重要性が高まりつつあるセキュア・バイ・デザインの原則に焦点を当てています。  

セキュア・バイ・デザインは大部分の米国企業にとって任意ですが、 連邦政府の請負業者や他国の企業は、重要なインフラストラクチャのセキュリティをサポートすることを製品によって保証するために、サイバーセキュリティ ガイドラインへの適合が義務付けられていることがよくあります。 こうした規制やガイダンスによって、安全なサイバー環境をグローバルに構築するために国際的なパートナー間で行われる協調的な取り組みも促進されています。 

セキュア・バイ・デザインの誓約

この誓約は、米国サイバーセキュリティ・インフラセキュリティ庁 (CISA) が開始した自主的な取り組みであり、ソフトウェア メーカーがソフトウェア製品とサービスの開発ライフサイクル全体を通じてセキュリティを重視することを奨励するものです。 主な特徴は以下のとおりです。 

対象者

この誓約は、オンプレミス、クラウド サービス、SaaS 製品を含むエンタープライズ ソフトウェアを開発する企業を対象としています。 直接的に言及されてはいませんが、IoT デバイスなどの物理的な製品を製造する企業も、セキュア・バイ・デザインの原則に取り組むよう推奨されています。 

測定可能なアクションに焦点を当てる 

この誓約は署名者に対し、署名後 1 年以内に、セキュア・バイ・デザインの原則に沿った具体的かつ測定可能なアクションを実行することを奨励しています。 

主要な目標 

この誓約では、ソフトウェアメーカーが セキュア・バイ・デザインに取り組むべき7つの主要分野を概説しています。 

• 製品全般に多要素認証 (MFA) の使用を増やす 
• デフォルトのパスワードへの依存を減らし、強力なパスワードによる管理の実践を促進する 
• ソフトウェア内の脆弱性クラス全体を最小限に抑えるための戦略を実装する 
• 顧客がセキュリティ パッチをタイムリーにインストールするよう推奨する 
• 明確かつ包括的な脆弱性開示ポリシーを確立する 
• 特定された脆弱性 (CVE) に関する詳細な情報を提供して修復を容易にする 
• ソフトウェア内の潜在的なセキュリティ インシデントを検出し、対応するためのメカニズムを実装する 

透明性と進捗報告   

署名者は目標達成に向けた進捗状況を公表し、業界の透明性と説明責任を強化することが求められます。  

セキュア・バイ・デザインの原則 

セキュア・バイ・デザインの原則は、セキュリティを強化したいソフトウェア プロバイダーに明確なガイダンスを提供することを目的としています。 

最低限の権限 

この原則により、ユーザーとシステムはその役割に必要なアクセス権のみを持つようになり、攻撃対象領域が制限され、不正なデータ アクセスのリスクが最小限に抑えられるため、脅威やエラーによる被害が限定的になります。 この実装には役割に基づいた厳格なアクセス制御と定期的な更新が含まれ、サイバー脅威に対するセキュリティが強化されます。 

職務の分離 

複数の関係者またはシステムに責任が分散され、単一の組織が重要なプロセスを制御することを防ぎます。これによって不正、エラー、権限の濫用の可能性を低減します。  

安全な開発ライフサイクルでは、開発、テスト、展開などの役割がさまざまなチームに分割され、単一の個人によって気付かれずにシステムが変更されないようにします。 さらに、この原則を維持するための自動安全対策も盛り込まれています。 

多層防御 

このアプローチでは、単一の防御では完全に安全ではないことを認識し、複数のセキュリティ層を使用して資産を保護します。 ファイアウォール、侵入検知システムに加えて、ハードウェア、ソフトウェア、手順に関する定期的なセキュリティ監査など、さまざまな安全対策が盛り込まれています。  

この方法は、さまざまな種類の脅威に対処し、侵入者に対して複数のハードルを追加することで脆弱性を大幅に低減し、組織のセキュリティ フレームワークを強化します。 

セキュア・バイ・デザインに参加するメリット 

ソフトウェア プロバイダーが セキュア・バイ・デザインの誓約に参加すると以下のメリットがあります。 

• セキュリティへの取り組みを示す: 誓約書に署名することで、企業が安全なソフトウェア開発手法に取り組んでいることを公に示します。 これによってブランドの評判が向上し、潜在的な顧客との信頼関係が構築されます。 
• 測定可能なセキュリティに重点を置く: この誓約は、セキュリティに対する結果重視のアプローチを奨励し、ソフトウェア製品のセキュリティ体制を明らかに改善する具体的なアクションを推進します。 
• 連携とナレッジシェアリング（知識共有）: この誓約により、業界関係者間の連携とナレッジシェアリングが促進され、安全なソフトウェア開発手法が集団レベルで向上することにつながります。 

顧客やユーザーにもメリットがあります。 ソフトウェア プロバイダーがセキュア・バイ・デザインの原則に従ったソリューションとプラットフォームを提供する場合、最も重要なメリットは顧客が体験するメリットです。 

• 保護の強化: セキュリティ機能が最初からソフトウェアに組み込まれていると、ソフトウェアはより強力になり、脆弱性も低減します。また、ソフトウェアが稼働しているネットワークも同様に安全となって強化されます。 
• DEXの強化: 開発中からセキュリティとテストに重点を置くことによって、より安定感があり、中断に強く、より最適化された製品が実現し、従業員のエクスペリエンスが向上します。 
• 最大投資収益率 (ROI) 向上: より安全な製品により、ダウンタイムとパッチを適用する必要性が最小限に抑えられ、ユーザーの生産性を保つことができます。 
• 合理化されたコンプライアンス: セキュア・バイ・デザイン ソフトウェアを使用すると、厳格なデータ プライバシーとセキュリティ要件を簡単に遵守できるようになり、コンプライアンス適合のために必要な時間とリソースが削減され、制裁を回避できます。 
• 評判の向上: セキュリティを優先的に考える企業は信頼性があるとみなされ、顧客の信頼と忠誠心を高めることができます。 

ソフトウェア製品における セキュア・バイ・デザインの実装

最初からセキュリティを組み込んだソフトウェアを開発することは、ソフトウェアの作成方法に抜本的な変化をもたらします。 歴史的にソフトウェアは、多くの場合、製品の開発後に「ボルトオン セキュリティ」と呼ばれる機能を追加する設計になっていますが、  

それはソリューションにセキュリティが組み込まれていないことを意味します。 コアとなる製品と追加機能が結合している場合、その箇所が攻撃者にとっての脆弱点となる可能性があります。 

セキュア・バイ・デザインは、ソフトウェア開発ライフサイクル (SDLC) 全体を通じてセキュリティ対策を最優先に考慮することを重視しています。  

コードが記述されるまで待つのではなく、プロセス全体に セキュア・バイ・デザインの原則を取り入れることで、計画と設計の段階からセキュリティに重点が置かれるようになります。 このアプローチでは、潜在的な脅威を早期に特定し、防御策をソフトウェアのアーキテクチャに直接組み込みます。

安全なコーディング手法は、セキュリティの脆弱性を事前に解決するソフトウェアの開発には不可欠です。 OWASP (Open Worldwide Application Security Project) などのガイドラインに基づいて、コードレビューや静的解析を実行すると、セキュリティの問題を早期に発見するのに役立ちます。 重要なプラクティスとして、入力検証、機密情報のハードコードは回避すること、安全なライブラリを選択することなどがあります。 継続的な脆弱性スキャンや脅威モデリングのためのツールを利用することで、サイバー脅威に対するソフトウェアのセキュリティはさらに強化されます。 

開発のあらゆる段階で徹底したセキュリティ テストを実施することで脆弱性を早期に発見して解決してエンドユーザーに問題が発生するのを防ぐことができ、 ソフトウェア開発ライフサイクル (SDLC) の後半、あるいは製品のリリース後（さらに深刻となる）にこれらのトラブルに対処するコストと複雑さを回避できます。 

セキュア・バイ・デザインの原則を適用することで、開発者はコードセット内でSAS (静的アプリケーション セキュリティ テスト) とDAS (動的アプリケーション セキュリティ テスト) を実行し、テストや脅威モデリングを SDLC プロセスの最後に行うのではなく、プロセス全体でユニット テストと統合テストを実施できるようになっています。  

セキュア・バイ・デザインの原則に従うためにソフトウェアに組み込む必要がある主な機能は以下のとおりです。 

• 認証と、既知のもの (パスワード) / 所有物(スマートフォン) / 固有のもの (生体認証) のいずれかを組み合わせる ロールベースアクセス制御 (RBAC) とポリシーベースアクセス制御 (PBAC) による承認により、ユーザーが必要なアクセス権限のみを取得するようにしてリスクを軽減する 
• 暗号化とデータ保護 暗号化は、AES (高度暗号化標準) 方式や RSA (マサチューセッツ工科大学の科学者 Rivest、Shamir、Adleman にちなんで命名) 方式などのアルゴリズムを使用して、保存時および転送中の機密データを保護します。 適切な暗号化には、データとは別に保存されたキーとハードウェア セキュリティ モジュール (HSM) の使用による安全なキー管理が必要です。 定期的なプロトコルの更新と監査によりセキュリティは強化されます。 

セキュア・バイ・デザインの課題

セキュア・バイ・デザインを実現するには課題があり、組織はそれに対処するための計画を立てておかなければなりません。 

• 開発カルチャーの転換: 機能に重点を置いた開発プロセスから、最初からセキュリティを統合した開発プロセスに移行するには、開発チーム内のカルチャーが大きく変わることが必要です。 セキュリティは、単なる追加機能ではなく、製品の重要な側面として捉えるべきです。 
• セキュリティと使いやすさのバランス: 強力なセキュリティ対策によって、ユーザーエクスペリエンスが損なわれてはなりません。 セキュリティと使いやすさの適切なバランスを見出すことは、ユーザーがソフトウェアに慣れたり、全体的にポジティブな体験をユーザーにもたらすために重要です。 
• レガシー インフラストラクチャとコード: 多くの組織には、セキュリティを考慮せず設計された可能性のある、古いコードベースに基づいて構築された既存のソフトウェア製品があります。 これらのレガシー システムに安全な設計原則を後から取り入れることは、複雑で時間がかかる可能性があります。 
• 継続的な脅威の状況: サイバーセキュリティの状況は常に進化しており、常に新たな脅威が出現しています。 セキュア・バイ・デザインはその場しのぎではありません。最新の脅威を常に把握し、それに応じたセキュリティ対策を講じるという継続的な取り組みが求められます。 
• 熟練した労働力の不足: セキュア・バイ・デザインを効果的に実装するには、セキュリティの専門知識を有するチームが必要ですが、 サイバーセキュリティの専門家は世界的に不足しており、組織にとって、セキュア・バイ・デザインの原則を完全に適用するために必要な有資格の人材を見つけることは困難である可能性があります。 
• ユーザーの関与: プロバイダーは、設計プロセスにエンドユーザーを関与させ、フィードバックを収集して使いやすいセキュリティ機能を作成しなければなりません。 セキュリティのベストプラクティスに関する継続的な教育も、ユーザーに負担をかけることなく人的エラーを減らすために重要です。 

セキュア・バイ・デザインの用語

セキュア・バイ・デザインの原則と、すでによく知られるサイバーセキュリティ用語との関連を以下に示します。 

• 攻撃対象領域: サイバー攻撃者がシステムやデータにアクセスするために悪用できるすべての潜在的なエントリーポイント。 セキュア・バイ・デザインは、脆弱性を減らすことで攻撃対象領域を最小限に抑えることを目的としています。 
• ブラック ボックス テスト: システムの内部機能についてテスト担当者が把握せずに行うセキュリティ テスト手法。 セキュア・バイ・デザインは、ブラック ボックス テストで検出可能な脆弱性を最小限に抑える安全なコーディング プラクティスを推奨します。 
• コンポーネント セキュリティ: ライブラリからフレームワークまで、すべての個別のソフトウェアのコンポーネントがセキュリティを考慮して構築されるようにする原則。 セキュア・バイ・デザインは、サードパーティ コンポーネントを安全に選択して統合することを重視しています。 
• データの最小化: 特定の目的のために必要な最小限のデータのみを収集、保存、処理する手法。 セキュア・バイ・デザインは、データ侵害の潜在的な影響を軽減するためにデータの最小化を推奨します。 
• 暗号化: 復号化キーでのみデータにアクセスできるスクランブル形式に変換するプロセス。 セキュア・バイ・デザインは、機密データを保護するために強力な暗号化アルゴリズムの使用を促進します。 
• ファームウェア セキュリティ: ハードウェア デバイスを制御するローレベルコードを保護する手法。 セキュア・バイ・デザインは、安全なコーディング手法の使用とファームウェアの定期的な更新を推奨しています。 
• グレー ボックス テスト: システムの内部機能についてテスト担当者が部分的に把握して行うセキュリティ テスト手法。 セキュア・バイ・デザインは、グレー ボックス テストのシナリオとブラック ボックス テストのシナリオのいずれもが適切に動作するコードを推奨しています。 
• インシデント対応計画: 組織がセキュリティ インシデントの際の対処計画を文書化。 セキュア・バイ・デザインは、潜在的なセキュリティ侵害のための積極的な計画を推奨しています。 
• 入力検証: 悪意のあるコードインジェクション攻撃を防ぐために、ユーザー入力を検証およびサニタイズするプロセス。 セキュア・バイ・デザインは、堅牢な入力検証手法を重視しています。 
• ジャストインタイム アクセス: 絶対に必要な場合にのみ、必要な期間だけリソースへのアクセスを許可します。 セキュア・バイ・デザインは、権限を最小限に抑え、ジャストインタイム アクセス管理を使用することを推奨しています。 
• 既知の脆弱性: 攻撃者が悪用する可能性があるソフトウェアの弱点を文書化。 セキュア・バイ・デザインは、既知の脆弱性を常にアップデートし、システムに速やかにパッチ適用を行うことを重視しています。 
• 最小権限: ユーザーに、業務を遂行するために必要な最低限のアクセス権限のみを付与する原則。 セキュア・バイ・デザインは、侵害されたアカウントによって生じうる損害を最小限に抑えるために、最小権限を推進しています。 
• 多要素認証 (MFA) : システムにアクセスするためにパスワード以外の 2 番目の検証要素を必要とする追加のセキュリティ層。 セキュア・バイ・デザインは、重要なセキュリティ管理として多要素認証 (MFA) を重視しています。 
• ペネトレーションテスト: サイバーセキュリティの専門家がハッカーを装ってシステムの脆弱性を悪用しようと試みるセキュリティ テスト手法。 セキュア・バイ・デザインは、セキュリティ上の弱点を特定して対処するために、定期的にペネトレーションテストを行うことを推奨しています。 
• オープンソース セキュリティ: オープンソース コンポーネント上に構築されたソフトウェアのセキュリティを確保する手法。 セキュア・バイ・デザインは、既知の脆弱性に重点を置いたオープンソース ライブラリを慎重に選択して管理することを推奨しています。 
• パッチ管理: ソフトウェアの脆弱性を修正するためにセキュリティ パッチを特定、取得、展開するプロセス。 セキュア・バイ・デザインは、パッチ管理に対するプロアクティブなアプローチを重視しています。 
• 品質保証 (QA) : ソフトウェアがセキュリティ要件を含む特定の要件と標準を満たしていることを確認するプロセス。 セキュア・バイ・デザインは、セキュリティに関する考慮事項を QA プロセスのすべてのフェーズに取り入れます。 
• リスク管理: セキュリティリスクの特定、評価、軽減。 セキュア・バイ・デザインは、最も重大な脅威を念頭に置いて、リスクに基づくセキュリティ アプローチを推奨します。 
• セキュアコーディング手法: ソフトウェア開発中に脆弱性がもたらされるのを最小限に抑えるコーディング手法。 セキュア・バイ・デザインでは、開発者にセキュアコーディング手法のトレーニングを行うことを重視しています。 
• 脅威モデリング: システムに対する潜在的な脅威を特定して分析するプロセス。 セキュア・バイ・デザインは、開発プロセスの早い段階で脅威のモデリングを行い、セキュリティ上の懸念に積極的に対処することを推奨します。 

関連事項: セキュア・バイ・デザインの目標に向けた Ivanti の進捗状況