シンガポールのフィンテック企業のサイバー保険更新が、たった一つの脆弱性スキャンで止まった理由

シンガポールのある決済企業のサイバー保険更新は、ブローカーが投げかけた一つの質問で止まった。オフィスの誰もその場で答えられなかったのだ——「直近の脆弱性スキャンはいつ実施し、何が見つかりましたか」。 スキャンなし、レポートなし、そして提示条件での更新もなし——実際にスキャンを行うまでは。

サイバー保険がフィンテック企業に問う質問が変わった

シンガポールでライセンスを持つフィンテックまたは決済企業にとって、サイバー保険はかつてほぼ形式的な手続きだった。申込書に記入し、アンチウイルスとデータバックアップを実施している旨のチェックボックスにチェックを入れ、保険料を払って終わり。しかし、顧客資金や決済認証情報、口座データを扱う規制対象の金融事業にとって、この流れはもはや通用しない。

フィンテックや決済企業向けのサイバー保険を引き受ける保険会社は今、チェックボックス式の質問ではなく、証拠に基づく質問をしてくる。「ファイアウォールはありますか」は「直近の脆弱性スキャンレポートを見せてください」に置き換わった。「アンチウイルスは導入していますか」は「パッチ適用のサイクルを説明してください」に置き換わった。この変化の背景にある論理は単純だ。保険金請求データは、未パッチの既知の脆弱性が今なお攻撃者の最も一般的な侵入経路であることを示しており、保険会社は企業の言葉をそのまま信じるより、実際の証拠に基づいてそのリスクを価格付け（あるいは引き受け拒否）したいと考えている。

シンガポールでライセンスを持つ決済・フィンテック企業にとって、これはすでに馴染みのある別の圧力とも重なる。シンガポール金融管理局（MAS）のテクノロジーリスク管理ガイドラインは、規制対象事業者に対し、より広範なセキュリティ態勢の一部として定期的な脆弱性評価を含む、能動的なテクノロジーリスク管理を求めている。ファイアウォール、エンドポイント保護、多要素認証、そこそこ規律あるパッチ適用サイクルといった、妥当な日常的セキュリティ習慣をすでに築いている企業でも、保険会社に提出できるものが何もないという事態は起こり得る。なぜなら、こうした日々の衛生管理そのものは文書を生み出さないからだ。脆弱性スキャンは違う。それは、その成果全体が日付入りの読みやすい証拠物件であり、引受担当者がまさに問うている質問にそのまま答える、数少ないセキュリティ実務の一つなのだ。

シンガポールがアジア有数のフィンテック・決済ハブであるという立場は、この問題を、数多く、なお増え続けているMASライセンス取得済みの決済機関、電子マネー発行体、および関連する金融テクノロジー企業にとって現実の課題にしている。これらの企業の中核事業はしばしば顧客資金の移動や保管そのものであり、それはまさに保険会社が高リスクとみなし、より少ないではなくより多くの証拠を求める類の事業プロファイルである。市場が引き締まって以降、初めてサイバー保険を更新する企業は、誰にも直接告げられないまま証拠のハードルが上がっていたことに気づくことが多い——ブローカーは、昨年の会話には含まれていなかった書類を、ただ求め始めるのだ。

シナリオ：日常の習慣は良好だが、継続的で記録された実務がない

40人から80人規模の、シンガポールでライセンスを持つ決済またはフィンテック企業を想像してほしい——エンジニアリング、オペレーション、コンプライアンス、カスタマーサポート、そして小規模な財務チーム。日々の観点で見れば、そのIT セキュリティはおおむね良好な状態にある。ノートPCは管理・暗号化され、オフィスとクラウドの境界にはファイアウォールがあり、エンドポイント保護は全台に展開され、メールと基幹の銀行・決済プラットフォームには多要素認証が強制されている。パッチも、IT担当が手が回るタイミングで、おおむね適用されている。

この企業に欠けているのは、継続的で記録された脆弱性スキャンの実務——外部公開システム、内部サーバー、Webアプリケーションを既知の弱点について体系的にチェックし、各サイクルの終わりに日付入りのレポートを残す、スケジュール化されたプロセスだ。おそらく一年半前、クライアントのデューデリジェンス質問票に対応するために、単発のペネトレーションテストを一度実施したことはあるだろう。あるいは、以前在籍していたIT担当者がオープンソースのスキャナーを一度実行し、それ以来誰も見ていないかもしれない。いずれにせよ、コンプライアンス責任者が保険ブローカーに渡す「現在の脆弱性状況」を探しに行くと、直近四半期以内の日付が入ったものは何もなく、会社が現在運用しているシステムに明確に対応するものもなく、直近のスキャンが実際に何を見つけ、それが修正されたかどうかを自信を持って言える人も誰もいない。

これは実に一般的なギャップであり、不注意の表れではない——むしろ、成長中の企業が日常的なインシデントを防ぐセキュリティ対策（ファイアウォール、エンドポイント保護、多要素認証）に投資しながら、それらの対策に既知の弱点がないかをスケジュールに沿って確認し記録するという、別の継続的な規律に対しては誰も担当者を割り当ててこなかった、という結果に過ぎない。

このギャップは、企業が成長するにつれて静かに広がっていく傾向もある。オフィスが一つ、クラウド環境が一つの40人規模のフィンテック企業であれば、頭の中で全体像を把握することはまだ可能だ。しかし、ハイブリッドリモートのエンジニアリングチームを抱え、十八か月の間にいくつものSaaS連携を追加し、パートナー向けに開放された決済APIがあり、誰も廃止手続きを取っていないレガシーサーバーが数台残っている80人規模のフィンテック企業では、そうはいかない。新しい連携を一つ追加するたびに、新しいクラウドサービスを一つ導入するたびに、新入社員のノートPCが一台増えるたびに、攻撃者——あるいは保険会社の質問票——が「対象範囲」とみなすものが少しずつ広がっていく。現在稼働しているものを自動的にカバーする継続的なスキャンがなければ、「誰もチェックしていないもの」のリストは、事業の成長とともに、誰にも気づかれないまま膨らみ続け、更新の会話がそれを一気に直視させるまで続く。

この質問に答えられないと、何が起こるか

最も直接的で目に見える問題は、更新そのものだ。ブローカーが保険会社から直近の脆弱性スキャンまたは評価レポートを求める要求を持ち帰るが、企業側には最新かつ完全な資料として送れるものが何もない。ここから起こり得ることは、いずれも望ましいものではない。未知のリスクを価格に織り込むため、更新見積もりが大幅に上がる。保険は更新されるものの、未パッチの脆弱性に起因するインシデントに特化した補償除外や副限度額が付く。あるいは、引受担当者が、補償を確定させる条件として、決められた期間内（多くの場合30日以内）にスキャンを完了するよう求め、計画的に進めるべき作業が突貫工事に変わってしまう。

この直接的な問題の下には、誰かが問い始めるとほぼ必ず表面化する、三つの別の問題がある。

• 「最後にいつ確認したか」の担当者がいない。 ファイアウォール、EDR、多要素認証といったセキュリティツールには、通常、明確な担当者がいる。誰かがそれを購入し、設定しなければならなかったからだ。しかし脆弱性スキャンにはそれがないことが多い。それは一度きりの購入ではなく、継続的な*活動*だからであり、担当者が割り当てられていない継続的な活動は、誰にも気づかれないまま静かに止まってしまう。
• 単発のペネトレーションテストと継続的なスキャンの混同。 これらは日常会話の中で互換的に使われがちだが、実際には異なる質問に答えるものだ。ペネトレーションテストは、特定の対象に対して熟練した攻撃者が実際に何を達成できるかを証明する、時点固定の手動主導の演習であり——価値はあるが、実施した日付のスナップショットにすぎない。脆弱性スキャンは、より広範で、繰り返し可能で、主に自動化された、既知の弱点についての継続的なチェックであり、スケジュールに沿って実行されることを前提としている。保険会社が「現在の脆弱性状況はどうなっていますか」と尋ねるとき、求めているのは後者であり、十八か月前のペネトレーションテストのレポートがどれほど優れていても、その質問には答えられない。
• 是正のループがなく、見つかった問題（あるとしても）が放置される。 スキャンが実施されていたとしても、その結果である発見事項のリストが誰かの受信箱に置かれたまま追跡されずにいるなら、企業は自らのリスクエクスポージャーを文書化するために費用を投じただけで、実際にはリスクを減らせていないことになる——これはスキャンを一切行わないより悪い状況とすら言える。なぜなら、発見済みだが未修正の問題は、保険会社や監査担当者から「なぜこれがまだ開いたままなのか」と正当に問われうるものになるからだ。

Brocent の見解：保険会社は具体的で答えられる質問をしている

こうした状況にある企業にとって本当に役立つ捉え直しは、次のようなものだ。保険会社が求めているのは完璧なセキュリティプログラムではない。求めているのは、具体的で範囲が明確な、答えられる質問だ——自社のシステムにある既知の弱点を能動的に確認し、見つかったものに対して対応しているという現在の証拠を示せるか、というものだ。それは「絶対にハッキングされない」ことを証明するよりもはるかに小さな要求であり、対応する解決策もそれに見合って具体的で実現可能だ——引受担当者、監査人、あるいはクライアントのデューデリジェンスチームが実際に読み、行動に移せるレポートを生み出す、継続的な脆弱性スキャンの実務を構築すること。

誠実な解決策は、更新の一週間前に慌てて対応することではない。保険の失効まで二週間という段階でパニック的に発注される単発のスキャンは、技術的には文書を生み出す——だがそれは同時に、「保険会社に言われたから始めた」という明白な日付印を持つ文書でもあり、継続的で日付の入ったシリーズの四番目、五番目のレポートと比べれば、次回の更新において明らかに弱い立場になる。より強固で、長期的にはより安価な立場は、脆弱性スキャンを、企業がすでにパッチ適用やバックアップに対して行っているのと同じように扱うことだ——一回限りのコンプライアンス上の購入ではなく、常設の、担当者を持つ、継続的な運用実務として。

これはまた、本稿の前半で触れた「チェックボックス対証拠」という区別が、企業にとって有利に働く場面でもある。先月付けのCVSSスコア付きスキャンレポートに、何が見つかり何が修正されたかを短くまとめたメモを添えてブローカーに渡せる企業は、反応的な慌てふためきではなく、日常的な運用規律という立場から、保険会社が実際に問うている質問に直接答えていることになる。この違いは、ファイルを審査する引受担当者の目には明らかであり、更新が円滑に進むか、それとも再価格付けや遅延の対象になるかを分ける違いでもある。

本物の脆弱性スキャン実務に実際に含まれるべきもの

保険会社、監査人、あるいはMASのテクノロジーリスク管理の期待に対して実際に通用するように構築された脆弱性スキャンの実務には、いくつかの具体的で譲れない要素がある。「スキャンをしています」という言葉が、真に厳格なプログラムから、誰も読んでいない自動化ツールのレポート一枚まで、ほぼ何でも意味しうる以上、それらが具体的に何であるかを明確にしておく価値がある。

• CVEに基づく検出と、現実の悪用可能性による優先順位付け。 理論上考えられるすべての脆弱性を羅列しただけのスキャン結果は役に立たない——ほとんどの企業は、どれが重要かを判断する手立てもないまま、何百もの発見事項を前に立ち尽くすことになる。有用なスキャンは、発見されたソフトウェアや設定を既知のCVEデータベースと照合し、CVSSの深刻度スコア、EPSS（実世界での悪用可能性を推定する指標）、そしてCISAの既知悪用脆弱性（KEV）リストといったシグナルを用いて優先順位を付ける。これにより、今月実際に悪用されている五件の問題が、理論上のものにすぎない二百件を差し置いて、レポートの最上位に浮かび上がる。
• 継続的なペース——年一回ではなく、月次または四半期ごと。 脆弱性スキャンは、動き続ける対象のスナップショットだ。新しいCVEは絶えず公開されており、一月には問題がなかったシステムが、三月には新たに公表され、現に悪用されている弱点を抱えているということもありうる。月次または四半期ごとのスキャン（Brocentのマネージドスキャンの各ティアは、一時点のチェックではなく継続的・常時稼働のベースで実行される）こそが、誰かがそれを読む頃には古びているのではなく、常に最新の状態を保つ方法だ。
• 機器・資産ごとのリスクスコアを伴う、平易な言葉で書かれたレポート。 スキャンツールから直接出力される生データは、ブローカーや監査人、あるいは技術に詳しくないコンプライアンス責任者が扱えるものではない。保険会社に渡す価値のあるレポートには、人の手で書かれたエグゼクティブサマリー、具体的な資産に対応付けられ優先順位付けされたCVSSスコア付きの発見事項リスト、そしてIT担当以外の人でも何が見つかりどれほど深刻かを理解できるだけの十分な文脈が含まれている。
• 受信箱に放置されるレポートではなく、是正のループ。 スキャンの意味は問題を修正することにあり、記録することにはない。持つ価値のある実務には、「発見」から「修正確認済み」への追跡可能な経路が含まれる——理想的には、修正が実際に機能したことを確認する再スキャンも伴う——ことで、企業は「スキャンしています」だけでなく、「スキャンし、そして見つけたものを閉じています」と誠実に言えるようになる。

この質問への三つの対応の仕方

• 継続的スキャンなし（「監査の前にチェックすればいい」）： セキュリティ対策自体は存在するが、脆弱性のチェックは受け身の対応であり、通常はクライアントの質問票、監査、あるいは保険更新に迫られて初めて行われる。どの時点をとっても、日付入りの最新レポートは手元になく、時間的な圧力の下で作成されるものは、履歴を伴わない単発の代物にすぎない。
• 年一回の単発ペネトレーションテスト： 確かに有用な演習だが、定められた範囲に対する手動テストによって生み出される、単一の日付のスナップショットであり、答えるのは「この日、熟練の攻撃者はこのシステムに対して何を達成できたか」であって、「現在、我々の全システムにどのような既知の弱点が存在するか」ではない。十二か月後、次回の更新の時点では、そのレポートは、直近の情報を期待する質問に対する古い証拠になっている。
• 月次レポート付きの継続的脆弱性スキャン（Brocentモデル）： 対象範囲に応じて外部、内部、認証付き、Webアプリケーションのスキャンを含む、継続的でマネージドなスキャン実務であり、スケジュールに沿って実行され、各サイクルごとに日付入りでCVSSに基づき優先順位付けされたレポートを生み出し、追跡可能な是正経路と再スキャンによる確認を伴う。これは、保険会社や監査人が質問するたびに、誰かがツールを実行しようと思い出したその一回限りではなく、常に最新の証拠でその質問に答えられるバージョンだ。

より広範なセキュリティプログラムへの位置づけ

脆弱性スキャンは、企業のセキュリティスタックの他の部分を置き換えるものではない——それは、スタックの他の部分が実際に意図した通りに機能しているかどうかを教えてくれる実務だ。Brocentの脆弱性スキャンサービスは、Brocentのマネージド IT サポートプランのアドオンセクションから直接申し込める独立したアドオンサービスとして提供されており、企業が保有する資産数に応じて規模が決まり、単発の評価としても、継続的なスキャンと定期的なレポーティングを伴う継続的なマネージドサービスとしても提供される。

シンガポールのフィンテックまたは決済企業にとって、このサービスは通常、他の二つの要素と並んで位置づけられる。一つはマネージド IT セキュリティサービスで、日常的な監視、パッチ管理、エンドポイント保護をカバーしており、スキャンレポートはまさにその有効性をチェックしている対象だ。もう一つはBrocentのより広範なサイバーセキュリティ実務で、脆弱性管理プログラムを取り巻くリスク評価、セキュリティ意識向上トレーニング、インシデント対応計画をカバーしており、それを置き換えるものではない。これらはいずれも必須のバンドルとして販売されているわけではない——企業は、既存のIT サポート体制に上乗せする形で脆弱性スキャンだけを単独で追加することも、より広範なセキュリティサービス群と組み合わせることもできる。スキャンサービスおよびその他すべてのアドオンの、チームサイズに応じた現在の価格は、Brocentの価格ページに掲載されている。更新のタイムラインに取り組んでいる企業、あるいは単に自社の規模でスキャンプログラムがどれくらいの費用でどこまでカバーするのかを把握したい企業は、お問い合わせページからBrocentに直接連絡できる。

よくある質問

脆弱性スキャンとペネトレーションテストの違いは何ですか？

脆弱性スキャンは自動化されており、対象範囲が広く、繰り返し実行可能だ——定義された一連のシステムを既知の脆弱性データベースと照合し、継続的なスケジュールに沿って結果を報告する。ペネトレーションテストは、テスターが特定の対象に対して実際に弱点を悪用しようと試み、現実世界への影響を証明する、手動かつ時点固定の演習だ。スキャンは「現在、我々が運用している全システムにどのような既知の弱点が存在するか」に答え、ペネトレーションテストは「この日、熟練の攻撃者はこの特定のシステムに対して実際に何を達成できるか」に答える。両方を必要とする企業の多くは、スキャンを継続的に、ペネトレーションテストを定期的に（一般的には年一回、または主要なシステムに変更があったとき）実施している。

スキャンは実際どのくらいの頻度で行うべきですか？

保険会社、監査人、あるいはクライアントから問われたときに結果がまだ最新であってほしいなら、年一回ではなく、月次または四半期ごとに行うべきだ。新たな脆弱性は絶えず公表されているため、年一回のスキャンは、それが本来カバーすべき一年のうちのほとんどの期間で古びてしまう。Brocentのマネージドスキャンの各ティアは、単発のチェックではなく継続的なベースで実行され、記録に残るレポートが常に最新であるようにするためのものだ。

スキャンレポートで保険会社は満足しますか、それとも他に何か求められますか？

保険会社や保険の規模によって異なるが、何を確認し、何を発見し、何を是正したかを示す、日付入りでCVSSスコア付きの脆弱性スキャンレポートは、多くのサイバー保険引受担当者が能動的な脆弱性管理の証明を求める際に、まさに期待している種類の証拠だ。より大規模な保険や、よりリスクプロファイルの高い企業では、継続的なスキャンに加えて定期的なペネトレーションテストが期待されることもある。両者は互いを代替するものではなく、補完し合うものだ。

スキャンでは実際に何をチェックするのですか？

範囲はスキャン対象によって異なるが、適切に実施される評価は、外部のインターネットに公開されたシステム（オープンなインターネット上の攻撃者が到達しうる範囲）、内部ネットワークとサーバーインフラ、そして該当する場合には認証済みチェックと、一般的なWeb脆弱性のOWASP Top 10カテゴリに基づくWebアプリケーション／APIスキャンをカバーする。Microsoft 365、Azure、AWSの設定といったクラウド環境も対象範囲に含めることができる。そこでの設定ミスは、クラウドホスト型のインフラを運用するフィンテック企業にとって、より一般的な露出源の一つだからだ。

スキャンで見つかった問題は誰が修正するのですか？

スキャン自体は問題の特定と優先順位付けのみを行う——是正は別のステップだ。取り決めによっては、企業自身のITチームが発見事項リストに対応することもあれば、マネージドサービスの一環として、修正が確認済みの解決まで追跡され、再スキャンによって検証されることもある。いずれの方式でも重要なのは、「発見」から「修正確認済み」への文書化された経路があることであり、一度メールで送られてそれきり忘れられるリストではないということだ。

自社の規模だと、これは通常どのくらいの費用がかかりますか？

価格は対象範囲内の資産数、そして単発の評価か継続的なマネージドサービスかによって変動する——40〜80人規模の精鋭フィンテック企業が外部・内部スキャンをスコープする場合の見積もりと、複数拠点を持つエンタープライズ規模の案件とでは、桁が大きく異なる。Brocentの価格ページには現在の各ティアと含まれる内容が掲載されている。正確な数字を得る最も確実な方法は、お問い合わせページから資産数とコンプライアンス目標を送り、その時点での見積もりを受け取ることだ。

これは既存のファイアウォール、多要素認証、エンドポイント保護といったセキュリティ対策を置き換えるものですか？

いいえ、そのために設計されたものでもない。脆弱性スキャンは、それらの対策が正しく設定されているか、そしてその背後にあるシステムに既知の未パッチの弱点がないかを確認するものだ——対策そのものの代替ではなく、検証のレイヤーだ。日常的なセキュリティ習慣がしっかりしているが継続的なスキャンを行っていない企業は、どちらも持たない企業よりも確かに良い出発点にいる。しかしそれでもなお、保険会社、監査人、あるいはクライアントのデューデリジェンス質問票が実際に見たいと望んでいる一つの証拠物件——日付入りで証拠に裏付けられたレポート——を欠いている。

保険期間の途中で、まだ更新時期ではないのですが、今始める価値はありますか？

ある。むしろ、それはより良い始め時だと言える。周期の途中で継続的なスキャン実務を開始すれば、次回の更新の会話が来る頃には、締切の二週間前に発注された単発のレポート一枚ではなく、すでに数か月分の日付入りレポートが手元にあることになる。それはまた、初回のスキャンで見つかった問題——初めてスキャンを行う企業にとっては通常最も件数が多い——が、保険会社や監査人が証拠の提示を求めてくるであろう日よりもかなり前に、すでに対応・解決されていることも意味する。

まとめ

保険会社が現在の脆弱性スキャンの証拠を求めているのは、ひっかけ問題を出しているわけでも、企業に対してまったく別の、よりセキュリティ成熟度の高い事業体になれと求めているわけでもない。求めているのは、CVEに基づくスキャンをスケジュールに沿って実行し、平易な言葉でレポートし、追跡可能な修正を伴う、具体的で継続的、定義の明確な一つの実務だ——そして、Brocentがシンガポールで支援する多くのフィンテック・決済企業は、保険会社、監査人、あるいはクライアントの質問票から直接尋ねられるまで、この実務を備えていなかった。それを、更新前の慌ただしい対応としてではなく、常設の運用ルーティンとして一度構築することこそが、「監査の前にチェックすればいい」を、問われるたびに自信を持って答えられる質問へと変える。