Help Net Securityの動画で、CylerityのCTO兼CISOを務めるDrew McCombs氏が、2つの役割をどのように両立させているかを語っています。同社ではセキュリティ対応をすべてのスプリントに組み込んでおり、患者データや資金の支払いに関わる問題を最優先で扱います。
McCombs氏は、CylerityがPHI（保護対象医療情報）を提携銀行に渡さないための工夫を説明しています。また、AIモデルは推奨するだけで自ら行動しない理由や、小規模な医療機関にとってメールのMFA有効化が最も低コストな対策である理由にも触れています。さらに、病院のCISOがフィンテックベンダーに尋ねるべき3つの質問と、その場で商談を打ち切るべき回答も挙げています。
CTOとCISOの肩書を兼任されています。ロードマップが競合した場合、どちらを優先しますか。また、公正さをどのように保っていますか。
この2つのロードマップは多くの場合うまく噛み合うため、別々のバックログとして扱ってはいません。セキュリティは完成することのない中核機能であり、重要なプロジェクトを着実に進めるために、すべてのスプリントに組み込んでいます。エンジニアリングチーム全体でも議論しています。そのため、セキュリティは後付けの作業ではなく、開発の全工程を通じて常に意識されています。
加えて、当社のSDLC（ソフトウェア開発ライフサイクル）では、すべての開発物に対してフルセキュリティスキャンを義務づけています。新たなリスクを抱え込まずに素早く提供できるよう、基盤への投資も続けています。こうした方針により、ほとんどの対立は計画の前に解消され、各スプリントの計画を完全に見通せる状態にあります。
それでも選択を迫られたときの答えは明確です。患者データや資金の支払いに影響する問題が優先されます。例外はありません。それ以外については、機能の提供と、中核となるセキュリティ施策の着実な前進とのバランスを取ります。
両方の肩書を持つ以上、中核的なセキュリティプロジェクトの進捗について、可視性と説明責任が欠かせません。そのため、進捗は経営陣と定期的に追跡・レビューしており、何がいつ起きているかが明確です。こうすれば判断を私一人が下すことはなく、セキュリティにも適切な緊急度で取り組めます。
HIPAAと銀行の要件が矛盾するのはどのような場面で、どう解決していますか。
まず、Cylerityが何であり、何でないかを押さえておくことが重要です。Cylerityは銀行ではなく、売掛債権のファクタリングも行っていません。当社は銀行の融資枠を使って医療機関に資金を提供しており、顧客は法人のみで、消費者は対象としていません。したがって、銀行規制の中核をなす多くの規制は、当社に直接は適用されません。代わりに、銀行側の要求は、信用契約や提携銀行によるデューデリジェンスを通じて当社に及びます。そこでは、顧客が誰か、資金がどう動くか、何を報告するか、銀行が何を監査できるかが審査されます。
HIPAAとの整合は取れていますが、複雑になるのは担保の部分です。当社は医療費請求（クレーム）を担保に融資しており、請求には患者情報（PHI）が含まれます。銀行が顧客の借入基準額（ボローイングベース）を議論する際には、明細行レベルまで掘り下げたほうが好都合なことが多くあります。そこで、銀行にPHIを開示しないための具体的な計画を立てています。
当社の方針は次のとおりです。第一に、顧客を支援するために必要な最小限のデータだけを扱います。通常は、支払者や顧客単位の集計情報を提供し、請求単位の詳細は取り除きます。第二に、明細行レベルまで掘り下げる必要がある場合でも、請求の識別子は公開しません。その粒度の詳細が必要なときのために独自の識別子を作成しており、これによりPHIは保護されます。最後に、プラットフォーム全体で、PHIを融資に必要なデータから分離しています。融資パートナーを含め、あらゆるデータ要求にはこの方針で応えています。
モデルが資金や患者データに触れる前に、最低限必須とする統制を一つ挙げるなら何でしょうか。
私にとっては単純で、モデルは行動しない、ということです。AIは推奨、要約、フラグ付けはできますが、その出力と、資金の放出や患者データの開示につながるあらゆる行為との間には、必ず人間が介在します。こうした知見は審査やモニタリングに取り入れ、チームがより多くの情報に基づいて判断できるようにしています。ただし、最終的な決定はあくまで当社のチームが下します。
この統制を機能させるのは説明可能性ですが、説明可能性そのものが統制ではありません。理解できないものを、レビュー担当者が実質的に承認することはできないからです。そのため、モデルが推奨を示すときは、根拠にしたソースデータも表示します。当社のチームは、モデル自身の説明ではなく、そのソースと照らし合わせて確認します。モデルが自らの推論過程を説明しても、それは証拠にはなりません。
私が最も注視しているリスクは、派手な攻撃ではありません。徐々に進む逸脱（ドリフト）です。レビュー担当者は最初の100件の推奨こそ慎重に承認しますが、やがて形だけの承認に陥ります。これには、判断に複数人を関与させることや、判断後に定期的に振り返ることで対処しています。
小規模な医療機関をオンボーディングする際に最もよく見られる弱点は何で、最も安価な対策は何でしょうか。
最もよく見られる弱点は、小規模な医療機関に特有のものではありません。どの企業にも当てはまります。MFAは依然として最も重要な統制の一つですが、まだ十分に使われていません。当社が支援する組織にとっては、特に重要です。こうした組織は、医療やサービスを提供するために作られたのであって、ITを運用するためではありません。患者データや医療費の支払いを初めて扱う組織も多くあります。
だからこそ、最も安価な対策が最も効果的でもあります。まずはメールからMFAを有効にすることです。通常、すでに契約しているメールサービスに含まれています。これは最低条件であり、このギャップを一つ塞ぐだけで、アカウント乗っ取りや支払い詐欺に至る最も一般的な経路を断てます。
当社の役割は、推奨するだけにとどまりません。当社は顧客の日々の収益サイクルを支援しているため、請求や資金調達の動きをリアルタイムで把握できます。そのため、通常のパターンから外れた動きを、小さなチームが単独で行うよりも早く見つけられます。さらに、入金口座の変更依頼が届いた場合は、依頼に記載された番号ではなく、すでに登録されている番号に電話をかけて確認します。
病院のCISOはフィンテックベンダーにどのような3つの質問をすべきでしょうか。また、どの回答が出たら取引を見送るべきでしょうか。
1つ目は、「再委託先、AIサービス、融資パートナーやその監査人を含め、当社のデータに触れるすべての関係者を挙げられますか」です。ベンダーがこの一覧をすぐに出せないなら、データがどこへ流れているのかを把握していません。フィンテックの貸し手は、患者の情報を含む記録に対して監査権を持つ場合があることを忘れてはなりません。契約を結ぶ前に、このことを知っておくべきです。
2つ目は、「資金の送金先の変更を、どのように検証していますか」です。フィンテックベンダーにとって、支払い先のすり替えは実害の大きい攻撃です。「依頼を慎重に確認しています」ではなく、誰も省略できない帯域外（アウトオブバンド）の確認手順があるという回答を聞くべきです。
最後は、「当社のデータが関わる侵害を発見してから最初の24時間の対応を説明してください。誰が誰に連絡しますか」です。求めるべきは、ポリシー文書ではなく、担当者名、役割、タイミングです。話を打ち切るべき回答は、「当社はHIPAA認証を取得しています」です。HIPAAには公式の認証制度が存在しません。この回答は、ベンダーが規則を誤解しているか、顧客が知らないことを当てにしているかのどちらかを示しています。
翻訳元: https://www.helpnetsecurity.com/2026/10/05/drew-mccombs-cylerity-healthcare-fintech-security/
