金融分野でも求められる「セキュリティ・バイ・デザイン」｜脆弱性を減らす開発の進め方とは？

サイバーセキュリティの重要性が日々高まる中、リリース前の脆弱性診断を中心とした従来のアプリケーション開発におけるセキュリティ対策では、数多く存在する脆弱性に対応しきれないことがあります。また、脆弱性診断で脆弱性を検出した場合には、修正のための手戻りが発生し、開発コストが増大する恐れがあります。

このような状況の中、「セキュリティ・バイ・デザイン」という考え方が重要視されています。

また、2024年10月4日、金融庁が公表した「金融分野におけるサイバーセキュリティに関するガイドライン^[i]（以下、金融庁ガイドライン）」においても、セキュリティ・バイ・デザインの対応が要件の一つとして盛り込まれています。

※詳細は、以下のブログをご参照ください。

【解説】金融分野におけるサイバーセキュリティに関するガイドライン｜金融機関における対策検討のポイント

本記事では、セキュリティ・バイ・デザインの重要性を解説し、金融庁ガイドラインで求められるセキュリティ・バイ・デザインの要件に対応するために必要な事項の紹介や対応方針の考察を行います。

セキュリティ・バイ・デザインとは？

セキュリティ・バイ・デザインとは、リリース前の脆弱性診断のように、システム開発の後工程でセキュリティ対策を追加するのではなく、企画や設計の初期段階からセキュリティを考慮し、対策を組み込むアプローチを指します。

実は、この概念自体は2000年前後にはすでに提唱されており、決して新しいものではありません。また、国内では2011年頃に、内閣サイバーセキュリティセンター（NISC）より提唱^[ii]されております。

さらに、2022年にデジタル庁からも「政府情報システムにおける セキュリティ・バイ・デザインガイドライン^[iii](以下、デジタル庁ガイドライン）」が公開され、近年その重要性は高まる一方です。

なお、デジタル庁ガイドライン内では、セキュリティ・バイ・デザインは以下のように定義されており、セキュリティ・バイ・デザインという用語は単に企画や設計の初期段階だけではなく、システム開発のライフサイクル全体でセキュリティを考慮することを指している場合もあります。

一般的に、開発から運用まで含めたシステム開発ライフサイクル全体でセキュリティ確保する方策を（とりわけソフトウェア開発においては）DevSecOpsと呼ぶが、本書では政府情報システムの企画工程から設計工程、開発工程、運用工程まで含めた全てのシステム開発ライフサイクルにおいて、一貫したセキュリティを確保する方策のことを「セキュリティ・バイ・デザイン」と定義する。

後述する金融庁ガイドラインにおいても、企画・設計段階だけではなく、開発・運用工程における事項もセキュリティ・バイ・デザインの要件として挙げられております。そのため本記事では、システム開発のライフサイクル全体でセキュリティを考慮することをセキュリティ・バイ・デザインと定義します。

セキュリティ・バイ・デザインのメリット

セキュリティ・バイ・デザインを推進していくと得られるメリットとして大きく「コスト削減」と「安全性の向上」が考えられます。

１．コスト削減

従来、リリース前の脆弱性診断を軸としてセキュリティ対策を行うことが主流でしたが、診断で発見される脆弱性の多くは、設計段階で検出可能なものであることがわかっています。

また、システムのリリース直前や運用中に見つかった脆弱性を修正するには、システム全体を再設計することが必要な場合もあり、これには相当なコストが発生します。

開発の初期段階でそもそも脆弱性を作りこまないことで、大幅なコスト削減効果が望めます。

参考までに、具体的に削減できるコストとして、NRIセキュアブログに記載の以下を引用いたします。

「シフトレフト」の始め方｜設計工程で作りこまれる脆弱性にどう対処するか？

実際に、NRIセキュアで実施したセキュリティ診断の傾向を分析すると、約3割のWebアプリケーションで重要情報の窃取に繋がる危険な脆弱性が発見されています。診断で発見された脆弱性の半数以上は要件定義・設計フェーズで作りこまれています。脆弱性を修正する場合、設計時での修正コストを1とすると運用時での修正コストは約100倍に上ります。

セキュリティ診断の統計情報から得られる気づき

２．安全性の向上

脆弱性診断で見つかる脆弱性の中には、予算やリリースまでの時間が限られているために対応が難しいものも少なくありません。

実際に脆弱性診断を行っていても、多くのお客様は、緊急度の高い高リスクの脆弱性は修正しますが、予算やリリースまでの時間の制約上、低リスクの脆弱性は修正しないケースが多いです。

また、比較的リスクの高い脆弱性であっても、リスク受容するケースも存在します。

こうした状況を防ぐため、セキュリティ・バイ・デザインを採用することで、脆弱性診断を行う段階では既に、企画・設計段階で検出可能な脆弱性が存在しない状態にすることが可能です。

これにより、従来見過ごされていた低リスクの脆弱性やリスク受容していた比較的リスクの高い脆弱性にまで対策が施され、セキュリティ品質が向上します。

セキュリティ・バイ・デザイン推進による安全性の向上イメージ

金融分野におけるサイバーセキュリティに関するガイドライン上の要件

金融庁ガイドラインでは、第2節「サイバーセキュリティ管理態勢」内の、システムのセキュリティ対策の中で、セキュリティ・バイ・デザインが要件として挙げられています。

本要件では、企画・設計段階だけではなく、開発・運用工程における事項も挙げられています。そのため、本ガイドの要件に準拠するためには、システム開発のライフサイクル全体でセキュリティ対策を考慮していく必要であると考えられます。

なお、「基本的な対応事項」は、「サイバーハイジーン（IT資産の適切な管理、セキュリティパッチ適用などの基本的な行動を組織全体に浸透させる取組み）と呼ばれる事項や、その他金融機関等が一般的に実施する必要のある基礎的な事項」と定められています。

また、「対応が望ましい事項」は、「金融機関等の規模・特性等を踏まえると、インシデント発生時に、地域社会・経済等に大きな影響を及ぼしうる先において実践することが望ましいと考えられる取組みや、他国の当局又は金融機関等との対話等によって把握した先進的な取組み等の大手金融機関及び主要な清算・振替機関等が参照すべき優良事例」と定められております。

さらに、金融機関ごとに規模や特性は異なるため、一律対応を行うのではなく、セキュリティリスクを把握したうえで、リスクに見合った低減措置を行うことが求められております。

セキュリティ・バイ・デザインの進め方

金融庁ガイドライン上でセキュリティ・バイ・デザインの実施が求められてはいるものの、実際にどのようなことを行っていけばよいかわからないケースが多いのではないでしょうか？

ここでは、金融庁ガイドラインと同様に、国内の政府機関が発行したデジタル庁ガイドラインを参照し、金融庁ガイドラインの各要件に対する具体的な対応策を考察していきます。

なお、前述の通り、デジタル庁ガイドラインもセキュリティ・バイ・デザインをシステム開発のライフサイクル全体でセキュリティを考慮するものとしているため、この点において両者には共通点があります。

基本的な対応事項

改めて、金融庁ガイドラインにおける基本的な対応事項は以下の通りです。

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

 

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

ここで、デジタル庁ガイドラインを参考に改めて整理すると、開発の各工程において実施すべきセキュリティ対策は以下の通りとなります。

各開発工程で実施すべきセキュリティ対策

特に、赤枠で囲った企画・設計段階で実施すべきセキュリティ対策について、それぞれ説明します。

１．サービス・業務企画

セキュリティリスク分析

サービス開発の初期である企画段階では、開発対象システムのセキュリティリスク分析を行うことが求められます。セキュリティリスク分析は以下の4ステップで行います。

ステップ1：システムプロファイルの作成

リスクを洗い出すためには、対象のシステムの詳細を整理しておく必要があります。具体的には、システムで取扱う重要情報の種類、重要情報の処理フローやライフサイクルが分かる内容、ステークホルダー、実施業務、他システムとの連携方法等をシステムプロファイルとして作成します。

ステップ2：脅威分析

作成したシステムプロファイルを元に、Microsoft STRIDEモデル^[iv]やMITRE ATT＆CK^[v]等の脅威モデルを用いて、対象システムで発生が想定されるセキュリティ脅威を特定します。その際、システム面でのセキュリティ脅威だけでなく、サービス仕様上の脅威や人的ミスによるセキュリティ脅威も含めて検討を行います。

ステップ3：リスク評価

洗い出したセキュリティ脅威に基づき、具体的にどのようなリスクが存在するのかを評価します。その際、セキュリティ脅威の発生可能性はどの程度なのか？実際に脅威が発生した際にシステムやビジネスにどの程度影響を与えるのか？といった観点で整理を行います。

ステップ4：対応方針の検討

リスク評価の結果、対策の優先度や遵守すべきセキュリティ標準を決定し、セキュリティ対応方針を検討します。全てのリスクに対処することは難しいため、ここで定めた優先度は、どこまで対策を行うのか判断するために非常に重要な役割を果たします。

２．要件定義

セキュリティ要件定義

サービス・業務企画段階で洗い出したセキュリティリスクや策定したセキュリティ対応方針をもとに、機能要件や非機能要件を定めていきます。その際、可能な限り多層防御の実施を前提としていくことが望ましいです。

３．調達

セキュア調達

外部ベンダに開発を委託する際には、セキュリティ対策を適切に行っている安全な委託先を選ぶことが非常に重要です。不適切な委託先を選んでしまうと、委託先が原因でセキュリティインシデントが発生するリスクがあります。

そのため、委託先に遵守してもらうべきセキュリティ対策を事前に定義し、これらの対策が確実に実施されていることを確認することが必要です。

また、委託先からの提案内容が自社のセキュリティ要件を満たしているかどうかも、しっかりと確認する必要があります。さらに、自社と委託先のセキュリティ対策に関する責任範囲を明確にし、調達仕様書などにセキュリティ関連事項を明確に記載することが求められます。

なお、金融庁ガイドラインの基本的な対応事項②に対応するためには、委託先がセキュリティ・バイ・デザインを実践できる体制を整えているかどうかを確認する必要があります。

しかし「セキュリティ・バイ・デザイン」とは具体的に何を指し、どのような基準を委託先に求めるべきかについては、明確な記載が存在しません。そのため、自社で実施しているセキュリティ・バイ・デザインに基づく対策と同等以上の取り組みを求めることが、最低限の対策として考えられます。

また、サードパーティ製のプロダクト（システムで利用する機器、ミドルウェア、ライブラリなど）を利用する際には、バックドア（限られた人物のみが対象システムを操作できるシステム仕様に記載されない隠された機能）が含まれておらず、サービス提供期間中にサポートが受けられる安全なプロダクトを選定することが重要です。

その際、利用するプロダクトに適切なセキュリティ対策が施されているかどうかを開発元に詳細に確認することで、プロダクトの信頼性を高めることができます。

４．設計・開発

セキュリティ設計

一般に公開されているものや、自社で作成したセキュリティガイドライン・フレームワークを参考にしながら、要件定義で策定したセキュリティ要件をシステム設計に反映させます。特に、ユーザ認証やアクセス制御などの複雑な部分では、外部のセキュリティ専門家にレビューを依頼し、協力しながら進めることで、より安全性を高めることが可能です。

ここまで紹介した対策をすべてのシステムに対して実施することはコストや時間の制約上難しい場合が多いです。そのため、企業やプロダクトの性質、扱う情報の重要度に応じて、優先順位をつけて実施していくことが求められます。

例えば、ユーザの病歴、犯罪歴といった要配慮個人情報やクレジットカード情報などの重要な情報を扱う場合、実施可能なセキュリティ観点でのチェック機構を開発プロセスの初期段階から優先的に組み込むことが望ましいです。

一方で、重要な情報を扱わない社内システムについては、定期的な脆弱性診断やDASTツールによるスキャンのみにとどめる、といった選択肢も可能です。

対応が望ましい事項

ここでは、引き続き金融庁ガイドラインにおける対応が望ましい事項について考察していきます。

セキュアコーディングに係る基準を策定し、実施すること。

一般に公開されているガイドラインを基に、社内におけるセキュアコーディング基準の策定を行います。開発者は、この基準に従ってコーディングを行うことで、セキュリティ基準を統一して守ることが可能となります。

また、コードレビュー時には、セキュアコーディング基準に基づいて作成されたチェックリストやチェックツールを活用して、セキュリティの実装状況を確認します。

データの機密性、アクセス管理、イベントログ取得等のセキュリティ要求事項を明確化していること。

基本的な対応事項において紹介したセキュリティ設計において、特に以下事項などを、明確に要件や設計として記載します。

• データの機密性：扱うデータを分類し、それぞれに適した暗号化方針や管理方式を明示する。
• アクセス管理：最小権限の原則に基づいて、適切な権限制御および認可制御を行う。また、認証方式にはユースケースに応じた強度の高い手法を採用する。
• イベントログの取得：アクセスや操作履歴を記録するイベントログの取得を行い、これらのログを定期的にレビューするようにする。これにより、インシデントの早期発見と迅速な対応が可能となる体制を整備する。

セキュリティ技術・アーキテクチャーに係る設計標準を策定すること。

セキュリティ技術・アーキテクチャーに係る設計標準として、開発するプロダクトが利用する技術に合わせたセキュリティガイドラインの整備や、安全性が担保された設計パターンを定めていくことが求められます。また、技術の進展に合わせ、ガイドラインや設計パターンは、定期的に更新する必要があります。

アプリケーションソフトウェアのリリース前及びリリース後定期的に、アプリケーションの脆弱性診断を実施すること。

開発するプロダクトのアプリ種別に合わせ、脆弱性診断を行います。リリースのたびに脆弱性診断を行うことは現実的ではないため、サービス・業務企画段階で行ったリスク評価の結果をもとに脆弱性診断の要否を決定していくことが求められます。

また、自動脆弱性診断ツール(SAST・DAST・IAST等)の導入や、セキュリティを考慮した設計を行うことで、複雑なロジックを組んだシステムやリスクの高いシステム以外については脆弱性診断の頻度を減らす判断を行うことも有効です。

システムへの脆弱性の混入及び作込みを未然に防止し、早期に検知するツール（ソースコード解析ツール等）を活用すること。

ソースコードの静的解析ツールであるSASTをはじめとした、各種セキュリティツールを開発プロセスの中に組み込みこみます。これにより、事前に脆弱性を検知することが可能となります。

ただし、ツールによる検知プロセスを開発のパイプラインに導入しすぎると、スキャンに時間がかかってしまい、アジリティが低下してしまうことが懸念されます。また、SASTツールのスキャン結果には誤検知が非常に多く、トリアージ（SASTが出した指摘が実際に問題となるかどうかの判断）にある程度時間がかかってしまいます。

そのため、こまめにスキャンを行うことで都度トリアージを行う、危険度がCRITICALなものだけ対応する、等の環境に合わせた適切なプロセス整備が求められます。

さいごに

本記事では、金融庁ガイドラインにおいて求められるセキュリティ・バイ・デザインの要件に対応するために必要な事項の紹介や対応方針の考察を行いました。

セキュリティ・バイ・デザインには特に決まった型はなく、企業によって対応策は大きく異なります。また、特に金融庁ガイドラインの「対応が望ましい項目」については、開発プロセスの企画や設計の初期段階だけでなく、下流工程以降でのセキュリティ対策も求められています。

そのため、システム開発のライフサイクル全体でセキュリティを考慮する必要があります。

筆者も多くのセキュリティ支援を行う中で、アプローチは様々ですが、セキュリティ・バイ・デザインへの意識が高まっている企業が増えていることを実感しています。

例えば、開発プロセスに自動脆弱性診断ツールを導入したり、新規プロダクトの企画・設計段階で有識者によるセキュリティレビューを必須にしたり、ガイドラインを迅速に活用できる環境を整備したりするケースなどが見られます。

こうした取り組みを行っている企業では、徐々に脆弱性診断での指摘数が少なくなっている傾向が見られます。

また、開発プロセスにセキュリティ観点でのチェック機構を何かしら取り入れることで、開発者にとってセキュリティがより身近な存在となり、セキュリティへの意識が自然と向上すると考えられます。

例えば、開発プロセス内で、自動脆弱性診断ツールの1つであるSASTによるスキャンを必須とする場合を考えてみます。前述の通り、SASTはソースコードを静的に解析するツールで、比較的容易に実行できる一方、誤検知が多いという特徴があります。そのため、誤検知のトリアージが必要です。

このトリアージを行う際にはまず、セキュリティに精通した人(セキュリティ専門家等)と開発者が協力して進めることになります。その際、開発者自身がトリアージ作業を行うことで、どういった指摘が出るのか、また指摘を回避するにはどのようにコードを書くべきかを理解することができます。

これにより、次回以降のコーディング時により注意を払うようになると考えられます。

開発プロセスにSASTを導入した際のイメージ図

こういった取り組みにより、チーム全体のセキュリティ文化が徐々に醸成されることが期待できます。まずは小さな取り組みからでも構いませんので、ぜひセキュリティ・バイ・デザインを実施してみてください。

弊社では、ガイドライン作成や各種ツールの導入をはじめ、ここまで紹介した全ての要件に対して、DevSecOps実行支援サービスやSEC Team Servicesとしてご支援が可能です。

お客様の開発メンバの一員として(オンライン)常駐することもできます。

ご支援時には、お客様と密に連携し、組織体制や文化、開発工程、開発環境などの状況に応じて、最適な解決策を提供することを強みとしております。セキュリティ・バイ・デザインを推進したいが何から始めてよいかわからない、といった方をはじめ、どなたでもお気軽にご相談ください。

[i] https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf

[ii] https://www.nisc.go.jp/pdf/policy/general/SBD_overview.pdf

[iii] https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/7e3e30b9/20240131_resources_standard_guidelines_guidelines_01.pdf

[iv] https://learn.microsoft.com/ja-jp/azure/security/develop/threat-modeling-tool-threats

[v] https://attack.mitre.org/