その報告書は銀行を納得させなければならない — 取引相手の審査を受ける香港フィンテックのペネトレーションテスト

要点：取引銀行から求められたペネトレーションテスト報告書は、あなたのために書かれるものではありません。読むのは相手方の第三者リスク管理チームのアナリストで、チェック欄に印を付け、後からその判断を説明できなければならない立場の人です。受け入れられるかどうかを決めるのは、相手の関心に合ったスコープ、明記された手法、再現可能な証拠、日付入りの修正・再テスト記録であり、指摘事項の件数ではありません。

なぜ従業員28名のフィンテック企業が、銀行からペネトレーションテスト報告書を求められるのか？

説明のための架空の複合事例として、香港のあるフィンテック企業を考えてみます。従業員は28名、その約半数がエンジニアです。製品は法人向けの決済・消込プラットフォームで、法人顧客は自社の会計システムをAPI経由で接続し、プラットフォームが入出金の照合、例外の検知、決済指図の送信を行います。事業全体が一つの提携銀行に依存しています。銀行は顧客資金口座を保有し、決済網を提供し、そして最近はファイルアップロードではなくAPIでの直接接続を求めるようになっていました。

商業条件は数か月前に合意済みでした。その後、オンボーディングは銀行の第三者リスク管理チームに移り、セキュリティ質問票のところで止まりました。ほとんどの設問は、技術責任者が午後のうちに回答できるものでした。保存データの暗号化、本番環境アクセスへの多要素認証の強制、シークレットの保管方法、デプロイ権限を持つ人。ただ一行だけ、まったく答えられない項目がありました。「本取引に関係するシステムを対象とした、独立した第三者による直近のペネトレーションテスト報告書（過去12か月以内の日付のもの）を提出してください」。

同社はこれまで一度もペネトレーションテストを発注したことがありませんでした。資金調達の前に無料のスキャナーで自社サイトを検査したことはあり、クラウド事業者のセキュリティダッシュボードもおおむね緑色でした。しかし、どちらもペネトレーションテストではなく、どちらも独立したものではありません。営業チームが法人顧客3社に約束した稼働開始日までは、あと8週間しかありません。創業者の最初の反応は「PDFが出てくる一番安いテストを」。技術責任者の最初の反応は「お金で買える一番徹底的なテストを」。結論から言えば、どちらの直感も読者を取り違えています。

この状況は、香港のフィンテック業界ではもはや一つの型として認識できるほどよくあるものです。小さなチーム、正式なオンボーディング手続きを持つ相手方、他人が決めた期限、そして簡単そうに聞こえて実は簡単ではない一通の書類の要求。本記事では、その書類が実際に何を果たさなければならないのかを順に見ていきます。

ローンチ、規制当局、保険会社のためのテストとは何が違うのか？

ペネトレーションテストという同じサービスでも、その結果を誰が読むかによって答えるべき問いが変わります。きっかけが自社のローンチ日であれば、テストは自分たちのためのものです。顧客に見つかる前にどこが壊れるかを知りたいわけで、そのスケジュールの問題はアプリのローンチ日に合わせたペンテストの計画で取り上げました。きっかけがライセンスを付与する規制当局であれば、問いは「何年にもわたって維持されたテストプログラムを運用しているか」になります。これは香港の決済事業者が予期していなかったペンテスト要件の視点です。保険会社は更新時に、一度きりの深いテストよりも継続的なセキュリティ衛生の証拠を求めることが一般的です。

取引相手は、この三者のいずれとも異なります。銀行はあなたの規制当局ではないので検査する権限はなく、保険会社でもないのでリスクを保険料に織り込むこともしません。銀行は、自社のシステムと評判をあなたの会社に接続するかどうかを判断しようとしている一企業であり、そのリスク管理チームには「この水準のアクセス権を持つ第三者は、独立したセキュリティテストの証拠を提出しなければならない」というポリシーがあります。報告書はその証拠です。保管され、内部監査の対象になる可能性があり、それを受け入れたアナリストは、受け入れた当事者として記録に名前が残ります。この事実が、報告書に何が含まれていなければならないかを変えるのです。

報告書を実際に読むのは誰で、何を探しているのか？

読み手を具体的に思い浮かべてみてください。銀行の第三者リスク管理部門、あるいは情報セキュリティ部門のアナリストで、同時に数十件のベンダー・提携先のデューデリジェンス審査を抱えています。あなたのエクスプロイトを再実行することはまずなく、技術付録を開かないことすらあり得ます。このアナリストが報告書から探しているのは、おおむね次の順番で四つのことです。

第一に、その取引にとって重要なシステムがテストの対象になっているか。銀行があなたのAPIを呼び出すことになっているのに、報告書が会社案内のウェブサイトしかテストしていなければ、どれほどきれいな結果であっても審査には無関係です。第二に、独立した者が、認知された手法で、先方ポリシーが求める期間内に実施したか。第三に、何が見つかり、どの程度深刻だったか。特に、クリティカルまたはハイと評価されたまま未解決のものが残っていないか。第四に、それに対してあなたが何をしたか、そして誰かがそれを確認したか。

このリストにないものに注目してください。指摘事項の総数です。重大度の低い所見が40件あっても修正記録が明確な報告書のほうが、指摘が3件しかないのにその後の対応が一切わからない報告書よりも受け入れやすいのです。指摘ゼロの報告書は、かえって疑問を招くことさえあります。経験のあるアナリストは、きちんとスコープを定めて稼働中のウェブアプリケーションをテストすれば、ほぼ必ず何かが見つかることを知っています。結果が真っ白だと、実際には何をテストしたのかを疑い始めるのです。

アナリストは、何かを書き残さなければなりません。社内記録には、おおよそ次のような一文が残ります。「提携先はX日付の独立したペネトレーションテストを提出。スコープはYをカバー。未解決のクリティカル・ハイの指摘なし。修正はZ日に検証済み」。報告書がこの一文の空欄を埋めやすいものであれば、審査は速く進みます。アナリストが「スコープは何だったのか」「このハイの指摘は修正されたのか」と問い合わせのメールを書かなければならないなら、そこで一週間を失います。期限まで8週間という状況では、一週間は大きな意味を持ちます。

取引相手に受け入れられるペネトレーションテスト報告書の条件とは？

体裁を取り除くと、ほぼすべての役割を四つの要素が担っています。どれか一つが欠けていると追加の質問が来やすく、四つが揃っていれば報告書はそのまま保管されることが多いのです。

スコープの記述は、相手方の関心と一致しているか？

スコープの記述は、リスクアナリストが最初に注意深く読むページです。テスト対象のシステムを、相手方が認識できる言葉で列挙する必要があります。銀行が接続する本番APIのエンドポイント、顧客向けのウェブアプリケーション、それらをホストする環境の外部境界、そして顧客データに到達し得る管理インターフェース。どの環境をテストしたのか、つまり本番環境なのか、本番と同等のステージング環境なのかも明記し、後者であればなぜそれが代表性を持つのかを説明します。

同じくらい重要なのが、何をスコープ外としたか、そしてその理由です。「社内オフィスネットワークは対象外。本番環境とのネットワーク接続なし」という一文は、事実である限りまったく問題なく受け入れられます。印象が悪いのは沈黙です。沈黙はアナリストに推測を強いますが、推測こそがアナリストに許されていない行為だからです。

手法は明記されているか、それとも推測に任されているか？

アナリストは、テストがその場の思いつきではなく、認知された手法に沿って行われたことを確認する必要があります。ウェブアプリケーションとAPIであれば、通常は次の点を明記します。OWASP Top 10の各カテゴリーとそれ以上をカバーしたこと。クローズドボックス（テスターが内部情報を持たずに開始）かオープンボックス（ドキュメント、認証情報、コードへのアクセスあり）か。どのテストアカウントとロールを使ったか。そしてテストを実施した日時。

クローズドボックスかオープンボックスかは、実際の結果を左右する選択です。クローズドボックスは、外部の人間に何ができるかを教えてくれます。オープンボックスで各ユーザーロールの認証済みアクセスを使えば、はるかに多くのこと、それも銀行が本当に心配している点がわかります。つまり、あなたの法人顧客の一社が、APIを通じて別の顧客の資金を閲覧したり動かしたりできるかどうかです。マルチテナントの決済プラットフォームを取引相手が審査する場面では、APIの認証済みテストのほうが通常は有用な証拠になります。

その場にいなかった人が、証拠を再現できるか？

すべての指摘には概念実証（PoC）の証拠が付いているべきです。送信したリクエスト、返ってきたレスポンス、必要に応じてスクリーンショット、そしてその場にいなかった有能なエンジニアが再現できるだけの詳細。各指摘には、認知された尺度に基づく重大度評価（一般的にはCVSS）、平易な言葉によるビジネスへの影響の説明、段階的な修正手順が付されている必要があります。

これが取引相手にとって重要な理由は、あなたのエンジニアとは関係がありません。再現可能な証拠こそが、本物のテストと「質問票を満たすために作られた書類」とを分けるものだからです。証拠のない曖昧な指摘の羅列を見せられたアナリストには両者を区別する手段がなく、報告書は後者として扱われることになります。

日付入りの修正・再テスト記録はあるか？

これは小さなチームが最も見落としがちな要素です。テスターが引き上げた後に起きることだからです。銀行が見たい報告書は、初回の指摘事項だけではありません。初回の指摘事項に加えて、どれがいつ修正され、その修正を独立した誰かが確認したことを示す記録です。実務上は、修正状況の列が追加された改訂版の報告書か、元の指摘事項を識別番号で参照し、それぞれを「解決済み」「一部解決」「リスク受容」として記録した再テストレターのいずれかになります。

この記録がなければ、アナリストの手元にあるのは、あなたのプラットフォームの脆弱性の一覧だけで、それらが解消されたという証拠は何もありません。取引相手の立場から見ると、これはテストをまったくしていない状態よりも悪い状況です。既知の弱点が記された書類が、相手方の記録に残ってしまうからです。

スコープに何を含めるべきか、そして取引相手がめったに求めないものは？

コストの大半と価値の大半は、スコープを決める段階で決まります。そこで、本記事の事例のようなプラットフォームについて、よくある候補を一つずつ見ていきましょう。

• 外部ネットワーク境界：製品をホストする環境のうち、インターネットから到達できるものすべて。ロードバランサー、APIゲートウェイ、VPNエンドポイント、公開されたままの管理ポート、忘れられたサブドメイン。ほぼ例外なくスコープに入り、焦点を絞った外部テストが、信頼に足る最小の作業単位になります。
• ウェブアプリケーションとAPI：顧客向けアプリケーション、そして何よりも、銀行が呼び出し、法人顧客が利用するAPI。決済プラットフォームにとっては報告書の核心です。認証、テナント間の認可、入力処理、そして決済指図の再送や改ざんといったビジネスロジックの悪用。
• クラウド設定：ストレージの権限、IDとアクセスのポリシー、ログ、本番環境とそれ以外との間のネットワーク分離。独立した案件としてではなく外部テストと併せてレビューされることが多く、小さなチームの実際のリスクが潜んでいることが多い領域です。
• 内部ネットワーク：侵害を前提としたテストです。攻撃者が従業員のノートPCや社内サーバーに侵入した場合、どこまで横展開できるか。本番環境がすべてクラウド上にあり、オフィスネットワークから本番への経路がないフィンテック企業であれば、今回の審査における優先度は下がるかもしれません。オフィスから本番に到達できるのであれば、話は別です。
• 人：ソーシャルエンジニアリングとフィッシングシミュレーション。価値があり、実際のインシデントの多くがここから始まるようになっていますが、技術的な接続を審査する取引相手がオンボーディングの条件としてこれを求めることはまれです。実施する価値はありますが、今回の質問票の詰まりを解消する項目であることはめったにありません。

実務的な原則はこうです。取引とそこで扱われるデータに関わるシステムにスコープを合わせ、そのうえで相手方の質問票が明示的に挙げているものを追加する。質問票の記述が曖昧であれば、銀行のリスク担当窓口に、どのシステムがカバーされていることを期待しているのかを直接尋ねてください。そのメール一本で、的外れな対象をテストし直す手間が省けることがあります。

なぜ最安のスキャンは通らず、最も高額な案件は過剰になるのか？

事例の創業者と技術責任者は、それぞれ半分ずつ正しかったと言えます。コストは確かに重要であり、徹底性も確かに重要です。しかし問うべきは「どれだけテストするか」ではなく、「どのテストがこの読み手の必要とする証拠を生み出すか」です。

自動スキャン vs. スコープを定めたペネトレーションテスト vs. 過剰スコープの案件

• 自動脆弱性スキャン：速く安価で、定期的なコントロールとしては確かに有用です。シグネチャに基づいて既知の脆弱性と設定ミスを検査します。しかし、ビジネスロジックはテストできず、テナントAがテナントBの取引を読めるかどうかも判断できず、悪用可能性について人間の判断を含まない機械生成の報告書を出すだけです。ペネトレーションテストを求める取引相手のリスク管理チームの多くは、スキャンを代わりとしては受け入れません。スキャン報告書を提出すると、その後の審査全体で信頼を失うことにもなりがちです。
• スコープを定めたペネトレーションテスト：人間のテスターが、取引に合わせて定めたスコープで、明記された手法に基づき、スキャナーが検知したものとスキャナーには見えないものの両方を手動で検証し、CVSS評価とPoC証拠付きの指摘事項を出し、修正と再テストの工程まで含むもの。質問票が実際に求めているのはこれであり、この規模のプラットフォームであれば、通常はスケジュール内に収めることができます。
• 過剰スコープの案件：本格的なレッドチーム演習、大規模なソーシャルエンジニアリング、物理的侵入、すべての内部セグメント。それぞれ単体では価値があるものもあります。しかしこの読み手にとっては、その大部分がノイズです。アナリストはAPIと外部境界の章に直行します。そして追加されたスコープは日程を期限の先まで引き延ばし、予算を28名の会社が一通の書類に費やすべき水準を超えて押し上げます。

スコープを定めたテストは、他の二つの妥協案ではありません。読み手に照準を合わせた唯一の選択肢なのです。

期限から逆算して、スケジュールをどう組むべきか？

テストを始めたい日から前に積み上げるのではなく、銀行が最終書類を必要とする日から逆算してください。本記事の事例で、期限まで8週間ある場合、計画はおおよそ次のようになります。

最初の一週間はスコープ設定と契約に充てます。銀行にどのシステムのカバーを期待しているかを確認し、サービス提供者とスコープとテスト期間を合意し、各ロールのテストアカウントを用意し、本番環境の担当者がテストの実施時期を把握している状態をつくります。標準的なペネトレーションテストは業務を妨げないよう設計されており、必要に応じてテスト時間帯を営業時間外に設定することもできますが、テスト中にこちら側で連絡のつく担当者は必要です。

テストそのものの期間はスコープによって決まります。目安として、焦点を絞った外部ネットワークテストは通常3〜5日、外部・内部・ウェブアプリケーションを含む包括的な案件は通常2〜3週間です。サービス提供者は提案段階で期間とスコープの見積もりを示すべきであり、それが含まれていない提案書には署名すべきではありません。

その次に来るのが、誰もが過小評価する部分、つまり修正です。エンジニアには、見つかった問題を修正し、その修正をテストし、デプロイするための現実的な時間が必要です。テストが4週目に終わり、銀行が8週目に書類を必要としているなら、再テストまでに使える修正期間はおそらく2〜3週間です。重大な指摘が数件であれば足ります。しかしAPIに構造的な認可の問題が見つかった場合には足りません。だからこそ、次の二つの節が重要になります。

なぜ再テストは、小さなチームが交渉し忘れる部分なのか？

初めて発注する人のほとんどはテストそのものに意識を向け、再テストを細かな付帯事項として扱います。しかし取引相手から見れば、問題の一覧を「管理されている」という証拠に変えるのは、まさに再テストなのです。

契約前に、三つのことを明確にしておいてください。再テストは含まれているのか、含まれるならどのような条件か。初回報告書の発行後、いつまでに再テストを実施できるのか。再テストの成果物は何か。改訂版の報告書なのか、元の指摘の識別番号を参照した別紙のレターなのか。

参考までに、Brocentの年間テストパッケージには、初回の指摘事項の修正後に行う再テストが含まれており、脆弱性が解消されたこと、そして新たな問題が生じていないことを確認します。どのサービス提供者からであれ単発の案件を購入する場合には、再テストが含まれていると思い込まないでください。確認し、書面で回答をもらい、含まれていなければテスト開始前に作業範囲記述書（SOW）に盛り込むよう交渉してください。指摘事項が出そろい、期限まで2週間しかない段階で交渉するよりも、はるかに合意しやすいはずです。

誰が再テストを行うかも取り決めておきます。自社のエンジニアが行った再テストは、独立した証拠にはなりません。元のテストを実施した同じ提供者が、自らの指摘識別番号と照らし合わせて確認する形が、最もすっきりした記録になります。

期限までに修正できない指摘事項は、どう扱えばよいのか？

期限内に完全には修正できない、というのが正直な答えになる場合もあります。深い認可の問題は、データモデルにおけるテナント分離の設計し直しを必要とするかもしれません。古いコンポーネントは、自社ではコントロールできないベンダー側のアップグレードに縛られているかもしれません。そのとき、アナリストが気付かないことを期待したくなります。しかしアナリストは気付きますし、それによって失われる信頼は、指摘事項そのものよりも大きくなります。

有効なのは、次の三つを組み合わせることです。第一に、今すぐリスクを下げる補完的コントロール。影響を受けるエンドポイントを銀行のIPレンジからのみ受け付けるよう制限する、ゲートウェイに追加の認可チェックを設ける、再構築が終わるまで該当機能を停止する、あるいは攻撃者が取らざるを得ない特定の挙動に対する監視を強化する、といったものです。第二に、再テストでその補完的コントロールを検証し、当該指摘を「解決済み」ではなく「緩和済み」として記録すること。第三に、日付入りの修正計画。何を、誰が、いつまでに行い、どのように証拠を示すのか。可能であれば、完了後に追加の再テスト結果を共有することを約束します。

リスク管理チームは、こうした状況に慣れています。彼らが受け入れられないのは、計画のない未解決のクリティカルな指摘や、日付のない計画です。緩和され、監視され、6週間以内の修正が予定され、担当者が明示されたハイの指摘は、提携先の審査記録においてごく普通に見られるものです。

この報告書を、次の取引相手にも使い回せるのか？

本記事の事例では、銀行は最初にこれを求めた取引相手ですが、最後ではないでしょう。法人顧客、二つ目の提携銀行、決済スキーム、将来の投資家。いずれも一年以内に同じことを尋ねてくる可能性があります。最初からそれを想定しておく価値があります。

完全版の技術報告書は機密性の高い書類です。何しろ、あなたのプラットフォームがどのように攻撃されたかを示す地図なのですから。ほとんどの提供者と取引相手は、これが秘密保持契約のもとでのみ共有されることを前提としており、契約条件によっては第三者への再共有が制限されている場合もあります。報告書をどこかに送る前に、テスト提供者との契約を確認してください。よく見られ、かつ合理的なやり方は、二種類の書類を用意しておくことです。一つは完全版の報告書で、技術的な詳細が本当に必要な相手にだけ共有します。もう一つは、提供者が発行するエグゼクティブサマリーまたは実施証明レターで、スコープ、日付、手法、修正状況を記載し、エクスプロイトの詳細は含めません。多くの審査担当者はサマリーを受け入れ、その内容に疑問が生じた場合にだけ完全版を求めます。

使い回しには有効期限もあります。3月に受け入れられた報告書が、翌年の2月にも受け入れられるとは限りません。その間にプラットフォームに大きな変更が加えられていたり、次の取引相手のポリシーが12か月以内ではなく6か月以内のテストを求めていたりすれば、なおさらです。テスト対象となったプラットフォームの日付とバージョンを記録しておけば、その質問が来たときに答えられます。

単発のテストを、年次サイクルに変えるには？

最初のテストは、ほぼ必ずプレッシャーの中で購入されます。二回目はそうであるべきではありません。ある取引関係が独立したテストを要求するとわかった時点で、翌年も要求されること、そしておそらく接続部分に大きな変更を加えるたびに要求されることもわかっているはずです。

年次サイクルには予測可能なリズムがあります。毎年同じ時期にスコープを合意し、テストし、修正し、再テストし、更新された報告書とサマリーを保管し、必要な相手に共有する。経済性も変わります。同じプラットフォームを毎年テストする提供者は、そのアーキテクチャを理解していくので、調査にかける時間が減り、変更された部分により多くの時間を割けるようになります。エンジニアは、どの種類の指摘が繰り返し出てくるのかを把握し、根本から修正するようになります。そして取引相手が毎年受け取る報告書は、スナップショットではなくトレンドになります。それこそがリスクアナリストが本当に見たいものです。

修正後の再テストを含む年間パッケージが、案件ごとに一から交渉するよりも合理的になるのも、この段階です。Brocentのペネトレーションテストサービスは、外部ネットワーク、内部ネットワーク（侵害を前提とした横展開）、OWASP Top 10とそれ以上を対象とするウェブアプリケーションテスト、ソーシャルエンジニアリングとフィッシングシミュレーションをカバーし、クローズドボックスとオープンボックスの両方に対応しています。すべての指摘事項には、CVSSによるリスクスコア、PoCの証拠、ビジネスへの影響の説明、段階的な修正手順が記載されます。

それでも、年次テストはある時点の一枚の写真にすぎません。来年の写真が良いものになるかどうかを決めるのは、残りの51週間に何が起きるかです。

よくある質問

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

脆弱性スキャンは、既知の脆弱性や設定ミスを自動で検査するものです。ペネトレーションテストは、人間が主導して弱点の悪用を試みるもので、スキャナーには見えないビジネスロジックの欠陥も対象にし、実際に何が可能だったかの証拠を示します。スキャンは優れた定期的コントロールですが、ペネトレーションテスト報告書を求める取引相手は、通常スキャンを代わりとしては受け入れません。

ペネトレーションテストにはどのくらいの期間がかかりますか？

スコープによります。焦点を絞った外部ネットワークテストは通常3〜5日、外部・内部・ウェブアプリケーションを含む包括的な案件は通常2〜3週間です。その前にスコープ設定の時間、その後に修正と再テストの時間を見込み、今日から積み上げるのではなく、取引相手の期限から逆算して計画してください。

報告書は英語で作成されますか？

報告書の言語は、思い込みに任せず、作業範囲記述書に明記する項目にしてください。取引相手のリスク管理チームが英語で業務を行っているのであれば、報告書は最初から英語で書かれるべきです。後から翻訳した報告書は、アナリストが最も注意深く読む箇所、つまりスコープ、重大度、修正状況に曖昧さを持ち込むおそれがあります。

再テストは含まれていますか？

何を購入するかによります。Brocentの年間テストパッケージには、初回の指摘事項の修正後に行う再テストが含まれています。単発の案件であれば、どの提供者であっても、テスト開始前に再テストが含まれるかどうか、どのような条件かを書面で確認し、含まれていなければ盛り込むよう交渉してください。

報告書を複数の取引相手と共有できますか？

通常は可能ですが、秘密保持の条件のもとで行う必要があり、まずテスト提供者との契約を確認してください。実務的には、エグゼクティブサマリーや実施証明レターは比較的広く共有し、完全版の技術報告書は詳細を必要とする相手にだけ渡す、という方法が取られます。誰にどの版を渡したかを記録しておきましょう。

クリティカルな指摘事項が見つかったらどうなりますか？

修正できるものは修正し、再テストでその修正を検証します。期限までに修正できないものについては、補完的コントロールを導入し、日付と担当者を明記した修正計画を文書化します。そして正直に開示してください。緩和され、予定が組まれた指摘は提携先の審査記録ではごく普通のものですが、隠された指摘はそうではありません。

どのくらいの頻度で再テストすべきですか？

その取引関係が独立したテストを求める限り、少なくとも年に一度。加えて、スコープ内のシステムに大きな変更があった後、たとえば新しいAPIバージョン、新しいホスティング環境、認証方式の大幅な変更の後にも実施します。相手方のポリシーも確認してください。12か月より短い間隔を求めるところもあります。

報告書には誰が署名するのですか？

あなたではなく、テスト提供者です。報告書には、提供者、テスト実施日、報告書のバージョン、テストの責任者が明記されるべきで、実施証明レターや再テストの確認書も提供者が自らの名義で発行すべきです。自社で署名した書類は独立した証拠にはなりません。そして独立性こそが、この要求の核心なのです。

来年の報告書をきれいに保つ仕事は、実際にはどこで行われるのか？

事例に戻りましょう。このフィンテック企業は報告書を入手し、指摘の大半を修正し、残りを緩和し、銀行との接続が完了しました。12か月後、同じ質問がまたやってきます。二通目の報告書が楽に済むか苦しいものになるかは、その間に何が起きたかにほぼすべてがかかっています。そして、その中でペネトレーションテストに関わる部分はごくわずかです。

初回テストの指摘事項の多くは、特殊なものではありません。パッチが当たっていないコンポーネント、管理用パスで強制されていない多要素認証、意図より広い権限が付いたストレージバケット、ベースラインから逸脱した設定、誰も監視していなかった既知の脆弱性。こうしたものを見つけるのに年一回のテストは要りません。必要なのは、毎週誰かが見ていることです。

その継続的なセキュリティ衛生こそ、マネージドITサポートが担う仕事です。Brocentのユーザー単位のマネージドITサポートプランは、24時間365日のNOC監視、多言語ヘルプデスク、セキュリティガバナンス、バックアップと災害復旧、vCIOという五つの柱で構成されています。すべてのプランにはBCS Beamエンドポイントエージェントが含まれます。これは読み取り専用のセキュリティ・ヘルス監査で、CISに準拠したベンチマークで端末を点検し、CVE、CVSS、EPSS、CISAの既知の悪用された脆弱性（KEV）カタログに基づいて優先順位付けした脆弱性を継続的に監視し、パッチの適用状況を追跡します。さらに手厚い体制が必要な企業には、マネージドセキュリティサービスで専任の検知・対応まで拡張できます。Brocentは2007年に北京で創業し、2016年から香港オフィスを構え、2021年からシンガポールに本社を置いています。金融サービス分野のお客様は、こうした取引相手による審査に日常的に向き合っています。

香港のプラン料金は、ユーザー1人あたり月額で公開しています。Startup（従業員1〜5名）HK$855.14、Established（5〜300名）HK$1,247.40、Growth（10〜500名）HK$1,561.21、Enterpriseは個別見積もりです。28名のチームがEstablishedプランを選んだ場合、公開料金で月額HK$34,927.20。次の報告書を短くしてくれる日々の仕事の対価です。詳しい内訳は料金ページをご覧いただくか、今年のテストのスコープ設定と、来年のテストを楽にするプランについてお問い合わせください。

テストは写真です。プランは、誰も写真を撮っていないときのあなたの姿を決めるものです。