金融庁ガイドラインを読み解く：セキュリティ・バイ・デザインの真意

前回、前々回と金融庁の「金融分野におけるサイバーセキュリティに関するガイドライン（以下、本ガイドライン）」に関する記事が続いていますが、今回は、セキュリティ・バイ・デザインについて取り上げます。なお、本記事の内容は、あくまでも私個人の意見であることをご理解いただき、その上で参考になる部分があればご活用いただければ幸いです。

1.金融庁ガイドラインにおけるセキュリティ・バイ・デザイン

セキュリティ・バイ・デザインについて、本ガイドラインでは以下の通り記述されています。

2.1.1. 基本方針、規程類の策定等
5 【基本的な対応事項】
経営陣は、金融商品・サービスを導入する場合や、デジタルトランスフォーメーションを推進する場合には、セキュリティ・バイ・デザインを含むサイバーセキュリティ確保に向けた取組みも同時に推進すること。

2.3.4.1. ハードウェア・ソフトウェア管理
【対応が望ましい事項】
a システムで利用するサードパーティのライブラリやミドルウェア、ハードウェアについては、不正侵入の経路となるバックドア等が含まれることのないように、セキュリティ・バイ・デザインやセキュリティ・バイ・デフォルト等の安全な開発手法を製品開発に取り入れている事業者から提供される安全なプロダクトを選定すること。

2.3.4.3. セキュリティ・バイ・デザイン
【基本的な対応事項】
1 金融商品・サービスの企画・設計段階から、セキュリティ要件を組み込む「セキュリティ・バイ・デザイン」を実践すること。サービス全体の流れの中で、重要なサードパーティも含めてリスクを検証し対策を講ずること。

2 自組織にシステムを提供する重要なサードパーティにおいて、セキュリティ・バイ・デザインを実施できる体制となっているかを確認すること。

【対応が望ましい事項】
a セキュリティ・バイ・デザインにかかる管理プロセスを、 以下の点も考慮のうえ、整備し、運用すること。
・セキュアコーディングに係る基準を策定し、実施すること。
・データの機密性、アクセス管理、イベントログ取得等のセキュリティ要求事項を明確化していること。
・セキュリティ技術・アーキテクチャーに係る設計標準を策定すること。
・アプリケーションソフトウェアのリリース前及びリリース後定期的に、アプリケーションの脆弱性診断を実施すること。
・システムへの脆弱性の混入及び作込みを未然に防止し、早期に検知するツール（ソースコード解析ツール等）を活用すること。

セキュリティ・バイ・デザインというキーワードが半ば唐突に出てきたので、戸惑っている方がいるかもしれません。また、セキュリティ・バイ・デザインというと、セキュアコーディング等の開発過程における技術的な対策という印象を持たれている方もいるかもしれません。
しかしながら、セキュリティ・バイ・デザインは企画工程を含めた全ライフサイクルにおいてセキュリティを確保する考え方であり、開発過程における技術的な対策だけではありません。むしろ上流においてリスクを分析したりセキュリティ要件を確保したりすることも重要です。

＜セキュリティ・バイ・デザインの実施プロセス＞
1 商品・サービスやシステムの企画・設計段階における「セキュリティリスク分析」
2 システムとして満たすべきセキュリティ要件を定義
3 開発や運用におけるセキュリティの確保


出典：デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」

そして、当ガイドラインにおいて優先度が高く記載されているのは、企画・設計段階における「セキュリティリスク分析」であり、開発や運用におけるセキュリティの確保については、【対応が望ましい事項】となっています。
ここまで読み解くと、2.1.1.⑤に【基本的な対応事項】として『経営陣は、金融商品・サービスを導入する場合や、デジタルトランスフォーメーションを推進する場合には、セキュリティ・バイ・デザインを含むサイバーセキュリティ確保に向けた取組みも同時に推進すること。』と記載されていることの意味や金融庁の問題意識が伺えるのではないでしょうか。

2.セキュリティリスク分析

商品・サービスやシステムの企画・設計段階における「セキュリティリスク分析」とは、要はこれから始めようとしていることについて、セキュリティ脅威を挙げだしてリスクを分析することですが、本ガイドラインにも参考資料として挙げているデジタル庁の「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン（以下、SbDガイドライン）」には、セキュリティリスク分析の実施内容について、以下の通り記載されており、参考になる内容です。

●システムで取扱う重要情報、ステークホルダー、実施業務、他システムとの連携方法等、システムで取扱う重要情報のフローやライフサイクルが分かる内容を記載したシステムプロファイルの作成

●システムプロファイルに基づくセキュリティ脅威の特定

●セキュリティ脅威の発生可能性、システムへの影響度を踏まえたリスク分析の実施

●リスク分析結果を踏まえたセキュリティ対応方針の決定（リスク対応優先度、遵守すべきセキュリティ標準、検証方法、対応リソース等）

ちなみに、リスク分析の手法については、前回記事「金融庁ガイドラインを読み解く：サイバーセキュリティリスクの分析手法について」が参考になると思います。
そもそも、新しい商品やサービスを始める際には、セキュリティだけでなく様々なリスクを挙げだし分析する必要があります。ですので、既に、リスク管理部門等が主催で「新商品・新サービスリスク評価会」のような取組みを実施されている金融機関もあると思います。そのような金融機関においては既存の取組みにセキュリティの観点を加えることで対応することも考えられますし、既に実施している金融機関もあるのではないでしょうか。

3.サードパーティにおけるセキュリティ・バイ・デザインガイドライン

本ガイドラインの2.3.4.3.②に 『自組織にシステムを提供する重要なサードパーティにおいて、セキュリティ・バイ・デザインを実施できる体制となっているかを確認すること。』と記載があります。これは結構、解釈に困る内容ですが、本ガイドラインのパブコメに対する金融庁の考え方として『例えば、システムのセキュリティ要件に基づく仕様を策定した上で、当該仕様を満たす能力を有した委託先を選定することが考えられます。』と記載があり、これがヒントになるように思います。SbDガイドラインにも「セキュア調達」というプロセスがあり、実施内容として以下の項目が記載されています。

●セキュリティ要件に基づいて、調達仕様におけるセキュリティ仕様策定

●セキュリティ仕様に関する、委託先との責任範囲の明確化

●委託先に求めるセキュリティ管理基準の策定

●セキュリティ仕様を満たす能力を有した安全な委託先の選定

●不正侵入の経路となるバックドア等が含まれていない、継続的なサポートを受けられる安全なプロダクトの選定

ですので、ここにおいても、セキュリティ・バイ・デザインにおける実施プロセスの上流である「セキュリティリスク分析」と「セキュリティ要件定義」がポイントになってくると思われます。

4.最後に

セキュリティ・バイ・デザインというと技術的な取組みだと思いがちですが、本ガイドラインが優先度の高い項目として挙げているのは、上流におけるリスク分析やセキュリティ要件の定義です。セキュリティ・バイ・デザインという言葉に過度に反応せず、全ライフサイクルを通して自社の課題や改善点を挙げだし、取り組んでいけばいいのではないでしょうか。

＜参考URL＞
政府情報システムにおけるセキュリティ・バイ・デザインガイドライン（デジタル庁）
https://www.digital.go.jp/resources/standard_guidelines