Twilio と、成功した一人の従業員フィッシングがもたらす顧客データ乗数効果

まとめ

• 確認:Twilio は、攻撃者が現職および元従業員に数百件の SMS フィッシングメッセージを送信し、偽のサインインページで認証情報を取得し、侵害された従業員の ID を利用して内部管理ツールやアプリケーションにアクセスしたと結論付けました。最後に観測された不正アクティビティは2022年8月9日でした。Twilio は最終的に209の影響を受けた顧客アカウントと93の影響を受けた Authy エンドユーザーアカウントを数えました。
• 下流への影響:209という数字はエンドユーザーの合計ではありません。影響を受けた顧客の一つである Signal は、攻撃者が登録ステータスを学習したり SMS 登録コードを閲覧した可能性のある約1,900の電話番号を特定しました。明示的に検索された3つのアカウントのうち1つは再登録が報告されました。サービスチェーンにおける Twilio の位置が、少数の従業員侵害の結果を増幅させました。
• コントロールの発見:攻撃者は暗号化を破ったり Twilio の顧客の API キーを盗む必要はありませんでした。従業員を騙して偽装サイトに認証させ、その権限を利用したのです。トレーニングや迅速なテイクダウンも重要ですが、決定的なコントロールは、間違ったサイトに対して再利用可能な回答を生成しない認証と、限定された管理権限および短いセッションの組み合わせです。
• 説明責任:攻撃者は偽装と不正アクセスに対して責任があります。Twilio は従業員認証、内部ツール、顧客データ範囲、セッションライフ、検知、顧客通知を管理していました。顧客は、下流の ID がどの程度 Twilio に依存するか、そして登録周りにどのような独立した保護策を講じるかを管理していました。通信事業者、レジストラ、ホスティングプロバイダー、ID ベンダーは、キャンペーンの再生可能なインフラの一部を管理していました。責任はチェーン全体で共有されていますが、平等でも代替可能でもありません。

小さい顧客数が大きな依存関係を隠すことができる

Twilio の最終的なインシデントレポートは、繰り返しやすく誤解されやすい2つの比率を示しています。27万以上の顧客のうち209、そして約7500万のうち93の Authy ユーザーです。どちらの割合も小さいですが、どちらも影響を受けた Twilio 顧客を通じてデータやアカウントが危険にさらされる可能性のある人々の全人口を説明していません。Twilio の顧客は多くの場合、自社のユーザー向けにサービスを運営する組織です。そのため、侵害された1つの顧客関係には、数千、数百万、または選択的に価値のある一握りの下流 ID が含まれる可能性があります。

Signal がその乗数効果を可視化しました。Signal は Twilio を電話番号確認に使用しており、約1,900のユーザーが自分の番号が Signal に登録されていることが明らかになったか、SMS 登録コードが露出した可能性があると判断しました。攻撃者は明示的に3つの番号を検索し、Signal はそのうちの1つのアカウントが再登録されたとの報告を受けました。Signal は、メッセージ履歴、連絡先リスト、プロフィール情報、ブロックリスト、Signal PIN は Twilio を通じて利用できなかったことを強調しています。これは重要な制限であり、イベントを軽視する理由にはなりません。アクセス期間中、再登録が成功すると、攻撃者は影響を受けた番号として新しい Signal メッセージを送受信できる可能性がありました。Signal は、影響を受ける可能性のある1,900すべてのアカウントの登録を解除し、再登録を要求し、8月15日と16日に SMS でユーザーに通知しました。(Signal のインシデント通知)

209の Twilio 顧客と1,900の可能性のある影響を受けた Signal ユーザーの比較は、SaaS インシデントに複数の分母が必要な理由を示しています。プロバイダーは影響を受けた顧客アカウントを数えなければなりません。各顧客は影響を受けたエンドユーザー、レコード、識別子、トランザクションを数えなければなりません。調査者は、閲覧されたデータと変更されたデータ、露出した登録コードと再登録されたアカウント、可能なアクションと観測されたアクションを区別しなければなりません。これらの状態を単一の合計に圧縮すると、修復に必要な情報が失われます。

Twilio はまた、攻撃者が顧客コンソールの認証情報、認証トークン、API キーにアクセスした証拠はないと述べました。その境界は、サポート可能な主張のセットを大幅に減らします。これは、公開された証拠が、攻撃者がすべての影響を受けた顧客として任意の Twilio API 呼び出しを行えたことを立証するものではないことを意味します。また、アクセスされた管理データが無害であったことを意味するわけでもなく、Signal がサポートシステムで独自に発見したことを無効にするものでもありません。内部ツールは、顧客自身の秘密が無傷のままであっても、運用上決定的な情報を露出する可能性があります。

これがこのケースの決定的なクラウド依存関係です。顧客は通信または確認機能を委任していました。Twilio の従業員はその機能をサポートするために何らかの能力を必要としていました。攻撃は従業員の権限を顧客情報への経路に変換し、Signal の場合、その情報はアカウント登録プロセス内にありました。したがって、プロバイダーの従業員 ID 境界は、顧客がアーキテクチャ図でその依存関係を見ることができるかどうかにかかわらず、顧客の認証境界の一部となりました。

2つのソーシャルエンジニアリングインシデント、そして拡大する調査

最終的な時系列は、当初の8月の開示よりも複雑です。Twilio の調査は、広く報告された SMS キャンペーンを以前のイベントに結び付けました。2022年6月29日、従業員が音声フィッシングにより認証情報を提供しました。侵入者は限られた数の顧客の顧客連絡先情報を入手しました。Twilio は12時間以内にそのアクセスを特定して排除し、7月2日に影響を受けた顧客に通知したと述べています。同社は後に、同じ悪意のある攻撃者が両方のイベントの原因である可能性が高いと結論付けましたが、「可能性が高い」は司法的な帰属ではなく、調査評価のままです。

7月中旬、攻撃者は現職および元 Twilio 従業員に何百ものテキストメッセージを送り始めました。メッセージは IT 部門または管理者を装い、期限切れのパスワード、変更されたスケジュール、またはサインインする別の理由など、一般的な仕事上の不安を利用しました。リンクは Twilio、Okta、SSO などのおなじみの単語を含むドメインと、Twilio の実際のサインイン体験に似せて作られたページに誘導しました。一部の従業員は認証情報を提供しました。その後、攻撃者は内部管理ツールやアプリケーションに侵入し、顧客情報に到達しました。

Twilio は8月4日に不正アクセスを認識しました。8月7日に最初の通知を公開し、当初は限られた数の顧客アカウントを説明していました。公開された数は調査の進行とともに変化しました。初期の更新では約125の顧客が特定されました。8月24日までに Twilio は163の顧客と93の Authy ユーザーを報告しました。10月27日の結論では、最終的な209の顧客と93の Authy ユーザーの数字が示されました。最後に観測された不正活動は8月9日でした。Twilio の統合されたインシデントレポートと調査結論がこのシーケンスの主要ソースです。

変化する数字はそれ自体で初期の声明が欺瞞的であったことを示すものではありません。調査者が ID、セッション、ツール、クエリ、顧客レコードを再構築するにつれて、インシデントの範囲は通常拡大します。説明責任の質問は、すべての数字が定義され日付が付けられているかどうかです。「これまでに特定された顧客」は「最終的な影響を受けた顧客」とは異なります。影響を受けた組織アカウントは個人とは異なります。Authy ユーザーはさらに異なります。Twilio の更新は一般的にその進行を示しましたが、最終的な公開アカウントは依然として、影響を受けた各顧客のデータカテゴリ、アクセスアクション、ダウンストリーム人口を公開していませんでした。

同社の証券報告はいくつかの有用な境界を追加しました。Twilio は、攻撃者が未知のソースから従業員の名前と携帯電話番号を入手したこと、影響を受けた顧客に通知して協力したこと、適切な規制当局に通知して質問に対処したこと、および業界レポートがテクノロジー、通信、暗号通貨組織にわたって活動を配置したことを述べました。同社の2022年第3四半期のForm 10-Qおよびその後の2022 Form 10-Kも209の顧客数を繰り返し、修復を要約しています。

これらの提出書類は、証券法の義務の下で作成された会社の声明です。匿名の報告よりも Twilio が正式に開示したもののより強力な証拠ですが、独立したフォレンジック監査や規制当局のコンプライアンス判断ではありません。この記事でレビューされた公開記録には、インシデントに関する法的責任を割り当てる執行命令は含まれていません。したがって、コントロールと証拠に関する運用判断をサポートしますが、裁判所や規制当局が最終的な過失判断に達したという主張はサポートしません。

従業員は標的であり、完全な根本原因ではない

一部の従業員が偽のページで認証情報を入力したことは事実です。そこで止めると弱い説明になります。ソーシャルエンジニアリングは、正当な仕事がすでに人々にメッセージを読ませ、リンクをたどらせ、スケジュール変更に対応させ、認証させることを利用するように設計されています。攻撃者は従業員が持ち歩くチャネル、雇用主に関連する言語、おなじみの ID プロバイダーを模倣したページを選びました。また、従業員名と電話番号（元スタッフの番号を含む）を結び付けるのに十分な個人マッピングも持っていました。

従業員の行動が侵害になったのは、認証システムが攻撃者が取得したものを受け入れ、その結果のセッションが機密性の高い内部ツールに到達できたからにすぎません。完全なチェーンは、ターゲット獲得、メッセージ配信、リンク信頼、認証情報入力、2要素認証のキャプチャまたは満足、ID プロバイダー受け入れ、アプリケーションセッション作成、管理承認、顧客データアクセス、遅延した失効でした。クリック後のすべての遷移は、組織の管理下にあるマシンまたはポリシーの決定でした。

この区別は、公平性とエンジニアリングの両方にとって重要です。従業員を非難することは、報告が最も価値がある瞬間に過少報告を奨励します。また、認識キャンペーンに資金を向けながら、再利用可能な認証プロトコルをそのままにします。Twilio は確かに補足的な必須トレーニングを追加しましたが、より重要な対応は、FIDO2 セキュリティキーをすべての従業員に配布し、2要素認証の予防策を強化することでした。FIDO 認証器は、その応答を実際のサイトまたは依頼者にバインドします。説得力のある模倣ドメインはまだパスワードを収集できますが、正当なサービスに必要な暗号応答を取得することはできません。

CISA のフィッシング耐性 MFA ガイダンスは、FIDO/WebAuthn を広く利用可能なフィッシング耐性オプションとして特定し、コードを中継するよう人に求める方法と区別しています。NIST の現在の認証ガイダンスは、メカニズムをより正確に説明しています。手動で入力される1回限りの出力は、偽装者が中継できるためフィッシング耐性がありませんが、暗号認証は認証器の出力を検証者またはチャネルにバインドできます。これらの後の標準は、Twilio が2022年7月にすべてのアプリケーションに使用した正確な要素構成を証明するものではありません。それらは、インシデント後に FIDO2 トークンを配布することが、疑わしいリンクに関する別の警告よりも文書化された攻撃経路に直接対処した理由を説明しています。

残りのテストは強制です。キーを所有することは、それらを要求することと同じではありません。リカバリルート、レガシーVPN、管理例外、管理されていないアプリケーション、ヘルプデスクリセット、またはフォールバック要素は、古い攻撃経路を保持する可能性があります。信頼できる修復記録には、フィッシング耐性認証が必須である従業員および特権アプリケーションの割合、請負業者および緊急アカウントの処理、例外の数と期間、フォールバックおよびリカバリプロセスに対する訓練の結果が示されるべきです。

Cloudflare は有益なコントロール比較を提供するが、道徳劇ではない

ほぼ同時期に、Cloudflare の従業員は同様の特性を持つキャンペーンを受けました。2022年7月20日、少なくとも76人の従業員が1分以内に個人用および仕事用の電話にテキストメッセージを受信しました。一部のメッセージは家族に届きました。3人の従業員が認証情報を入力しました。Cloudflare は、攻撃者がその後必要な FIDO2 ハードウェアキーのステップを通過できなかったため、システムは侵害されなかったと報告しました。24時間インシデントチームは、受信者をログインアクティビティと比較し、影響を受けた認証情報とセッションをリセットし、デバイスをスキャンし、インフラをブロックし、他の標的とインテリジェンスを共有しました。(Cloudflare の技術的説明)

この比較は、人間の変数をほぼ一定に保つため有用です。両社の従業員は説得力のある SMS ルアーに遭遇しました。両社の従業員はそれに反応しました。結果はプロトコルと強制の層で分岐しました。Cloudflare のキーは従業員をより人間味のないものにしたわけではありません。それらは、人間の過ちを実際の検証者を満たすのに不十分にしたのです。

Twilio が Cloudflare のアーキテクチャのすべての要素をコピーすべきだった、または1つのコントロールが安全性を保証すると結論付けるのは単純すぎます。Cloudflare の説明は自己報告であり、キャンペーンはすべての詳細で同一であることが証明されたわけではなく、決意のある攻撃者はエンドポイント制御、アカウントリカバリ、セッション盗難、または別の経路を追求する可能性があります。教訓はより狭く、より強力です。顧客データへの管理アクセスを保持するプロバイダーは、現実的なフィッシング訓練の成功を、すべての従業員がルアーを認識するかどうかに主に依存させるべきではありません。

Cloudflare はまた、中央可視性の価値を示しています。正しい盗まれたパスワードを使用したがハードウェアキーの要件を満たさなかった認証試行を特定し、従業員の報告と結び付け、セッションを強制終了し、アクセスログを照会できました。その証拠は、散在するテキストメッセージをキャンペーンに変換しました。Twilio にとって、同等の説明責任の質問は、ID プロバイダーがログを生成したかどうかだけでなく、会社がどの従業員 ID が認証されたか、どの要素が使用されたか、どのアプリケーションがセッションを発行したか、それらのセッションがどの顧客レコードに触れたか、およびすべての関連セッションが失効されたかどうかを迅速に回答できるかどうかです。

0ktapus は単純なインフラをスケーラブルなキャンペーンに変えた

Twilio の最終報告書は、より広範な活動を0ktapus または Scatter Swine と名付けた独立研究者を引用しています。Group-IB のキャンペーン調査では、169のフィッシングドメイン、9,931の侵害された認証情報レコード、5,441の侵害された MFA コード、および136の一意のメールドメインに関連する被害者が見つかりました。調査員は、組織固有の Okta ページを模倣し、ユーザー名、パスワード、コードを収集し、キャプチャした素材を Telegram チャネルに送信する静的フィッシングキットを説明しました。攻撃者は短命のコードを迅速に使用する必要がありましたが、まれなマルウェアや未公開の暗号解読は必要ありませんでした。(Group-IB の0ktapus 分析)

キャンペーンレベルの数字を Twilio の被害者数にインポートすべきではありません。Group-IB のコーパスは多くの組織をカバーし、Twilio の8月の発見より数ヶ月前から始まる期間を含んでいました。これは攻撃者の経済性と一般的な手法に関する証拠であり、データセット内のすべての認証情報が使用されたことや、リストされたすべての組織が同じ結果を被ったことの証明ではありません。

経済的非対称性は依然として明らかです。攻撃者はドメインを登録し、ログインページをクローンし、ホスティングをレンタルし、メッセージのバーストを送信し、テイクダウン後にインフラを交換できました。Twilio は米国の通信事業者と協力して悪意のあるメッセージを停止し、ホスティングプロバイダーと協力してアカウントを閉鎖したと述べていますが、攻撃者は通信事業者とホストをローテーションし、攻撃を再開しました。各防御行動には、正しいプロバイダーに報告が届き、そのプロセスを満たすのに十分な証拠、決定、実装が必要でした。攻撃者には、別の低コストのアカウントまたはドメインだけが必要でした。

それが悪用連絡先の経済学です。外部の警告を防御行動に変えるための価格と遅延です。価格はフォーム送信だけではありません。責任のあるプロバイダーの発見、証拠のフォーマット、誤検知フィルターの克服、プライバシーの維持、重複報告の相関、法的権限の決定、顧客への通知、悪意のあるリソースが他の場所に戻っていないかの追跡が含まれます。攻撃者は悪用インフラの供給を自動化できます。防御側は多くの場合、報告を孤立したチケットとして処理します。

Twilio の現職および元従業員へのメッセージの説明は、追加の報告問題を提起します。現職の従業員は内部ボタン、チャットチャネル、ホットラインを使用するように訓練できます。元従業員には認証された内部ルートがない場合があります。メッセージを受け取った家族は、どの雇用主が偽装されているか、または証拠を安全に提出する方法を知らない場合があります。成熟したプログラムには、会社に関する不審なメッセージのための公開された、障壁の低いチャネルが必要であり、従業員専用のヘルプデスクだけではありません。

Twilio は現在、セキュリティ脆弱性の報告とメッセージング乱用の報告のための別々のルートを公開しています。最初のルートは研究者、パートナー、ベンダー、顧客、コンサルタントからの報告を受け付けます。2番目のルートは不要な通話やメッセージに関する詳細を収集します。これらは有用な公開面ですが、今日の存在は、2022年7月の従業員スミッシング報告がどのようにルーティングされたか、またはどのくらい迅速にインシデントレスポンダーに届いたかを立証するものではありません。脆弱性、製品乱用、顧客アカウント侵害、従業員フィッシング、アクティブインシデントインテリジェンスは重複しますが、同一のキューではありません。システムはそれらをマージできなければなりません。

RFC 9116は、セキュリティ連絡先を見つけることがそれ自体遅延の原因であるため、部分的にsecurity.txtを標準化しました。これはサイトに、報告チャネルと開示ポリシーを公開するための予測可能な機械可読の場所を提供します。(RFC 9116) 連絡先ファイルは報告を調査できず、ウェブフォームは通信事業者やレジストラに強制できません。それらの価値は、調整を開始する固定費を下げることです。より強力な指標は、受け入れ後の対応です。確認時間、アナリスト割り当て、クロスレポート相関、エスカレーションしきい値、テイクダウン時間、再発追跡、報告者へのフィードバックです。

サポートコンソールは Signal の認証システムの一部だった

Signal の通知は、フィッシングを通じて到達されたシステムとして Twilio のカスタマーサポートコンソールを特定しています。この詳細は、サポートツールがしばしば運用上の便利さとして扱われ、本番セキュリティ境界としては扱われないため重要です。サポート担当者は、正当な問題を解決するために配信ステータス、電話番号、確認イベント、またはアカウント設定を検査する必要がある場合があります。同じ可視性は、攻撃者が登録されたアカウントを特定したり、瞬間的なコードを傍受したりするのに役立ちます。

したがって、Twilio の最終報告書の「非本番システム」というフレーズは注意深く解釈されるべきです。ツールはライブトラフィックを送信したり、顧客のアプリケーションをホストしたりする必要はなく、本番 ID の決定に影響を与える可能性があります。本番通信によって生成されたデータを表示したり、顧客レコードの検索を許可したり、オペレーターが状態を変更するのを助けたりする場合、それはサービスの実効的な信頼境界内に属します。サポート、バックオフィス、非本番などのラベルは、そこで利用可能な権限の機密性を低下させません。

正しい設計の質問は、サポートスタッフがゼロアクセスであるべきかどうかではありません。通信プラットフォームは、証拠なしに配信やアカウントの問題を調査できません。質問は、デフォルトでどのくらいのデータが表示されるか、どのフィールドに昇格が必要か、特に機密性の高い検索に理由や承認が必要か、アクセスがテナントにどのようにスコープされるか、バルククエリがどのように制約されるか、顧客がプロバイダー従業員が自社のアカウントにアクセスしたことを確認できるかです。

Twilio の現在のMonitor Events ドキュメントは、API、コンソールユーザー、さらには Twilio 従業員によって行われた変更のイベントレコードを説明しています。イベントには、アクタータイプ、ソース、送信元 IP、リソース、イベントデータが含まれる場合があります。保持期間はアカウントパッケージによって異なります。これは、顧客が現在意味のあるプラットフォームアクティビティレコードを取得できる証拠ですが、Signal に関連する2022年のサポートコンソールビューがすべてその製品の下で顧客に見えるか保持されたことの証明ではありません。インシデントは、監査範囲に設定変更だけでなく、読み取りアクセスと検索を含めるべき理由を強調しています。

プロバイダーをアカウントリカバリや確認に統合する顧客は、正確なサポートアクセスモデルを尋ねるべきです。プロバイダー従業員はライブのワンタイムコードを表示できますか？番号が登録されているかどうかを明らかにできますか？そのアクセスは明示的に昇格されるまでマスクされていますか？昇格は期限切れになりますか？高リスクアカウントを含む対象ルックアップには2人目の人物が必要ですか？顧客はほぼリアルタイムのイベントを受け取りますか？プロバイダーは顧客自身の通知期限に十分な期間それらのレコードを保持できますか？これらの質問は、すべての Twilio 製品が同じデータを露出することを前提とせずに、Signal の影響から直接従います。

Authy は第二の形の下流権限を示した

影響を受けた93の Authy ユーザーは異なる境界に属していました。Twilio は、攻撃者がこれらのアカウントに追加のデバイスを登録し、その後不正なデバイスを削除してユーザーに連絡したと報告しました。同社はユーザーに、リンクされたアカウントを検査し、デバイスを確認し、見慣れないものを削除し、バックアップデバイスを確立した後にマルチデバイス機能を無効にするようアドバイスしました。

これは単なる連絡先データの露出ではありませんでした。Authy デバイスを追加すると、アカウント設定とリンクされたサービスの保護手段に応じて、攻撃者にリンクされたサービスの時間ベースの認証コードへの継続的なルートが与えられる可能性がありました。Twilio のリンクされたアカウントを検査するガイダンスはその可能性を反映していました。公開報告書は、93人のユーザー全員がリンクされたサービスで侵害を被ったとは述べていないため、正しい状態は「不正デバイスが登録された」であり、その後顧客固有の調査が続きます。

Signal と Authy は一緒に、2種類のクラウドサービス増幅を示しています。Signal の場合、通信プロバイダーのサポートビューがダウンストリームサービスの登録フローと交差しました。Authy の場合、ID 製品のデバイス登録メカニズムが、攻撃者の認証機能を他のアカウントに拡張する可能性がありました。どちらの害も、Twilio の顧客組織のみを数えることではうまく測定されません。

また、プロバイダーの侵害を封じ込める設計の価値を示しています。Signal のサーバーは、Twilio 攻撃者が取得できるメッセージ履歴、連絡先、プロフィールデータを保持していませんでした。Signal PIN と登録ロックは、SMS コードの所有を超えた別の境界を提供しましたが、登録ロックはオプションであり、Signal はユーザーに有効化を促しました。サービスは依然として機密ステップを Twilio に依存していましたが、そのアーキテクチャはその依存関係が明らかにできるものを制限しました。クラウド依存関係はめったに排除されません。狭くすることはできます。

データ最小化は管理ビューに適用されなければならない

プロバイダーはしばしば、データベース保持の観点からデータ最小化を説明します。このイベントは別の次元を追加します。表示の最小化です。フィールドは配信、不正防止、請求、トラブルシューティングのために正当に保持される可能性がありますが、すべてのサポート ID に完全に表示される必要はありません。インターフェースは、マスクされた番号、配信結果、一方向の確認状態を、完全な秘密や関連するすべてのレコードを表示せずに明らかにできます。

インシデントレポートは、影響を受けた各 Twilio 顧客が何を失ったかのフィールド別の説明を公開しませんでした。その omission は、顧客の機密性、調査の限界、または製品とサポートビューの多様性を反映している可能性があります。それでも、保証のギャップを生み出します。顧客は Twilio の総数から自分たちの露出を推測できず、外部の読者はアクセスが適切に最小化されたかどうかをテストできません。

説明責任のあるプロバイダーは、従業員 ID、アプリケーション、セッション、タイムスタンプ、クエリまたはオブジェクト、表示されたフィールド、エクスポート、変更、信頼レベルを含む顧客別の証拠パッケージを構築できるべきです。顧客はプロバイダーの証拠を自社のユーザーと義務にマッピングできます。正確なログが利用できない場合、プロバイダーはそう述べ、欠落したテレメトリを静かに「影響なし」に変換するのではなく、保守的な影響を受けた人口を採用すべきです。

現在の Twilio のドキュメントは、制限付き API キーとより広範な認証情報を区別し、利用可能な最小限の特定のアクセスを使用することを推奨しています。(Twilio API キー概要) その最小権限の原則は、顧客 API クライアントと同じくらい強力に人間のサポートツールを統治すべきです。1回のフィッシュされたログインの後、内部の汎用サポート ID がすべてのテナントとすべての機密フィールドを表示できる場合、狭い顧客キーはデータを保護するのにほとんど役立ちません。

管理設計は、観察とアクションも分離するべきです。メッセージステータスの参照、アカウント設定の変更、認証情報の作成、デバイスの登録、ワンタイムコードの表示は異なる結果をもたらします。それらは異なる承認要件と紛れもない監査イベントを生成するべきです。高リスクアクションには、最近のフィッシング耐性再認証、管理デバイスのポスチャ、顧客承認のサポートセッション、またはデュアルコントロールが必要になる場合があります。目的はサポートを使用不能にすることではありません。従業員の侵害が顧客インシデントになる前に期限切れになるようにすることです。

通知は分散型インシデントレスポンスコントロールである

Twilio は影響を受けた顧客組織に個別に通知しました。その後、それらの顧客は自社のどのユーザーが影響を受けたか、データがどの状態を表しているか、どの防御行動が適切かを判断する必要がありました。Signal は、約1,900の番号を特定し、3つのアクティビティを検索し、1つの再登録報告を得るのに十分な情報を受け取ったため、行動できました。8月4日に Twilio が不正アクセスを検出してから11日後の8月15日までに直接通知を開始し、翌日プロセスを完了しました。

このシーケンスは、プロバイダーの通知が「あなたのアカウントが影響を受けました」だけでは構成できない理由を示しています。ダウンストリーム組織には、共通のタイムゾーンのタイムスタンプ、アクセスされたデータフィールド、マッチングに適した識別子、実行されたアクション、セッション境界、信頼度、封じ込めステータス、継続的な指標が必要です。また、パッケージを安全に受け取る方法も必要です。曖昧または遅延した通知は、調査コストを顧客に転嫁し、顧客自身の法的または契約上の期限を守れなくする可能性があります。

連邦取引委員会のデータ漏洩対応ガイドは、他者のデータを保存する企業に影響を受けた企業に通知するよう指示し、サービスプロバイダーが実際に脆弱性を修正したことを確認するよう組織にアドバイスしています。また、調査の文書化、証拠の保存、関係する情報と人口の確認、人々が自分自身を保護するのに役立つ詳細の提供を強調しています。このガイドは Twilio の執行判断ではありませんが、プロバイダーチェーンに関連する運用基準を捉えています。

NIST の現在のインシデントレスポンス推奨事項は、インシデント対応を準備、検知、対応、復旧、改善にわたって配置し、確認後に始まるセキュリティチームのイベントとして扱うのではありません。クラウドプロバイダーにとって、顧客コミュニケーションはその運用モデル内に属します。通知品質は、インシデント前にサンプルテナント固有の証拠パッケージを生成し、顧客がそれに基づいて行動できるかテストすることによって事前に訓練されるべきです。

Twilio の現在のデータ保護追補は、対象となるセキュリティインシデントを過度の遅延なく顧客に通知し、顧客が当局またはデータ主体に通知する際に合理的な支援を提供すると述べています。また、機密監査報告書と設定に関する顧客責任について説明しています。リンクされたバージョンは2026年に更新されたため、2022年のすべての顧客の正確な契約として遡って読むべきではありません。これは、通知、支援、監査、共有責任が現在どのように割り当てられているかの現在の声明として有用です。実際の権利は、各顧客に適用される契約と法律に依存します。

修復は侵入経路に対処したが、証明は不完全なまま

Twilio は4つの即時根絶措置を報告しました。侵害された従業員の認証情報のリセット、侵害された Okta 統合アプリケーションに関連するアクティブセッションの失効、既知の指標のブロック、偽の Twilio ドメインのテイクダウンの要請です。その後、5つの長期的措置を挙げました。すべての従業員に対するより強力な2要素予防策と FIDO2 トークン、追加の VPN コントロール、管理ツールの機能の削除または制限、Okta 統合アプリケーションのトークンリフレッシュの頻度向上、補足的な必須トレーニングです。

これは実質的に具体的な修復リストです。単に「セキュリティを真剣に受け止める」と約束するのではなく、攻撃の複数の段階に対応しています。FIDO2 は検証者の偽装に対処します。短いトークンライフは、認証情報やセッション侵害の後の有用なウィンドウを減らします。VPN コントロールは別のポリシー境界を追加します。管理機能の制限は爆発半径を減らします。トレーニングと勧告は認識と報告を改善します。

このリストはまた、顧客が次に何を尋ねるべきかを明らかにしています。FIDO2 は、フィッシュ不可のリカバリを含め、すべての従業員および特権認証に必須になりましたか？セッション失効は、ID プロバイダーセッションだけでなく、アプリケーションセッションを確実に無効にしましたか？どの管理機能が削除され、どれが単に非表示にされ、どのような承認が現在それらを管理していますか？リフレッシュされたトークンはどのくらい短く、インシデントチームは数分以内にグローバルに失効できますか？元従業員の番号は内部ディレクトリと対象警告プログラムから削除されましたが、彼らが偽装を報告する経路は維持されましたか？

Twilio は、強化から即時のメリットを見ていると述べました。公開報告書はそれらのメリットを指標で定義したり、運用効果の独立した評価を提供したりしませんでした。同社の現在のセキュリティ概要は、セキュリティインシデント対応チーム、アクセスコントロール、テスト、認証、その他のプログラム要素を説明しています。Twilio トラストセンターは、SOC 2レポートなどの保証文書への制御されたアクセスを提供しています。これらのソースは顧客が現在デューデリジェンスを行うのに役立つかもしれませんが、現在の認証は2022年7月のコントロールに対するフォレンジック評決として扱われるべきではありません。監査範囲、期間、テスト基準、例外、補完的な顧客コントロールがすべて重要です。

信頼できる公開修復スコアカードは、結果を公開しながら機密詳細を保護する可能性があります：

公開証拠の欠如は、コントロールが存在しないことの証明ではありません。それは、保証を実装とは別に評価する理由です。Twilio は、エンタープライズ顧客や監査人に、安全に公開できない機密証拠を提供する可能性があります。調達チームはそれを要求すべきです。公開説明責任は、顧客のアイデンティティや防御上の秘密を明らかにしない集約的なカバレッジとパフォーマンス測定を通じて向上することができます。

顧客には責任があったが、Twilio の従業員に対するコントロールはなかった

共有責任は、クラウドインシデントの後に、境界を曖昧にする方法でしばしば引き合いに出されます。Twilio の顧客は、アプリケーション設計、ローカル認証情報、ユーザー通知、およびサービスを通じて送信することを選択したデータの機密性に対して責任がありました。彼らは Twilio の従業員認証器を選択せず、どのサポートフィールドが表示されるかを決定せず、内部 VPN を設定せず、侵害された従業員セッションを失効させませんでした。これらはプロバイダーのコントロールでした。

顧客はそれでもプロバイダーの障害の結果を減らすことができました。登録に SMS を使用するサービスは、アプリケーション固有の PIN を追加し、高リスクのアカウント変更を遅延させ、既存のデバイスに通知し、再登録を検出し、機密ユーザーに対してより強力なリカバリ経路を要求できます。メッセージコンテンツに配置されるデータを最小限に抑え、通信イベントを唯一の ID 証明として使用することを避け、サインアップとリカバリに関与するすべての外部プロバイダーをマッピングできます。

Twilio の顧客はまた、プロジェクトと認証情報を分離し、制限付き API キーを使用し、露出したシークレットをローテーションし、プラットフォームイベントをエクスポートできます。同社の不正防止開発者ガイドは、顧客側の乱用に対する使用トリガー、地理的制限、サブアカウント、迅速なキーローテーションを推奨しています。これらのコントロールは主に顧客自身のアカウントの侵害や不正を対象としており、Twilio 従業員が内部ツールを閲覧することではありません。それでも、隣接する爆発半径を減らし、侵入者がデータアクセスからトラフィック生成に移行した場合に顧客に独立したシグナルを提供します。

エンタープライズ依存関係レビューは、ベンダー名ではなく機能を追跡すべきです。「Twilio を使用しています」は広すぎます。あるチームはプログラマブルボイスを使用し、別のチームは SMS アラート、別のチームはワンタイム確認、別のチームはカスタマーサポート、さらに別のチームは Authy を使用する場合があります。各機能には異なる保存データ、サポートアクセス、障害動作、ユーザー救済策があります。調達は、各使用に対するデータフローと権限マップを要求すべきです。

NIST のサイバーセキュリティサプライチェーンリスク管理クイックスタートガイドは、テクノロジーサービスプロバイダーをサプライチェーンの一部として扱い、サプライヤーリスクを一度きりの調達ではなくガバナンスに結び付けています。ここに適用すると、顧客はプロバイダー依存関係をインベントリし、重要な機能とデータを特定し、インシデント通知要件を設定し、保証証拠を取得し、代替案を計画すべきです。これは一般的な違反条項を追加するよりも要求が厳しいですが、クラウド関係を管理可能にします。

Twilio チェーンの説明責任の割り当て

攻撃者は従業員を選択し、電話番号マッピングを取得し、内部システムを偽装し、認証情報とコードを収穫し、無許可でシステムに侵入し、顧客データを検索しました。攻撃に対する彼らの責任は直接的です。キャンペーンを組織的または系統的と説明することは能力を説明します。それはいかなるコントロール所有者も免責しません。

Twilio のセキュリティおよび ID チームは、認証プロトコル、ID プロバイダーポリシー、セッションライフサイクル、VPN、監視、インシデント相関、失効メカニズムを管理しました。彼らは、盗まれた従業員の秘密を不十分にし、異常なアクセスを検出し、すべての派生セッションを遮断する責任がありました。

Twilio の製品およびサポートリーダーは、管理ツールが表示し許可するものを管理しました。彼らは、テナント境界、データマスキング、昇格、読み取りログ、機密アクション、およびカスタマーサポートがより少ない常設権限で機能できるかどうかに責任がありました。

Twilio の経営陣と取締役会の監督者は、投資、リスク受容、保証、報告に関するインセンティブを管理しました。彼らの任務は、従業員が決してクリックしないことを保証することではありませんでした。クリックが広範な顧客権限を解除できず、インシデントが迅速に再構築され伝達されるという証拠を要求することでした。

影響を受けた顧客は、ダウンストリームアプリケーションアーキテクチャとユーザー対応を管理しました。Signal のアカウントは責任ある封じ込めを示しています。プロバイダーデータをユーザーにマッピングし、露出したものとされなかったものの境界を設定し、再登録を強制し、ユーザーに通知し、登録ロックを促進しました。他の顧客の義務は、データと製品の使用に依存していました。

ID、通信事業者、ホスティング、レジストラ、プラットフォーム仲介者は、攻撃インフラの一部を管理しました。迅速な行動はキャンペーンを短縮できましたが、孤立したテイクダウンは敵対者のローテーション能力を解決できませんでした。これらのプロバイダーは、無関係な乱用チケットのシーケンスではなく、相互運用可能な証拠、信頼できるエスカレーション連絡先、再発分析を必要としていました。

規制当局および公的機関は、通知の受信、法律が重複する場合の調整、支持された違反の調査、法的に可能な場合の重要な調査結果の公開に責任がありました。Twilio は適切な規制当局に通知し、質問に回答したと述べています。レビューされた公開記録には、このインシデントに固有の最終的な公開規制命令は示されていないため、規制承認または証明された違反のいずれかを主張するために使用することはできません。

公開記録がまだ答えられないこと

最も強力な説明責任分析は、自信を持った言葉で埋めるのではなく、未知のものをマークします。Twilio は、従業員の電話番号がどのように収集されたかを公に特定していません。Group-IB は、通信組織への初期の標的化がいくつかの番号を提供した可能性があると示唆しましたが、それは証明された Twilio 固有の情報源ではなく、キャンペーンの仮説です。

公開記録は、何人の従業員が認証情報を入力したか、影響を受けた各アカウントがどの要素を使用したか、攻撃者がワンタイムコードをリアルタイムでキャプチャしたかどうか、または何らかのリカバリ経路が関与したかどうかを述べていません。最初の成功した認証から8月9日までのセッション別のタイムラインを提供していません。

到達した内部ツールの完全なセット、各従業員 ID の権限、または表示されたフィールドとアクションの顧客別リストを公開していません。Signal は自社の人口の詳細を提供していますが、その詳細を他の208の顧客に一般化すべきではありません。

影響を受けたすべての顧客が下流通知を完了するのに十分な情報を受け取ったかどうか、各顧客がどのくらい迅速に通知されたか、またはインシデント全体で最終的に連絡された個々のエンドユーザーの数を示していません。209という数字は個人の人口に変換できません。

完了した FIDO2 ロールアウト、フォールバックパス、トークン失効、VPN 制限、管理ツール削減の独立した公開テストを提供していません。後の保証文書は一部のコントロールを機密にカバーする可能性がありますが、その範囲と例外は想定ではなくレビューされる必要があります。

最後に、Twilio プラットフォームの停止があったこと、攻撃者がすべての影響を受けた顧客のメッセージコンテンツにアクセスしたこと、顧客 API キーが盗まれたこと、または露出した可能性のあるすべての Signal ユーザーが再登録されたことを立証していません。それらの主張は証拠を超えるでしょう。

永続的なテストは、1つの信頼できるメッセージがどれだけの権限を購入できるかである

Twilio のインシデントは、顧客のごく一部に影響を与えた SMS フィッシュとして要約されることがあります。その説明は算数的には防御可能ですが、運用上は不完全です。重要な単位は顧客アカウントのパーセンテージではありませんでした。従業員が間違った場所に認証した後に利用可能なダウンストリーム権限の量でした。

ある顧客の場合、結果として得られたアクセスは、約1,900人の可能性のある影響を受けた人々が使用する電話番号登録プロセスに触れました。93の Authy ユーザーの場合、認証製品に不正デバイスが追加されました。より広範なキャンペーン全体で、安価なドメイン、クローンページ、テキストメッセージ、迅速に中継されたコードが100以上の組織に到達しました。攻撃者は別の連絡先ポイントを作成するためにほとんど費やしませんでした。防御側は、特定、報告、検証、無効化、調査、通知、証明のために繰り返し支払いました。

Twilio の発表された対応は、正しい技術的方向に動きました。FIDO2 キーは認証の前提を変えました。短いセッションとより広範な失効は時間を制約しました。削減された管理機能は権限を制約しました。トレーニング、公開報告ルート、調整されたテイクダウンは、人間とプロバイダー間の層を改善しました。これらの対策は、一般的な謝罪よりも多くの重みに値します。

しかし、説明責任は展開で終わりません。顧客は、フィッシング耐性認証が弱いフォールバックなしに強制されていること、サポートツールがタスクに必要なものだけを明らかにすること、すべての機密読み取りが attributable であること、疑わしいセッションがアプリケーション全体で失効できること、顧客固有のインシデント証拠が顧客の通知義務よりも速く動くことができることの証拠を必要とします。取締役会は、カバレッジ、例外、訓練、応答時間の測定を必要とします。規制当局は、不幸なクリックと不合理なコントロール設計を区別するのに十分な事実を必要とします。

永続的な教訓は、人々を信頼できないとか、クラウドコミュニケーションが特別に安全でないということではありません。クラウドプロバイダーへの信頼には、プロバイダーの従業員、管理インターフェース、ID プロトコル、悪用連絡先、通知機構が含まれるということです。信頼できるメッセージは、いつか誰かに悪い瞬間に届くでしょう。説明責任のあるシステムは、メッセージがほとんど何も購入せず、即座のシグナルを生成し、影響を受けるすべての顧客が使用できる記録を残すように設計されたシステムです。