Twilio：1件のフィッシング成功が顧客データに与える増幅効果

サマリー

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

少ない顧客数は大きな依存関係を隠蔽しうる

Twilio の最終インシデント報告書には、口にしやすく誤解しやすい2つの比率が示されている。27万社以上のうち209社の顧客、そして約7500万人のうち93人の Authy ユーザーである。どちらの割合も小さいが、影響を受けた 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 の統合されたインシデント報告書と調査結論がこの一連の流れの主要な情報源である。

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

同社の証券取引報告書はいくつかの有用な境界を追加した。Twilio は、行為者が未知の情報源から従業員の氏名と携帯電話番号を入手したこと、影響を受けた顧客に通知し協力したこと、適切な規制当局に通知しその質問に対処したこと、そして業界の報告ではこの活動がテクノロジー、通信、暗号資産の各組織に及んでいたこと、などを述べている。同社の第3四半期2022年フォーム10-Qおよびその後の2022年フォーム10-Kでも、209社という数字を繰り返し、改善策を要約している。

これらの提出書類は、証券法上の義務に基づいて作成された企業声明である。匿名の報道よりも、Twilio が正式に開示した内容についてのより強力な証拠とはいえるが、独立した法科学監査や規制当局によるコンプライアンス判断ではない。本記事のためにレビューされた公開記録には、このインシデントについて法的責任を割り当てる執行命令は含まれていない。したがって、本記事は管理策と証拠に関する運用上の判断を支持するものであり、裁判所や規制当局が最終的な過失評決に達したという主張を支持するものではない。

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

一部の従業員が偽のページで認証情報を入力したのは事実である。そこで止めると弱い説明になる。ソーシャルエンジニアリングは、正当な業務がすでに人々にメッセージを読み、リンクを開き、スケジュール変更に対応し、認証することを求めているという事実を利用するように設計されている。攻撃者は、従業員が持ち歩く経路、雇用主に関連する文言、馴染みのあるアイデンティティプロバイダを模倣したページを選んだ。さらに、元スタッフの番号を含め、従業員の氏名と電話番号を結びつける十分な個人マッピングを行っていた。

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

この区別は、公平性とエンジニアリングの両方にとって重要である。従業員を非難することは、報告が最も貴重な瞬間に過少報告を助長する。また、認識キャンペーンに資金を振り向ける一方で、再利用可能な認証プロトコルをそのままにする。Twilio は追加の必須訓練を導入したが、より重要な対応は、全従業員に FIDO2 セキュリティキーを配布し、二要素認証の対策を強化したことであった。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 にとって、同等の説明責任上の問いは、アイデンティティプロバイダがログを生成したかどうかだけでなく、どの従業員アイデンティティが認証したか、どの要素が使用されたか、どのアプリケーションがセッションを発行したか、それらのセッションがどの顧客レコードに触れたか、そして関連するすべてのセッションが無効化されたかどうかを、同社が迅速に回答できたかどうかである。

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 の現在のMonitor Events 文書は、API を通じて、コンソールユーザーによって、さらには Twilio 従業員によって行われた変更のイベントレコードを説明している。イベントには、アクタータイプ、ソース、ソース IP、リソース、イベントデータが含まれ、保持期間はアカウントパッケージによって異なる。これは、顧客が現在意味のあるプラットフォーム活動レコードを入手できる証拠であるが、Signal に関連する2022年のサポートコンソールビューがすべて顧客可視であり、その製品の下で保持されていたことの証明ではない。このインシデントは、監査範囲に構成変更だけでなく、読み取りアクセスと検索も含めるべき理由を浮き彫りにしている。

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

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

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

これは単なる連絡先データの露出ではなかった。Authy デバイスの追加は、アカウント設定やリンク先サービスの安全策次第で、攻撃者にリンクされたサービスのタイムベース認証コードへの持続的な経路を与えうる。Twilio がリンクされたアカウントを調査するよう助言したことは、その可能性を反映している。公開報告書は93人の全ユーザーがリンク先サービスで侵害を受けたとは述べていないため、正しい状態は「不正デバイスが登録された」であり、その後の顧客固有の調査が続く。

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

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

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

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

インシデント報告書は、各影響顧客が何を失ったかについてのフィールド単位の説明を公表しなかった。その省略は、顧客の機密性、調査の限界、あるいは製品やサポートビューの多様性を反映しているかもしれない。それでもなお、それは保証上のギャップを生み出す。顧客は Twilio の総数から自らのエクスポージャーを推測することができず、外部の読者はアクセスが適切に最小化されていたかどうかをテストできない。

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

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

管理設計はまた、観察とアクションを分離すべきである。メッセージステータスの確認、アカウント設定の変更、認証情報の作成、デバイスの登録、ワンタイムコードの表示は、それぞれ異なる結果をもたらす。それらは異なる承認要件と明確な監査イベントを生成すべきである。高リスクのアクションは、最近のフィッシング耐性再認証、管理デバイスのポスチャー、顧客承認済みのサポートセッション、または二重管理を要求しうる。目的はサポートを使いにくくすることではない。それは、従業員の侵害が顧客インシデントになる前に失効するようにすることである。

通知は分散型のインシデント対応管理策である

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

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

米国連邦取引委員会のデータ侵害対応ガイドは、他者のデータを保管する事業者に対し、影響を受けた事業者に通知し、サービスプロバイダが実際に脆弱性を修正したことを確認するよう助言している。また、調査の文書化、証拠の保持、関与する情報と人口の確認、人々が自分自身を保護するのに役立つ詳細の提供も強調している。このガイドは Twilio に対する法的判断ではないが、プロバイダチェーンに関連する運用基準を捉えている。

NIST の現行のインシデント対応勧告は、インシデント処理を準備、検出、対応、回復、改善にわたって位置づけており、確認後に始まるセキュリティチームのイベントとして扱っていない。クラウドプロバイダにとって、顧客コミュニケーションはその運用モデルの中に属する。通知の質は、サンプルのテナント固有証拠パッケージを生成し、顧客がそれに基づいて行動できるかどうかをテストすることによって、インシデント発生前に訓練されるべきである。

Twilio の現行のデータ保護補遺（Data Protection Addendum）は、対象となるセキュリティインシデントについて不当な遅延なく顧客に通知し、顧客が当局やデータ主体に通知しなければならない場合に合理的な支援を提供すると述べている。また、秘密監査報告書と顧客の構成責任についても説明している。(Twilio データ保護補遺) リンク先のバージョンは2026年に更新されているため、2022年のすべての顧客にとっての正確な契約書として遡及して読むべきではない。これは、通知、支援、監査、および責任共有がどのように割り当てられているかについての現在の表明として有用である。実際の権利は、各顧客に適用される契約と法律に依存する。

改善策は侵入経路に対処したが、証明は不完全なままである

Twilio は4つの即時根絶措置を報告した。侵害された従業員認証情報のリセット、侵害された Okta 統合アプリケーションに関連するアクティブセッションの無効化、既知の指標のブロック、偽の Twilio ドメインのテイクダウン要求である。その後、5つの長期的措置を挙げた。全従業員向けのより強力な二要素認証対策と 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 のサプライチェーンリスク管理クイックスタートガイドは、テクノロジーサービスプロバイダをサプライチェーンの一部として扱い、サプライヤーリスクを一度限りの購買ではなくガバナンスに結びつけている。本事例に当てはめると、顧客はプロバイダ依存関係を棚卸し、重要な機能とデータを特定し、インシデント通知要件を設定し、保証証拠を入手し、代替案を計画すべきである。これは、一般的な侵害条項を追加するより要求度は高いが、クラウド関係を管理可能にする。

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

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

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

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

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

影響を受けた顧客は、下流のアプリケーションアーキテクチャとユーザー対応を管理していた。Signal の説明は責任ある封じ込めを示している。プロバイダデータをユーザーにマッピングし、何が露出し何が露出しなかったかを境界付け、再登録を強制し、ユーザーに通知し、登録ロックを促進した。他の顧客の義務は、データと製品の利用状況に依存する。

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

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

公開記録が依然として答えられないこと

最も強力な説明責任分析は、未知の部分を自信のある言葉で埋めるのではなく、印を付けるものである。Twilio は、従業員の電話番号がどのように収集されたかを公に特定していない。Group-IB は、電気通信事業者への初期の標的化がいくつかの番号を供給した可能性を示唆したが、それはキャンペーンの仮説であり、Twilio 固有の証明された情報源ではない。

公開記録は、何人の従業員が認証情報を入力したか、影響を受けたアカウントがどのような要素を使用していたか、攻撃者がワンタイムコードをリアルタイムで取得したかどうか、あるいはいかなる回復経路が関与したかについて述べていない。最初の認証成功から8月9日までのセッション単位のタイムラインも提供していない。

到達された内部ツールの完全なセット、各従業員アイデンティティの権限、または顧客ごとの閲覧フィールドとアクションのリストも公表していない。Signal は自らの人口について詳細を提供しているが、その詳細は他の208社の顧客に一般化されるべきではない。

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

完了した FIDO2 展開、代替経路、トークン無効化、VPN 制限、管理ツール削減に関する独立した公開テストも提供していない。後の保証文書は一部の管理策を秘密裏にカバーするかもしれないが、その範囲と例外は仮定するのではなくレビューされなければならない。

最後に、Twilio プラットフォームの停止があったこと、攻撃者がすべての影響顧客のメッセージ内容にアクセスしたこと、顧客の API キーが盗まれたこと、または潜在的に影響を受けたすべての Signal ユーザーが再登録されたことを立証していない。それらの主張は証拠を超えるものである。

永続的な試金石は、1通の信憑性のあるメッセージでどれだけの権限が買えるかだ

Twilio のインシデントは、ごく一部の顧客に影響を与えた SMS フィッシングとして要約されることがある。その説明は算術的には防御可能だが、運用上は不完全である。重要な単位は顧客アカウントの割合ではなかった。それは、従業員が誤った場所で認証した後に利用可能になった下流の権限の量であった。

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

Twilio の発表された対応は、技術的に正しい方向に動いた。FIDO2 キーは認証の前提を変えた。短いセッションとより広範な無効化は時間を制約した。管理機能の削減は権限を制約した。訓練、公開報告経路、調整されたテイクダウンは、人間とプロバイダ間の層を改善した。これらの措置は、一般的な謝罪よりも重みを持つに値する。

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

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