LayerX Fintech事業部*1で、セキュリティ、インフラ、情シス、ヘルプデスク、ガバナンス・コンプラエンジニアリングなど色々やってる @ken5scal です。

今日はFintech事業部らしく、金融庁が意見募集をしていた「金融分野におけるサイバーセキュリティに関するガイドライン」（案）*2について感想を記載します。具体的には、よかったな〜とおもうところ、きになったところ、最後にルールメイキングやっていこうぜ！という内容です。 ~~もちろん良い子のFintechのみんなは提出したよね？~~

本邦におけるサイバーセキュリティの確保について「サイバーセキュリティ基本法」を軸として各種施策が定められています。その中で当社Fintech事業部が取り組むような証券サービスは「重要社会基盤事業者（重要インフラ事業者）」に位置づけられています。これは証券サービスが「他に代替することが著しく困難なサービスを提供する事業が形成する国民生活及び社会経済活動の基盤*3」とされ、従って、その安定の確保という任務において金融庁は、健全かつ適切な運営がされているか監督しています。その監督時の指針として、各金融セクター向けの監督指針*4があります。

サイバーセキュリティ管理態勢についても監督指針内に含まれていたのですが、各種リスクに対してプラグイン的な記述にすぎませんでした。しかし、様々な国内外の情勢の変化を反映してか、この度、より詳細なガイドライン「金融分野におけるサイバーセキュリティに関するガイドライン（案）*5」が作成され、監督指針から参照されるような変更が提案されました。

本ブログでは、ガイドラインについての小学生並みの感想をつらつら書いたものです。

よかったところ

まず、プラグイン的な書き方から、体系的な文書になりました。

目次を見ると、NISTのサイバーセキュリティフレームワーク（さらにv2）をベースにしていそうです。２章の各節が、管理態勢（NIST CSFでいうところのGV）、特定、防御、検知、対応及び復旧とわかれています。GVのなかで、GV.SCに該当すると思われる「サードパーティリスク管理」は2.6にあります。このようにサイバーセキュリティが機能別で整理され、いままで監督指針の補足的、個別最適あった課題が改善されています。

そもそもこの体系的なガイドライン作成自体が大きな一歩といっていいでしょう。事業者の中の担当としても助かります。

気になったところ

脆弱性管理における経営陣（等）の責務が細かそう

「2.2.3 ハードウェア・ソフトウェア等のぜい弱性管理」について、「例外的にパッチ適用等の対応を実施しない場合には、実施しないことと実施しないことのリスクについて経営陣等から承認を得ること」　と記述されています。「経営陣等」および「パッチ適用等」の等がどこまで含むかにもよりますが、個別のぜい弱性対応について経営陣からの承認を得るように読めてしまいます。更に、パッチ適用等の対応にも経営陣から承認を得る場合、ワークアラウンド実施においてもまずは経営陣から承認を得なければ実施できないようにも見えます。経営者（等）が全体の態勢を率いねばならないのはその通りですが、一方、個別具体策にまで関わることを要求している様に感じました。

※また、事後承認も許容しているのかもですが....

せっかく2.1.1で「サイバーセキュリティ関連業務を統括管理する責任者（CISO）」を登場させているので、委譲先の責任者の責務とできるような書き方が、一担当者としては嬉しいですね。

あるいは、「パッチ適用等」ではなく「ぜい弱性対応等」にするとより、企業ごとの実態にあわせた対応が可能になりそうです。

クラウドサービス利用時の留意点が限定的である

「2.3 サイバー攻撃の防御」の「2.3.4.5 クラウドサービス利用時の対策」の立ち位置について気になりました。下の図がその内容ですが、「防御」より包括的な対応事項でしょう。いってしまえば「態勢」な内容です。あうりは、クラウドサービス利用によって金融サービスが成り立つのであれば、それはサプライチェーンリスクであり、「2.6. サードパーティリスク管理」に近しいのではないでしょうか。

演習・訓練の範囲

「2.2 サイバーセキュリティリスクの特定」の「2.2.5 演習・訓練」です。　演習・防御、検知、対応及び復旧にも関わるのでより広範囲になりそうです。一方、NIST CSFですとPR（防御）.ATに該当するので、本ガイドラインで「特定」に配置した理由が気になりました。

定義の充足

「等」の示す範囲をもう少し明確にできそうです。行政文書に明るくないのも一因ですが、「等」の範囲が広く、解釈に自信を持てませんでした。ガイドラインとして成立するには明確な定義が必用になるので、「定義」に関する章があるとよりガイドラインの読み手としては、理解しやすくなりそうでした。

まとめ: ルールメイキングに参加・貢献していきたい！

まとめとして、「金融分野におけるサイバーセキュリティに関するガイドライン（案）」を読み、コメントしまいた。あらためて、本ガイドラインを作成されたかたに感謝を。多大な苦労をもとに作成されたものを、「関係法令、監督指針等及び本ガイドライン等の趣旨を踏まえ、実質的かつ効果的な対応を行う*6」ことが可能になる正式なガイドラインに昇華するには、分野と規模を問わない金融事業者が実務経験をもとにフィードバックしていくことが大事になるので、積極的に「多様な主体の連携により、積極的に対応すべき*7」なのでしょう。そうしなければ、（他意はありません）現場に即していない「ガイドラインを形式的に遵守することのみを重視したリスク管理態勢」になってしまいます。最終的には、「安定の確保」につながるための実務的なチェックリストにしたいものです。

昨今の米国では、「NIST SP800-207A A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments *8」に見られるように、ルールメイキング側がEnvoy, K8S, SPIFFEEなどモダンな技術を取り入れる姿勢を見せています。逆に言うと、エンジニア側がそのルールメイキングに積極的に参加しているといってもいいのかもしれません（今まで参加していてその成果が表面化しただけかもですが）。

Fig. 3. Multi-tier policies for a hybrid application environment

本邦でも実際にシステム要件や実装、昨今の技術トレンドに明るいエンジニア等がこういったパブリックコメントを残していくのは大事な姿勢になると考えていますので、より「実質的かつ効果的な監督状況」を望む当社としては、積極的に監督行政とのコミュニケーションをとっていきます。

とはいえ、ルールメイキングや過去の経緯に必ずしも明るくはなく、限界を感じています。各ガイドラインに対して「点」での理解はしていますが、時系列や過去の議論、多の分野における状況など「面」での理解は全く追いついていません。上記で気になったところも的を得ているのかどうか...でも、やっていくしかないですね！

こういった主体的なポリシーメイキングや継続的なルールメイキングに興味のある方は、是非、ご連絡をお待ちしています。