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

金融機関には、使用するソフトウェア・コードの安全性を確保しなければならない強い理由がある。もちろん、漏洩した個人情報、後始末の費用、罰金や賠償金、組織の評判へのダメージなど、莫大な費用がかかる可能性のある情報漏洩からデータを保護する必要性は、明白な動機である。もう一つの継続的な理由は、業界や政府の様々な規制を遵守する必要性である。

金融サービス業は、多くの機密情報、個人情報、金融情報、そして人々の金銭を扱うため、規制の厳しい業界である。提供するサービスによって、企業はさまざまな規則や要件を遵守しなければならない。

例えば、PCI DSS（Payment Card Industry Data Security Standard）は、カード会員データの保護に関する規定としてよく知られている。サーベンス・オクスリー法（Sarbanes-Oxely Act）の要件は、財務記録管理を規定している。国際的に事業を展開する企業は、拘束力のあるリスク管理フレームワークであるデジタル・オペレーショナル・レジリエンス法（DORA）や、スイフトとして知られる国際銀行間金融通信協会が定めた資金移動の世界標準に精通している。

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

これだけでは不十分な場合、国家サイバーセキュリティ戦略では、ソフトウェア・メーカーは非効率なソフトウェア・セキュリティに責任を負うべきであると述べている。また、サイバーセキュリティ・インフラ・セキュリティ庁（CISA）は、米国内外の17のパートナーとともに、ソフトウェア開発のためのセキュア・バイ・デザインの原則に関するガイダンスを発表している。 

金融サービス企業に共通するのは、セキュアなコードは、規制の目標を達成するために不可欠な要素であり、規制への準拠を容易に示すのに役立つということである。そして、開発者が開発プロセスの初期段階でコードにセキュリティが適用されていることを確実にするためのトレーニングとスキルアップを必要としている理由が明確になった。

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

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

PCI DSS 4.0は2024年4月1日付で義務化され、PCI DSS 3.2.1に対していくつかの大幅な更新が含まれています。

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

要件は多くの場合、大まかに示されているが、企業はより徹底したアプローチを実施したいと考えるかもしれない。

たとえば、バージョン4.0の要求事項のひとつに、「安全なシステムおよびソフトウェアを開発し、維持するためのプロセスと仕組みが定義され、理解されている」とある。このことを確実にする良い方法は、開発者が知識のギャップを埋めるために、使用しているプログラミング言語やフレームワークの正確なトレーニングを受けることである。

もうひとつの要件は、オーダーメイドやカスタム・ソフトウェアに携わる開発者は、少なくとも12カ月に1回、以下の内容のトレーニングを受けなければならないというものだ：

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

しかし、現実には、中核的なセキュリティ問題に対処し、悪いコーディング習慣を断ち切るには、年に 1 回の頻度では十分ではない。トレーニングは継続的かつ測定的であるべきであり、それが有効に活用されていることを確認するためのスキル検証プロセスが必要である。

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

新バージョンはまた、認証管理、パスワードの長さ、共有アカウント、その他の要素に関する新たな要件を追加する一方で、チェックボックスにチェックを入れるのではなく、成果に焦点を当て、組織がその要件を満たすことにある程度の柔軟性を与えている。 

コンプライアンスは SDLC の最初から始まる

これらの規制の共通点は、金融サービス業界のデータとトランザクションを保護するための高い基準を設定しようとしていることです。また、PCI DSS の最新版の場合と同様に、ソフトウェア開発ライフサイクル（SDLC）の初期段階におけるセキュアコードの重要性がますます強調されています。また、国家サイバーセキュリティ戦略とCISAのSecure by Designの原則は、出荷前のソフトウェアの製造者にセキュリティの責任を課しているため、金融サービス規制が直接適用されない企業であっても準拠する必要があります。

組織は、開発者をトレーニングすることによって、開発スピードを重視するDevOpsチームと、セキュリティをプロセスに組み込むことを急ぐAppSecチームの間に存在するギャップを埋める必要がある。しかし、これには複雑な一連のスキルが必要であり、毎年のトレーニングセッションや標準的で停滞した教育プログラムでは対応できない。トレーニングは継続的かつ機動的であるべきであり、学習者が能動的かつ実世界のシナリオに関与できるように構築され、学習者の仕事のスケジュールに合わせて小分けにして提供されるべきである。

金融サービス企業は、情報漏えいから身を守り、ますます厳しくなる規制に準拠し続けるために、セキュリティを確保する必要がある。コンプライアンス違反のコストは、企業の評判や金銭的コストに与える影響という点で、情報漏えいと同程度の損害をもたらす可能性がある。例えば、IBM の「Cost of a Data Breach Report 2023」によると、コンプライアンス違反の度合いが高い組織では、罰金やその他のコストが平均で合計 505 万ドルに上り、実際のデータ漏えいの平均コストよりも 50 万ドル高いことが判明しています。

クラウドベースの環境とデジタルトランザクションの継続的な成長により、金融サービス業界におけるソフトウェアのセキュリティは最も重要なものとなっており、PCI DSS のような規制もそれを認めています。安全なソフトウェアを保証する最善の方法は、SDLC の開始時に安全なコーディングを行うことです。そして、その方法は、セキュアコーディングの実践において開発者を効果的にトレーニングすることです。 

セキュアコーディングが金融サービス企業の成功、セキュリティ、利益の確保にどのように役立つかの包括的な概要については、新たにリリースされた電子書籍（Secure Code Warrior ）をお読みください：金融サービスにおけるセキュリティトレンドの究極のガイド。

ブログ Secure Code Warriorサイバーセキュリティ、ますます危険になる脅威の状況、そして組織と顧客をよりよく守るために革新的なテクノロジーとトレーニングを採用する方法についての詳しい洞察については、ブログページをご覧ください。

‍