セキュア・バイ・デザインとは
セキュア・バイ・デザインまたはセキュリティ・バイ・デザインとは、設計段階からセキュリティを考慮してシステム開発をする考え方です。
内閣サイバーセキュリティセンター（NISC）では、「情報セキュリティを企画・設計段階から確保するための方策」として、セキュリティ・バイ・デザインという言葉で定義しています。
また、米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）の発行するガイダンスでは、セキュア・バイ・デザインを、「技術製品が、悪意あるアクターによって端末機器、データ、インフラに不正にアクセスできないよう合理的に保護されている形で作られること」と定めており、セキュリティ・リスクアセスメントにより、サイバー脅威を特定し、防御策を設計に組み込むことを求めています。
なぜ今、セキュア・バイ・デザインが求められるのでしょうか。
従来の開発手法では、セキュリティ上の問題が起こった際に、後から対応してきましたが、それによる不都合が多く発生していました。例えば、テスト段階でセキュリティ上の欠陥が見つかった場合には、修正するための手戻りコストが生じます。また、機能を後付けする場合、コストの高い手段しか取れない、元の機能とうまく馴染まないといった問題が生じるケースもあります。
そのような事態を避けるためにも、開発の早期段階からセキュリティを考慮するセキュア・バイ・デザインが必要となります。
セキュア・バイ・デザインを取り巻く国内外の動き
セキュア・バイ・デザインの必要性が高まっていることから、近年様々な動きがあります。
日本
日本では、デジタル庁より2022年に「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」が発行されました。このガイドラインでは、セキュリティ・バイ・デザインを、企画工程から設計工程、開発工程、運用工程まで含めた全てのシステム開発ライフサイクルにおいて、一貫したセキュリティを確保する方策として定義しており、各工程で要求される事項や実施内容、重要なセキュリティ対策の考え方がまとめられています。主なターゲットは、政府情報システムの開発や運用に従事する関係者ですが、そのような方々だけでなく、システム開発の初期段階から係るメンバは目を通しておくことをお勧めします。
海外
海外でのセキュア・バイ・デザインの動きとして大きなものは、CISAによる取り組みが挙げられます。
2023年4月にセキュア・バイ・デザインについてのガイダンスが公開されて以降、ガイダンスへの各国関係機関の賛同が集まり、2024年5月から始まったセキュア・バイ・デザイン誓約に大手メーカーが参加するなど、かなり活発な動きが見られます。
ガイダンスは、セキュア・バイ・デザインおよびセキュア・バイ・デフォルトをソフトウェアが達成するために、その指針となる3つの基本原則と実際に取りうる手法について言及しています。2023年10月に改定され、その際にこれらの3つの基本原則についての説明が大幅に拡大されました。なお、このタイミングで、ガイドラインに賛同する各国機関も増えており、日本からもNISCとJPCERT/CCが賛同しています。
図1：ソフトウェア製品のセキュリティ3原則
もう一つの取り組みであるセキュア・バイ・デザイン誓約は、オンプレミスソフトウェア、クラウドサービス、SaaSなど、エンタープライズソフトウェア製品とサービスを提供するメーカーへの自発的な誓約として設定されました。この誓約に参加すると、メーカーは1年の間に、設定された7つの目標に対して、どのように達成したか、また、達成できない場合は進捗状況を公表することになっています。
本取り組みへの参加メーカーは、2024年5月の段階でAWS、Microsoft、Google、Cisco、IBMなど68社の大手企業が参加し、2024年11月末現在では250社を超えており、取り組みが広がっていることがわかります。まだ取り組みが始まってから1年未満ですが、すでに現在の達成状況をアピールしているメーカーも見られます。
図2：セキュア・バイ・デフォルト誓約の7つの目標
- 1．多要素認証（MFA）
パスワードベースの攻撃に対する防御として、多要素認証の使用を進めます。これは、システムへの導入だけでなく、実際に登録され使われることも含めます。そのために、デフォルトMFA有効などいくつかのアプローチが示されています。 - 2．デフォルトパスワード
製品全体で共通するデフォルトパスワードの削減が目標です。アプローチとして、製品のインスタンスごとに、ランダムな初期パスワードの利用やインストール時の強力なパスワード生成等による置き換えが示されています。 - 3．脆弱性クラス全体の削減
製品から、脆弱性のクラス（種類）一つ以上を選択して大幅に削減することが求められています。例としては、SQLインジェクション、XSS、メモリ安全性などが挙げられており、これらはセキュアコーディングや、フレームワークの利用、メモリセーフな言語の使用といったアプローチが示されています。 - 4．セキュリティパッチ
ソフトウェアにおいて、ユーザによるセキュリティパッチのインストールを増やすために、パッチサポートの提供や、パッチの自動的適用等のアプローチが示されています。また、パッチがサポートできなくなった場合のアプローチ等も言及されています。 - 5．脆弱性開示ポリシー
脆弱性開示ポリシーの公表を求めています。このポリシーは、製品に対する一般ユーザによる（セキュリティ）テストを許可、ポリシーに従うユーザには法的措置を取らないこと、また脆弱性の報告チャネルの提供、脆弱性のベストプラクティスと国際標準に沿った脆弱性一般公開を可能にするものとされています。 - 6．CVE（Common Vulnerabilities and Exposures）：共通脆弱性識別子
脆弱性の報告の透明性を示すために、CVEに、CWE（脆弱性の分類）とCPE（影響対象）を含めることが求められています。また、重大または影響度の大きい脆弱性で、お客様によるパッチ適用が必要か、活発な悪用の証拠がある脆弱性については、速やかにCVEを発行することも要求されています。 - 7．侵入の証拠
セキュリティインシデントの検出などのため、顧客の監査ログなど、侵入の証拠を収集する機能を提供することが求められています。
この7つの目標について、それぞれ解説します。
今後の日本企業への影響予測
システム開発の現場でセキュア・バイ・デザインの考え方を取り入れる場合には、デジタル庁のガイドラインを参照されるケースは多くなるでしょう。
また、セキュア・バイ・デザインの導入自体が要求されるケースも増えてくると想定されます。現在CISAの取り組みは米国企業が中心ですが、日本企業の参加も見られます。セキュア・バイ・デザイン誓約の参加企業が急速に増えている状況もあり、ソフトウェアやサービス提供会社においては、製品比較の軸として使われる可能性があります。いずれにせよ、システム開発において必要な考え方ですので、その達成のための手段を取り入れることをお勧めいたします。
サイバーセキュリティ | NTTデータ - NTT DATAについてはこちら：
https://www.nttdata.com/jp/ja/services/security/
あわせて読みたい：