Twilio と、成功した従業員フィッシングの背後にある顧客データ増幅効果

概要

• 確認済み:Twilio は、攻撃者が数百件の SMS フィッシングメッセージを現職および元従業員に送信し、模倣したログインページで認証情報を取得し、侵害された従業員の身元情報を使って内部の管理ツールやアプリケーションに侵入したと結論付けました。確認された最後の不正アクセスは 2022 年 8 月 9 日でした。Twilio は最終的に、影響を受けた顧客アカウントを 209 件、Authy エンドユーザーアカウントを 93 件カウントしました。
• 下流への影響:209 という数字はエンドユーザーの総数ではありません。影響を受けた顧客の 1 つである Signal は、攻撃者が登録状況を把握したり SMS 登録コードを閲覧した可能性のある電話番号が約 1,900 件あったと特定しました。明示的に検索された 3 件のアカウントのうち 1 件は再登録されたと報告されています。サービスチェーンにおける Twilio の立場によって、少数の従業員アカウント侵害がもたらす影響が拡大されました。
• コントロールに関する所見:攻撃者は暗号を破ったり、Twilio の顧客の API キーを盗んだりする必要はありませんでした。従業員を説得してなりすましサイトで認証させ、得られた権限を利用したのです。トレーニングや迅速なテイクダウンも重要ですが、決定的なコントロールは、偽サイトに対して再利用可能な応答を生成しない認証と、狭い管理権限、短いセッションの組み合わせです。
• 説明責任:攻撃者は欺き行為と不正アクセスに対して責任を負います。Twilio は従業員の認証、内部ツール、顧客データの範囲、セッションの有効期間、検知、顧客通知を管理していました。顧客は、下流のアイデンティティが Twilio にどの程度依存しているか、登録プロセスにどのような独自のセーフガードを設けるかを管理していました。通信事業者、レジストラ、ホスティングプロバイダー、アイデンティティベンダーは、攻撃キャンペーンの再利用可能なインフラの一部を管理していました。責任はチェーン全体で共有されますが、それは平等でも交換可能でもありません。

少数の顧客数は大きな依存関係を隠す可能性がある

Twilio の最終インシデントレポートは、繰り返しやすいが誤解しやすい 2 つの比率を示しています。27 万以上の顧客のうち 209 件、約 7,500 万人の Authy ユーザーのうち 93 件です。どちらも小さな割合です。しかし、どちらの数字も、影響を受けた Twilio 顧客を通じてデータやアカウントが危険にさらされる可能性のある全体の人数を表しているわけではありません。Twilio の顧客は、多くの場合、独自のユーザーにサービスを提供する組織です。したがって、1 つの顧客関係の侵害には、数千、数百万、あるいは選別された少数の下流アイデンティティが含まれる可能性があります。

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 のケースではその情報がアカウント登録プロセスの中にありました。したがって、プロバイダーの従業員アイデンティティ境界は、顧客がアーキテクチャ図でその依存関係を認識できるかどうかにかかわらず、顧客の認証境界の一部になりました。

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 件とし、Authy ユーザー93 人は維持されました。最後に観測された不正アクティビティは 8 月 9 日でした。この一連の流れの主な情報源は、Twilio の統合インシデントレポートと調査結論です。

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

同社の証券報告書は、いくつかの有用な境界線を追加しました。Twilio は、攻撃者が従業員の氏名と携帯電話番号を未知の情報源から入手したこと、影響を受けた顧客に通知し協力したこと、適切な規制当局に通知し質問に回答したこと、そして業界レポートがテクノロジー、通信、暗号通貨関連の組織にわたる活動を示していると述べました。その第 3 四半期2022 年 Form 10-Qとその後の2022 年 Form 10-Kでも、209 件の顧客数が繰り返され、是正措置が要約されています。

これらの提出書類は、証券法上の義務に基づいて作成された企業声明です。匿名の報道よりも、Twilio が正式に開示した内容の強力な証拠となりますが、独立したフォレンジック監査や規制当局によるコンプライアンスの認定ではありません。本記事のために検討した公開記録には、このインシデントに関する法的責任を配分する執行命令は含まれていません。したがって、この調査は管理と証拠に関する運用上の判断を裏付けるものであり、裁判所や規制当局が最終的に過失の判断を下したという主張を支持するものではありません。

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

一部の従業員が偽のページに認証情報を入力したのは事実です。しかし、そこで思考を止めると弱い説明になります。ソーシャルエンジニアリングは、正規の業務がすでに人々にメッセージの読み取り、リンクのフォロー、スケジュール変更への対応、認証の実行を求めているという事実を悪用するよう設計されています。攻撃者は従業員が携帯するチャネル、雇用主に関連する言葉遣い、使い慣れたアイデンティティプロバイダーを模倣したページを選択しました。また、攻撃者は従業員の氏名と電話番号を関連付ける十分な個人マッピングを持っており、その中には元従業員の番号も含まれていました。

従業員の行動が侵害となったのは、認証システムが攻撃者の取得した情報を受け入れ、その結果のセッションが機密性の高い内部ツールに到達できたからにすぎません。完全な連鎖は次のとおりです。標的の特定、メッセージ配信、リンクの信頼、認証情報の入力、第 2 要素の取得または満足、アイデンティティプロバイダーによる受諾、アプリケーションセッションの作成、管理権限の付与、顧客データへのアクセス、そして遅延した失効。クリック後のすべての遷移は、組織の管理下にある機械やポリシーの決定でした。

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

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

残るテストは施行です。キーを所有することと要求することは同じではありません。回復ルート、レガシーVPN、管理例外、管理対象外のアプリケーション、ヘルプデスクのリセット、または代替要素が、古い攻撃経路を保存する可能性があります。信頼できる修復記録は、フィッシング耐性認証が必須とされる従業員および特権アプリケーションの割合、コントラクターや非常用アカウントの扱い、例外の数と期間、および代替・回復プロセスに対する演習の結果を示すでしょう。

Cloudflare は教訓劇ではなく、有益なコントロール比較を提供する

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

この比較は、人間の変数をほぼ一定に保っているため有用です。両社の従業員は説得力のある SMS のルアーに遭遇し、両社の従業員がそれに反応しました。結果はプロトコルと施行の層で分かれたのです。Cloudflare のキーは、従業員の人間性を減じたわけではありません。人間のミスを、本物の検証者を満足させるには不十分なものにしたのです。

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

Cloudflare はまた、中央の可視性の価値を示しています。同社は、正しい盗難パスワードを使用したがハードウェアキー要件に失敗した認証試行を特定し、それを従業員の報告と関連付け、セッションを強制終了し、アクセスログを照会できました。その証拠は、散在するテキストメッセージをキャンペーンに変換しました。Twilio にとって、同等の説明責任の問題は、アイデンティティプロバイダーがログを生成したかどうかだけでなく、同社がどの従業員 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 は現在、セキュリティ脆弱性の報告とメッセージング乱用の報告について、別々のルートを公開しています。前者は研究者、パートナー、ベンダー、顧客、コンサルタントからの報告を受け付け、後者は迷惑な通話やメッセージに関する詳細を収集します。これらは有用な公開窓口ですが、現在の存在は、2022 年 7 月の従業員のスミッシング報告がどのようにルーティングされたか、またはインシデント対応者にどれだけ迅速に到達したかを立証するものではありません。脆弱性、製品の乱用、顧客アカウントの侵害、従業員フィッシング、アクティブなインシデントインテリジェンスは重複しますが、同一のキューではありません。システムはそれらをマージできなければなりません。

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

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

Signal の通知は、フィッシングによって到達されたシステムとして Twilio の顧客サポートコンソールを特定しています。この詳細が重要なのは、サポートツールがしばしば本番環境のセキュリティ境界ではなく、運用上の利便性として扱われるからです。サポート担当者は、配信状況、電話番号、認証イベント、またはアカウント設定を調べて、正当な問題を解決する必要があるかもしれません。同じ可視性が、攻撃者が登録済みアカウントを特定したり、一瞬のコードを傍受するのに役立つ可能性があります。

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

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

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

アカウントリカバリや認証にプロバイダーを統合する顧客は、正確なサポートアクセスモデルを要求すべきです。プロバイダーの従業員はライブのワンタイムコードを表示できますか？番号が登録されているかを明らかにできますか？そのアクセスは明示的に昇格されるまでマスキングされていますか？昇格には有効期限がありますか？高リスクアカウントに関わるターゲット検索にはもう一人の担当者が必要ですか？顧客はほぼリアルタイムのイベントを受け取れますか？プロバイダーは、顧客自身の通知期限に間に合うようにそれらの記録を十分に長く保持できますか？これらの質問は、Signal の影響から直接導かれ、すべての Twilio 製品が同じデータを露出しているとは想定していません。

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

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

これは単なる連絡先データの暴露ではありませんでした。Authy デバイスの追加は、アカウント設定やリンクされたサービスのセーフガードに応じて、攻撃者にリンクされたサービスの時間ベースの認証コードへの継続的な経路を与える可能性がありました。リンクされたアカウントを調査するよう Twilio がガイダンスを出したことは、その可能性を反映しています。公開レポートは、93 人の全ユーザーがリンクされたサービスで侵害されたとは述べておらず、したがって正しい状態は「不正デバイスが登録された」であり、その後の顧客固有の調査が必要です。

Signal と Authy は、クラウドサービスの増幅の 2 つの種類を合わせて示しています。Signal のケースでは、通信プロバイダーのサポートビューが下流のサービスの登録フローと交差しました。Authy のケースでは、アイデンティティ製品のデバイス登録メカニズムが、攻撃者の認証機能を他のアカウントに拡張する可能性がありました。どちらの被害も、Twilio の顧客組織の数だけで適切に測定できるものではありません。

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

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

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

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

説明責任を果たせるプロバイダーは、従業員 ID、アプリケーション、セッション、タイムスタンプ、クエリまたはオブジェクト、提示されたフィールド、エクスポート、変更、信頼度を含む、顧客ごとの証拠パッケージを構築できるべきです。顧客はその後、プロバイダーの証拠を自身のユーザーと義務にマッピングできます。正確なログが利用できない場合、プロバイダーはその旨を述べ、欠落したテレメトリーを密かに「影響なし」に変換するのではなく、控えめに影響を受けた集団を採用すべきです。

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

管理設計はまた、観察と行動を分離すべきです。メッセージステータスの確認、アカウント設定の変更、認証情報の作成、デバイスの登録、ワンタイムコードの表示は、異なる結果をもたらします。それらは異なる認可要件と明白な監査イベントを生成すべきです。高リスクの行動は、最近のフィッシング耐性再認証、管理対象デバイスの姿勢、顧客承認済みサポートセッション、またはデュアルコントロールを必要とするかもしれません。目的はサポートを使えなくすることではありません。従業員の侵害が顧客インシデントになる前に期限切れにすることです。

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

Twilio は影響を受けた顧客組織に個別に通知しました。それらの顧客は、次に、自身のユーザーのうち誰が影響を受けたか、データがどのような状態を表しているか、どの保護措置が相応かを判断しなければなりませんでした。Signal が行動できたのは、約 1,900 の番号を特定し、3 つの番号の検索アクティビティ、1 つの再登録報告のための情報を十分に受け取ったからです。同社は、Twilio が不正アクセスを検知してから 11 日後の 8 月 15 日までに直接通知を開始し、翌日にプロセスを完了しました。

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

連邦取引委員会のデータ侵害対応ガイドは、他者のデータを保管する事業者が影響を受けた事業者に通知することを義務付け、サービスプロバイダーが実際に脆弱性を修正したことを確認するよう組織に助言しています。また、調査の文書化、証拠の保持、関与する情報と集団の検証、人々が自身を保護するのに役立つ詳細の提供を強調しています。このガイドは Twilio の執行結果ではありませんが、プロバイダーチェーンに関連する運用基準を捉えています。

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

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

修復は侵入経路に対処したが、証明は依然不完全である

Twilio は 4 つの即時根絶措置を報告しました：侵害された従業員の認証情報のリセット、侵害された Okta 統合アプリケーションに関連するアクティブセッションの無効化、既知のインジケーターのブロック、偽の Twilio ドメインのテイクダウン要求です。次に、5 つの長期的対策を列挙しました：すべての従業員に対するより強力な 2 要素認証予防策と FIDO2 トークン、追加の VPN 制御、管理ツールにおける機能の削除または制限、Okta 統合アプリケーションのより頻繁なトークン更新、補足的な必須トレーニングです。

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

このリストはまた、顧客が次に何を問うべきかを露呈しています。FIDO2 は、非フィッシング可能な回復手段を伴って、すべての従業員および特権認証に対して必須になりましたか？セッションの無効化は、アイデンティティプロバイダーのセッションだけでなく、アプリケーションセッションを確実に無効にしましたか？どの管理機能が削除され、どれが単に非表示にされ、現在どのような承認がそれらを管理していますか？更新されたトークンはどのくらい短く、インシデントチームは数分以内にグローバルにそれらを無効化できますか？元従業員の番号は内部ディレクトリと標的警告プログラムから削除されつつも、彼らが偽装を報告する経路は保たれていますか？

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

信頼できる公開修復スコアカードは、機密の詳細を保護しつつ成果を明らかにすることができます。

公開証拠の欠如は、管理策が不在であることの証明ではありません。それは、保証を実装とは別に格付けする理由です。Twilio は、安全に公開できない企業顧客や監査人に機密の証拠を提供するかもしれません。調達チームはそれを要求すべきです。公的な説明責任は、顧客のアイデンティティや防御上の秘密を明らかにしない集約されたカバレッジとパフォーマンスメジャーを通じて、依然として改善されることができます。

顧客には責任があったが、Twilio の従業員に対する管理権はなかった

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

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

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

企業の依存関係レビューは、ベンダー名ではなく機能を追跡すべきです。「Twilio を使用している」は広すぎます。あるチームはプログラマブル音声を使用し、別のチームは SMS アラート、また別のチームはワンタイム認証、さらに別のチームはカスタマーサポート、そして Authy かもしれません。各機能は異なる保管データ、サポートアクセス、障害時の動作、ユーザー救済策を持っています。調達は、各用途に対してデータフローと権限マップを要求すべきです。

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

Twilio チェーンに対する説明責任の割り当て

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

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

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

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

影響を受けた顧客は、下流のアプリケーションアーキテクチャとユーザー対応を管理していました。Signal の説明は責任ある封じ込めを示しています。それはプロバイダーデータをユーザーにマッピングし、露呈したものとそうでないものを区切り、再登録を強制し、ユーザーに通知し、登録ロックを推進しました。他の顧客の義務は、そのデータと製品用途に依存していました。

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

規制当局および公的機関は、通知を受け取り、法律が重複する場所での調整、裏付けられた違反の調査、法的に可能な場合の重要な調査結果の公開に責任を負っていました。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 キーは認証の命題を変えました。より短いセッションとより広範な失効は時間を制約しました。管理機能の削減は権限を制約しました。トレーニング、公開報告ルート、調整されたテイクダウンは、人間とプロバイダー間の層を改善しました。これらの措置は、一般的な謝罪よりも重みがあります。

しかし、説明責任は展開で終わりません。顧客は、フィッシング耐性認証が弱い代替手段なしに施行されていること、サポートツールがタスクが必要とするものだけを明らかにすること、すべての機密性の高い読み取りが帰属可能であること、不審なセッションがアプリケーション全体で無効化できること、そして顧客固有のインシデント証拠が顧客の通知義務よりも速く移動できることの証拠を必要とします。取締役会はカバレッジ、例外、演習、応答時間のメジャーを必要とします。規制当局は、不幸なクリックを不合理な管理設計と区別するのに十分な事実を必要とします。

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