アミール・カヤットは、SaaSおよびAIエコシステムセキュリティのリーダー企業VorlonのCEO兼共同創業者である。
AT&Tはまもなく1億4900万ドルを、サードパーティストレージプロバイダーのSnowflakeに関連する2024年のハッキング後にデータが漏洩した現在および過去の顧客に支払う予定だ。AT&Tだけがこの不幸に見舞われたわけではなく、Snowflakeの顧客160社以上がこの侵害の影響を受けた。サードパーティリスクに関しては、これは氷山の一角に過ぎない。
今日のAIとSaaSを活用した企業において、どの組織も孤立して存在することはできない。平均的な企業は現在100以上のクラウドアプリケーションを使用しており、それぞれがベンダー、パートナー、インテグレーションのウェブに接続されている。この相互接続性はイノベーションと成長を促進するが、デジタル境界線が最も脆弱なベンダーのセキュリティにまで及ぶという持続的かつ増大するリスクも伴う。
最も堅固な組織でさえ、重要なベンダーが躓くと不意を突かれる可能性がある。その混乱は現実のものであり、その代償は甚大となりうる。侵害が最初の侵害から数週間（あるいは数カ月）後に報告されるという恐ろしい現実は、積極的な封じ込めのための時間枠を縮小させる。あなたがそれを知る前から、すべての時間が重要なのだ。
ここでは、サードパーティSaaS侵害が発表された瞬間にすべてのセキュリティリーダーが取るべき行動と、次に危機が発生した際の被害を制限するための積極的なフレームワークの構築方法を紹介する。
侵害が発生した際の対応
1. 遅滞なくインシデント対応チームを編成する。
侵害通知後の最初の24時間は極めて重要だ。セキュリティ、IT、法務、広報、主要事業部門、侵害されたベンダーの代表者を含む、機能横断的なインシデント対応チームを編成する。行動を調整し、明確なコミュニケーションを確保するための単一の連絡窓口を指定する。
できれば、データ侵害に対する対応計画をすでに持っているはずだが、持っていない場合は今が作成する時だ。各行動の責任者、内部および外部とのコミュニケーション方法、機密データが関与している場合のエスカレーションステップを文書化する。
2. ベンダーから事実を収集する。
侵害されたSaaSベンダーから入手可能なすべての情報を収集する。以下を確認する：
• 侵害はいつ検出され、システムはどれくらいの期間露出していたか？
• 侵害の性質は何か（例：認証情報の盗難、設定ミス、APIの悪用、マルウェアなど）？
• どのタイプのデータとどの顧客セグメントが影響を受けたか？
• ベンダーはこれまでにどのような是正措置を講じ、今後何を計画しているか？
• 自社環境での侵害を探すために使用できる技術的指標は何か（例：不審なIPアドレス、ファイルハッシュ、侵害されたAPIキーなど）？
• 使用できるフォレンジック報告書はあるか？
3. 自社の被害状況を評価する。
初期の事実を把握したら、自社組織がどのように影響を受けたかを判断する。多くの企業はこの段階で躓くが、それはSaaS環境の可視性が不足しているか、重要なログが欠けているためだ。
不完全または断片的なログ記録は、このプロセスを指数関数的に困難にする。多くの組織は、インシデント後になって初めて、SaaSテレメトリが何が起きたかを追跡するのに十分な粒度を持っていないことに気づく。
評価プロセスのチェックリストは以下の通り：
• すべてのベンダー統合をインベントリ化する。 侵害されたベンダーに関連するすべての統合、ユーザーアカウント、API接続、サードパーティアプリをマッピングする。マシンアイデンティティ、サービスアカウント、シャドーIT接続を忘れないこと。
• 認証ログを確認する。 不審なアクティビティ（通常とは異なる地域やIPアドレスからのログイン、ログイン試行の失敗、ブルートフォースパターン、通常の営業時間外のアクセスなど）について認証ログを分析する。
• データアクセスと転送ログを精査する。 異常なデータダウンロード、エクスポート、APIコールを特定する。特に機密性の高いデータや規制対象データに関わるものに注意する。
• 権限変更を調べる。 侵害期間中のユーザーまたはアプリの権限に予期しない変更がないか確認する。
• 認証情報とトークンの悪用を確認する。 APIキー、OAuthトークン、サービス認証情報がアクセスされたり悪用されたりしていないか調査する。必要に応じて認証情報をローテーションし、取り消す。
4. 封じ込め、コミュニケーション、是正措置を行う。
自社環境での露出や侵害の証拠が見つかった場合：
• 影響を受けた認証情報とトークンを直ちに取り消すか、ローテーションする。
• 侵害されたベンダーとの統合を制限または一時的に停止する。
• 法律または会社のポリシーに従って、影響を受けたユーザーまたは顧客に通知する。
• 規制上およびフォレンジック目的のために、取られたすべての行動を文書化する。
透明で適時のコミュニケーションは、社内外のステークホルダーとの間で極めて重要だ。法務チームと広報チームと協力して、メッセージが正確であり、不必要なパニックを引き起こさないようにする。
5. 報告と協力。
業界や管轄区域によっては、規定の時間枠内に規制当局に侵害を報告する必要がある場合がある。規制当局への通知用のテンプレートを用意し、アクセスされた内容、対応方法、現在の影響評価に関する詳細を共有できるよう準備する。
侵害されたベンダーや他の影響を受けた顧客と協力して、情報を共有し、対応を調整し、集団的な防御を改善する。
積極的な対策：より良いログ記録と継続的なモニタリングの必要性
厳しい現実として、多くの組織は侵害が発生した後、もし発見できたとしても、自社の被害の全容を把握するのが遅れることが多い。ベンダーからすべての回答を待つのはリスクが高い。特に攻撃者が接続されたSaaSアプリ間を横断的に移動することが多いためだ。
将来のサードパーティ侵害による被害範囲と規制上の影響を軽減するために：
• 包括的なSaaSログ記録に投資する。 ユーザーアクティビティ、データアクセス、APIコールが詳細に記録され、ログが意味のある期間保持されるようにする。
• マシンアイデンティティとトークンを監視する。 すべてのサービスアカウント、トークン、キーの作成、使用、権限レベルを追跡する。
• 統合を継続的にインベントリ化する。 ITの直接監視外でユーザーによって作成されたものを含め、すべてのSaaS接続のリアルタイムマップを維持する。
• 異常検出を自動化する。 通常の行動をベースラインとし、SaaSエコシステム全体で不審なパターンを強調するツールを使用する。
結論
過去のように組織の境界内にセキュリティが限定されていた時代とは異なり、今日のセキュリティチームは、しばしば直接的な管理外から発生する、ますます複雑な攻撃に直面している。サードパーティSaaSの侵害は、ハイパーコネクテッドなビジネス環境において、残念ながら避けられない現実となっている。しかし、明確な対応計画と可視性およびモニタリングへの積極的な投資により、セキュリティリーダーはリスクを大幅に軽減し、組織と信頼を寄せる顧客の両方を保護することができる。
