金融サービスのコンプライアンスはソフトウェアのセキュリティにかかっている

金融機関が使用するソフトウェアコードの安全性を確保すべき理由は明白です。最大の動機は、データ侵害から情報を保護することです。侵害が発生すれば、個人情報の漏洩、復旧費用、罰金や賠償金、そして組織の評判失墜など、多大なコストを招く恐れがあります。また、業界や政府の多様な規制を遵守し続けることも、継続的な課題となっています。

金融サービス業界は、機密性の高い個人情報や金融情報、そして顧客の資産を扱うため、非常に厳格な規制下にあります。提供するサービスに応じて、企業はさまざまなルールや要件を遵守しなければなりません。

例えば、カード会員データを保護するためのルールとして「PCI DSS（PCIデータセキュリティ基準）」が広く知られています。サーベンス・オクスリー法（SOX法）の要件は、財務記録の管理を規定しています。国際的に事業を展開する企業であれば、拘束力のあるリスク管理フレームワークであるデジタルオペレーショナルレジリエンス法（DORA）や、国際銀行間通信協会（Swift）が定める資金送金のグローバル基準にも精通しているはずです。

さらに、カリフォルニア州消費者プライバシー法（CCPA）やEUの一般データ保護規則（GDPR）といった法律が、顧客のプライバシーと個人情報を保護するための要件を定めています。他にも、米国通貨監督庁（OCC）や欧州中央銀行（ECB）が定める規制などが存在します。

それだけではありません。国家サイバーセキュリティ戦略では、ソフトウェアメーカーは不十分なソフトウェアセキュリティに対して責任を負うべきであると明記されています。また、米国のサイバーセキュリティ・インフラセキュリティ庁（CISA）は、17の米国および国際的なパートナーと共同で、ソフトウェア開発におけるセキュア・バイ・デザインの原則に関するガイダンスを発行しています。

金融サービス企業にとって共通の課題は、セキュアなコードが規制目標の達成を支援する重要な要素であり、コンプライアンスの証明を容易にするという点です。だからこそ、開発プロセスの初期段階からセキュリティをコードに組み込めるよう、開発者へのトレーニングとスキルアップが不可欠なのです。

その仕組みの例として、最新版のPCI DSSを見てみましょう。

セキュアコーディング（および開発者トレーニング）はPCI DSS 4.0の中核です

2024年4月1日から義務化されたには、PCI DSS 3.2.1からの大幅な更新がいくつか含まれています。その中でも特に重要なのが、セキュアなソフトウェアコードを確保する上での開発者の役割に対する強調です。

PCIは以前からセキュアなソフトウェアの重要性を認識してきました。2017年にリリースされたバージョン2.0には、モバイルデバイスでの安全な取引を確保するための開発者向けガイダンスが含まれていました。バージョン4.0のガイダンスでは、ソフトウェア開発へのセキュリティベストプラクティスの適用が強調され、開発者トレーニングに関する具体的な指針も盛り込まれています。

要件は概括的に述べられていることが多いですが、企業はより徹底したアプローチを実装することが望ましいでしょう。

例えば、バージョン4.0の要件の一つに「セキュアなシステムおよびソフトウェアを開発・維持するためのプロセスとメカニズムが定義され、理解されていること」とあります。これを確実に実行する良い方法は、開発者が使用するプログラミング言語やフレームワークに特化したトレーニングを受け、知識のギャップを埋めることです。

別の要件では、特注ソフトウェアやカスタムソフトウェアの開発に携わる開発者は、少なくとも12ヶ月に1回、以下の内容を含むトレーニングを受ける必要があると定めています。

• 職務および開発言語に関連するソフトウェアセキュリティ。
• セキュアなソフトウェア設計とコーディング技術。
• ソフトウェアの脆弱性を検出するためのセキュリティテストツールの使用方法（使用している場合）。

しかし現実には、年に一度のトレーニングでは、根本的なセキュリティ課題に対処したり、悪いコーディング習慣を改善したりするには不十分です。トレーニングは継続的かつ測定可能であるべきであり、学んだことが確実に活用されているかを確認するスキル検証プロセスが必要です。

PCI DSS 4.0には、さまざまな種類の攻撃の防止と緩和、サードパーティ製ソフトウェアコンポーネントの文書化、脆弱性の特定と管理、その他のセキュリティ対策など、他にも多くの要件が含まれています。いずれの場合も、組織はこれらの対策を徹底的に追求するのが賢明です。攻撃ベクトルに関するトレーニングは年1回ではなく、頻繁に行うべきです。脆弱性の温床となりやすいサードパーティ製コンポーネントは、ソフトウェア部品表（SBOM）プログラムを通じて慎重に棚卸しする必要があります。また、組織は脆弱性管理の役割を明確に定義しておくべきです。

新バージョンでは、認証制御、パスワードの長さ、共有アカウントなどに関する新たな要件が追加される一方で、チェックリストを埋めることよりも成果を重視する柔軟な対応が組織に認められています。

コンプライアンスはSDLC（ソフトウェア開発ライフサイクル）の最初から始まります

これらの規制に共通しているのは、金融サービス業界におけるデータと取引の保護に対して高い基準を設けようとしている点です。また、最新のPCI DSSバージョンに見られるように、ソフトウェア開発ライフサイクル（SDLC）の初期段階におけるセキュアなコードの重要性がますます強調されています。国家サイバーセキュリティ戦略やCISAの「Secure by Design（設計によるセキュリティ）」原則も、ソフトウェアの出荷前にメーカー側がセキュリティの責任を負うべきだと定めており、金融規制の直接的な対象外である企業であっても、対応が求められるようになっています。

組織は、開発スピードを重視するDevOpsチームと、セキュリティの組み込みを急ぐAppSecチームの間に存在するギャップを埋める必要があります。そのためには、開発者がセキュリティを自らのアプローチに不可欠なものとして捉えられるよう育成しなければなりません。しかし、それには年1回の研修や、形式的で停滞した教育プログラムでは不十分な、高度で複雑なスキルが求められます。トレーニングは継続的かつアジャイルであるべきであり、実際の現場で起こりうるシナリオを用いて学習者の意欲を引き出し、業務の合間に取り組めるよう短時間で提供される必要があります。

金融サービス企業は、侵害を防ぐだけでなく、ますます厳格化する規制を遵守するためにもセキュリティを確保しなければなりません。コンプライアンス違反がもたらす損害は、企業の評判や金銭的コストの面で、データ侵害と同等に壊滅的な影響を及ぼす可能性があります。例えば、IBMの「2023年データ侵害のコスト調査」によると、コンプライアンス違反のレベルが高い組織は、平均で505万ドルの罰金やその他のコストを負担しており、これは実際のデータ侵害による平均コストを50万ドル上回る金額です。

クラウド環境とデジタル取引の継続的な拡大により、金融サービス業界におけるソフトウェアのセキュリティは最優先事項となっており、PCI DSSなどの規制もそれを認識しています。セキュアなソフトウェアを確保する最善の方法は、SDLCの開始段階からセキュアコーディングを行うことです。そして、それを実現するには、開発者に対してセキュアコーディングの実践的なトレーニングを効果的に行う必要があります。

セキュアコーディングが金融サービス企業の成功、セキュリティ、そして利益確保にどのように貢献するかについての包括的な概要は、Secure Code Warriorが新たに公開した電子書籍『金融サービスにおけるセキュリティトレンドの究極ガイド』をご覧ください。

サイバーセキュリティやますます危険性を増す脅威の状況に関する詳細な洞察、そして革新的な技術やトレーニングを活用して組織と顧客をより強固に保護する方法については、Secure Code Warriorのブログページをご覧ください。

‍