概要

  • 2020年7月の Twitter アカウント乗っ取りは、内部アクセスの侵害により攻撃者が注目度の高いアカウントから投稿できるようになったため、私的なサポート制御問題を公的信頼の出来事にした。
  • 公的記録には、Twitter の企業アップデート、ニューヨーク州金融サービス局の調査、司法省の起訴記録、SEC のリスク開示、FTC のガバナンス状況、Coinbase の緩和対策メモ、およびこの攻撃に関するセキュリティレポートが含まれる。
  • 制御の問題は、攻撃者がどのようにアクセスを獲得したかだけではない。Twitter が、特権的な従業員ツールが制限、監視、再設計され、アカウントレベルの権限の公的結果に適合していることを証明できるかどうかである。
  • 責任は分散されていたが対称的ではなかった。攻撃者とソーシャルエンジニアが直接の悪用を引き起こした。Twitter は内部ツール、従業員アクセス、認証、トレーニング、監視、注目アカウントの保護、インシデント対応、および公的通知を管理していた。
  • 永続的な教訓は、ソーシャルプラットフォームのサポートツールは公共インフラのように管理されなければならないということである。内部統制が公的発言を書き換えることができる場合、それらは単なるバックオフィスツールではない。

一般ユーザーは発言を見たが、攻撃者はコントロールプレーンを見ていた

2020年の Twitter インシデントは、最も目に見えるペイロード、すなわち注目度の高いアカウントが暗号通貨詐欺メッセージを投稿したこととして記憶されることが多い。その記憶は正確だが不完全である。より永続的な説明責任の教訓は、ソーシャルプラットフォームの内部アカウント管理ツールが公的発言に対するコントロールプレーンを形成したことである。ユーザーはツイートを見た。攻撃者は、アカウントがあたかも発言しているように見せかけることができる特権的な経路を見ていた。

Twitter のセキュリティインシデントに関する企業アップデートによると、攻撃者はソーシャルエンジニアリングによって従業員を標的にし、内部システムを使用してアカウントにアクセスした。ニューヨーク州金融サービス局は後に、攻撃がどのように展開したか、そしてなぜそれがより広範なプラットフォームガバナンスリスクを露呈したかを説明する詳細なTwitter 調査報告書を発表した。これらの情報源は同じ根底にある点を指摘している:アカウントの完全性はユーザーのパスワードや二要素認証だけでなく、プラットフォーム自身の内部権限にも依存する。

その区別は公的信頼にとって重要である。注目度の高いアカウントは単なるログインではない。それは公的コミュニケーションチャネルである。市場を動かし、ニュースサイクルを形成し、支持者を誘導し、支払いを促し、パニックを引き起こし、あるいはアカウント所有者が発言していると合理的に信じるユーザーを誤解させる可能性がある。内部ツールがユーザー側の保護を無効にできる場合、プラットフォームはそれが生み出しうる公的結果に応じてそのツールを保護する義務を負う。

ミスマッチは簡単に言える。一般はアカウント所有者に意味を帰する。プラットフォームは従業員とツールに運用権限を割り当てる。従業員ツール層が公的信頼層よりも弱い場合、一般は制御システムが保証できない場所で真正性を見る。Twitter ハックは、そのミスマッチを数時間の混乱の中で可視化した。

これが、このインシデントをユーザー認識の問題に還元できない理由である。影響を受けたアカウントの所有者は、すべて同じフィッシングメッセージに引っかかったわけではない。プラットフォームの内部ワークフローが争点となった表面である。プラットフォームはユーザーに強力な認証を採用するよう促すことができるが、内部システムが同等の規律なしにアカウント制御をリセット、変更、またはアクセスできる場合、ユーザー側のセキュリティは約束の一部に過ぎなくなる。

従業員ソーシャルエンジニアリングはプラットフォーム設計のテストだった

ソーシャルエンジニアリングはしばしば人間の弱点として議論される。Twitter の記録では、それはシステム設計のテストとして扱われるべきである。従業員は標的だったが、プラットフォームは機密アクセスを持つ従業員の数、ツールを使用できる条件、必要な認証、ツール使用の監視、異常なリクエストのワークフロー、および従業員の認証情報が悪用された場合の爆発半径を選択した。

NYDFS の報告書を要約したプレスリリースは、攻撃の重大性と大規模ソーシャルメディア企業に対するより強力なサイバーセキュリティ規制の必要性を強調した。報告書の詳細は、「従業員がだまされた」だけで止まらないため有用である。なぜ攻撃者が従業員アクセスを公的規模のアカウント乗っ取りに転換できたのかを問いている。

これが正しい説明責任の枠組みである。企業はすべてのソーシャルエンジニアリングリスクを取り除くことはできないが、ソーシャルエンジニアリングの有用性を低下させることはできる。特権アクセスを減らし、より強力な認証を要求し、サポートツールを分離し、異常な行動を監視し、高リスクのアカウント変更には二重管理を適用し、機密操作をレート制限し、ジャストインタイムの承認を要求し、注目アカウントを追加の制限で保護し、疑わしい電話をエスカレーションするよう従業員を訓練することができる。それぞれの設計選択は、1回の成功した欺瞞が公的悪用になる可能性を減らす。

NIST のデジタルアイデンティティガイダンスSP 800-63Bは Twitter 固有の基準ではないが、認証強度とアカウント回復管理が重要である理由を明確にするのに役立つ。数百万のアイデンティティを管理するプラットフォームは、自社の従業員認証を公的アイデンティティシステムの一部として扱わなければならない。内部の保証が弱いと、外部の強力な保証が損なわれる可能性がある。

CISA のSecure by Designガイダンスもここで役立つ。負担は、個々の従業員だけがすべての欺瞞的な電話に抵抗することにあるべきではない。製品と運用システムは、一般的な人的エラーが壊滅的な公的結果を生まないように設計されるべきである。国家元首、主要企業、取引所、有名人、メディアアカウントに影響を与える可能性のあるサポートツールは、通常のヘルプデスクパネルのように振る舞うべきではない。

ソーシャルエンジニアリングインシデント後の責任ある対応は、従業員がより注意するようにというメモではない。それはアクセスの再設計である。どのツールが強力すぎたか?どのユーザーが多すぎる常時アクセスを持っていたか?どのアクションに二次レビューが欠けていたか?どのログが監視されていなかったか?どの注目アカウントに追加の保護が必要だったか?緊急例外のためにどのワークフローが存在したか?どの従業員グループがサポートしていないアカウントに行動できたか?

これらの質問は、議論を非難から制御へと移す。それらは欺瞞を許容しない。プラットフォームが欺瞞を強力にしすぎたかどうかを問う。

注目アカウントの保護は通常のサポートではありえない

影響を受けたアカウントのセットは、Twitter インシデントを特に敏感なものにした。著名な公的人物、企業、暗号関連アカウントは大きな注目を集めた。そのようなアカウントからの虚偽のメッセージは、放棄されたプロフィールからのスパムと同じではない。ユーザーに即座に届き、ニュースメディアに埋め込まれ、自動取引や詐欺検出を引き起こし、削除後もスクリーンショットを通じて拡散する可能性がある。

司法省のアーカイブ発表によると、3人が Twitter ハックへの関与で起訴されたことで法執行対応が文書化された。後の SDNY の発表では、Joseph James O'Connor に対する5年の刑期が示され、この事件がより広範なサイバー犯罪記録の一部であり続けたことがわかる。刑事責任は重要だが、プラットフォームガバナンスの問題を終わらせるわけではない。プラットフォームは、高リスクアカウントが内部ツールの悪用からどのように保護されるかを示す必要があった。

注目アカウントの保護には、バッジや公的な認知以上のものが含まれるべきである。それは異なる管理ルールを意味する。機密アカウントでは、メール変更、電話番号変更、パスワードリセット、セッション無効化、投稿制限に二重承認が必要になるかもしれない。内部ツールがそれに触れた場合、より強力なアラートが発動されるかもしれない。1回のサポートアクションでは完了できない強化された復旧パスを持つかもしれない。突然の詐欺的な言葉や支払いアドレスパターンが監視されるかもしれない。

トレードオフがある。サポートチームは、特にジャーナリスト、政府関係者、攻撃下にある組織などのアカウント所有者を迅速に支援する必要がある。過度に厳格な管理は、正当なユーザーを締め出したり、緊急の修復を遅らせたりする可能性がある。しかし、2020年のインシデントは、通常のサポートの利便性だけが設計基準になりえない理由を示している。注目アカウントからの虚偽の投稿は公的な出来事である。

同じ論理が内部スクリーンショットとツールの可視性にも適用される。当時の報道、例えば TechCrunch の著名アカウントが暗号詐欺でハッキングされたという記事では、インシデント中に内部ツールのスクリーンショットが出回ったことが議論された。特定のスクリーンショットがすべての関連ツールの権限を捉えていたかどうかは、原則よりも重要ではない。管理ビュー自体が機密アーティファクトになりうる。プラットフォームは、強力なツールを使用できる人だけでなく、機密アカウントのメタデータを見ることができる人、ツールビューをエクスポート、撮影、悪用する方法を制限すべきである。

注目アカウントの保護には、公的対応モードも必要である。プラットフォームが著名なアカウントが悪用されていることを認識した場合、投稿を制限し、アカウントをロックし、危険なコンテンツを抑制し、特定の機能を一時的に無効にする必要があるかもしれない。Twitter はインシデント中に一部のアカウント活動を制限した。説明責任の問いは、それらの緊急制御が事前に定義され、テストされ、比例していたか、それとも圧力の下で即興で行われたかである。

詐欺対策は Twitter の外でも行われた

直接のペイロードは暗号通貨詐欺であり、一部の対策はプラットフォーム外で行われた。Coinbase は後に、1,100人以上の顧客がビットコインを詐欺アドレスに送信するのを阻止したと述べている。この記録は、プラットフォームのインシデントが隣接システムに義務を生み出すことを示すため重要である。Twitter の内部制御の失敗は、取引所の詐欺防止問題およびユーザー保護問題になった。

一般は時折、暗号詐欺インシデントを被害者がもっと注意すべきだったと扱う。それは単純すぎる。詐欺は、ユーザーがすでに認識しているアカウントの正当性を借りることによって機能した。攻撃者が信頼されたアカウントを通じて投稿するとき、詐欺シグナルは部分的に反転する。アカウント自体が餌になる。ユーザーは依然として賢明でない行動をとるかもしれないが、プラットフォームは信頼されたアイデンティティの下で虚偽の声明を表示させることにより、欺瞞に貢献した。

CNBC のTwitter ハックとビットコイン詐欺に関する報道は、この出来事がどれほど迅速に主流の公的関心事になったかを捉えた。KrebsOnSecurity のハックの背後にいるのは誰かの分析は、セキュリティコミュニティの証拠とオンラインアカウント取引の文脈を追跡した。これらの報告は公式記録に取って代わるべきではないが、公的注意、サイバー犯罪捜査、プラットフォーム対応がどれほど迅速に収束したかを示している。

したがって、詐欺対策はインシデントプレイブックの一部であるべきである。プラットフォームのアカウント乗っ取りが支払いの勧誘に使用された場合、プラットフォームは取引所、支払い会社、ウォレット分析プロバイダー、法執行機関、悪用対策チームに通知する高速経路を持つべきである。投稿されたコンテンツ、URL、支払いアドレス、影響を受けたアカウント、タイミングの証拠を保存すべきである。詐欺を不必要に増幅させることなく特定する明確なユーザーガイダンスを公開すべきである。

プラットフォームはまた、注目アカウント全体での突然の共通詐欺テンプレートの事前構築検出を検討すべきである。多くの著名アカウントが同様の支払いアドレスメッセージを投稿し始めた場合、そのコンテンツパターン自体が内部ツールまたはアカウントリカバリが悪用されたシグナルである可能性がある。自動コンテンツモデレーションだけでは十分ではないが、露出を短縮できる。

説明責任の記録は、Twitter が Coinbase や他の取引所を管理していたと装うべきではない。公的プラットフォームのインシデントがより広い防御チェーンを生み出すことを認識すべきである。内部ツールを所有する企業は、送金を停止できる企業と迅速に連携しなければならない。その連携は公的被害の軽減の一部である。

公的通知は速度と証拠のバランスを取らなければならなかった

公的プラットフォーム乗っ取りの間、通知は形式的なものではない。ユーザーはアカウントが本物かどうか、メッセージを信頼すべきかどうか、ダイレクトメッセージがアクセスされた可能性があるかどうか、アカウント所有者が行動を起こす必要があるかどうか、攻撃者がまだ制御しているかどうかを知る必要がある。同時に、プラットフォームはまだ調査中である可能性がある。通知の問題は、確実性を装わずに迅速であることである。

Twitter のインシデントアップデートは、多くのアカウントの機能を制限し、アクセスを復元するための取り組みなど、取られた措置を説明した。また、影響を受けたアカウントをより広範なプラットフォーム活動から区別し、内部システムを調査の一部として説明した。この種の公的コミュニケーションは、インシデント自体が公衆の面前で発生するため必要である。沈黙は、詐欺投稿やスクリーンショットが単なる異常なアカウント行動であるかのように流通し続けることを許す可能性がある。

NIST のコンピュータセキュリティインシデント対応ガイドは、コミュニケーションをインシデント対応の一部として位置付け、広報の付加物ではないとするため有用である。プラットフォーム発言インシデントでは、コミュニケーションは安全制御でもある。明確な通知は、詐欺送金を減らし、ユーザーに詐欺メッセージを信頼しないよう警告し、アカウント所有者に次のステップを安心させ、インシデントに関する誤情報が二次インシデントになるのを防ぐことができる。

適切な通知は、既知の事実、現在の行動、ユーザーガイダンス、未解決の質問を分離すべきである。既知:一部のアカウントが内部システムを通じて侵害された。現在の行動:特定の機能が制限された。ユーザーガイダンス:暗号通貨を送金したり、疑わしい投稿を信頼したりしないこと。未解決:完全なアカウントセット、ダイレクトメッセージの露出、内部アクセス経路、長期的な是正。この構造は、詳細が進化してもユーザーが何をすべきかを理解するのに役立つ。

より難しい問題は、プラットフォームが可視的なインシデント履歴を保持すべきかどうかである。公的アップデートは削除、編集、またはスレッド全体に散在する可能性がある。耐久性のあるインシデントページまたは報告書は、ユーザー、アカウント所有者、研究者、規制当局に安定した記録を提供する。公的コミュニケーションを仲介するプラットフォームにとって、自身のコミュニケーションの記録は監査可能であるべきである。

公的通知はまた、名前が悪用されたアカウント所有者を考慮しなければならない。彼らは確認、サポート、フォロワーとの信頼回復のガイダンスを必要とする。著名なアカウント所有者は、メッセージが虚偽であったことを述べ、法執行機関と連携し、フォロワーに警告し、評判の損害を評価する必要があるかもしれない。プラットフォームの通知は、プラットフォームのブランドを保護するだけでなく、そのプロセスを支援すべきである。

規制記録は公共インフラの性格を露呈した

NYDFS の報告書は、Twitter を単なる私的アプリ以上のものとして扱ったため貴重である。大規模ソーシャルメディアプラットフォームは、金融市場、政治コミュニケーション、公共の安全、市民的信頼に影響を与える可能性があることを認識した。それはすべてのプラットフォームが銀行のように規制されるべきという意味ではない。内部統制は、その障害が公的コミュニケーションを大規模に歪める可能性がある場合に精査に値するという意味である。

Twitter の2021年 Form 10-Kには、2020年7月のハックと、セキュリティインシデントがアカウントと公的認識に影響を与える可能性に関するリスクファクターの文言が含まれていた。SEC の提出書類は投資家に役立つが、この場合、同じ事実がユーザーにも重要である。注意と公的コミュニケーションを収益化する企業は、注意が本物かどうかを決定するシステムを統治しなければならない。

FTC の2022年のプレスリリースで Twitter をアカウントセキュリティデータをターゲット広告に欺瞞的に使用したとして告発したのは別の問題であり、修正された FTC 命令は2020年7月のハックに関する技術報告書として扱われるべきではない。それでも、規制当局が表明、セキュリティプログラム、プライバシーの約束、アカウントセキュリティに関する内部統制をどのように評価するかを示すため、ガバナンス記録に属する。プラットフォームの信頼は単一のインシデントだけではない。

公共インフラの性格は対応負担に現れる。銀行のアカウントがハッキングされると、顧客が欺かれる可能性がある。公務員のアカウントがハッキングされると、有権者が誤解される可能性がある。メディアアカウントがハッキングされると、ニュースが歪曲される可能性がある。企業幹部のアカウントがハッキングされると、市場が反応する可能性がある。暗号通貨取引所のアカウントがハッキングされると、詐欺が加速する可能性がある。プラットフォームの内部ツールは、これらすべての結果の下にある。

したがって、規制当局は通常のユーザーが答えられない質問をする。何人の従業員がアクセスを持っていたか?どの認証が必要だったか?特権的なアクションは記録され、レビューされたか?注目アカウントは追加の制御の対象だったか?従業員は訓練されていたか?内部ツールは悪用を最小限にするように設計されていたか?インシデント対応の制限はテストされていたか?ユーザーは迅速に真実を知らされたか?

これらの質問は後知恵として却下されるべきではない。それらはまさにプラットフォームがインシデントの前に問うべき質問である。公共プラットフォームのガバナンスは、内部運用をそれが生み出しうる公的被害の周りに設計することを意味する。

サポートツールには最小特権と摩擦が必要

サポートツールはユーザーの問題を解決するために存在する。ロックされたアカウントをリセットし、アクセス回復を支援し、悪用報告を管理し、アカウント状況を確認し、プラットフォームを使用可能に保つ。その正当な目的がそれらを強力にする。Twitter インシデントは、サポートツールに最小特権と意図的な摩擦が必要である理由を示している。正しいユーザーを助けることができるツールは、アクセスとワークフローが弱い場合、間違った攻撃者も助けることができる。

CISA のセキュア構成ベースラインの概念は、一般的なガイダンスであるがここに適合する。内部ツールはベースライン制御を持つべきである:制限されたアクセス、MFA、デバイス状態チェック、ログ記録、レビュー、変更承認、職務分離。特に機密性の高いアカウントについては、ベースラインをより厳格にする必要がある。セキュリティの目標はサポートを不可能にすることではなく、危険なサポートアクションを可視化し、悪用を困難にすることである。

最小特権は複数の層に適用されるべきである。従業員の役割は、仕事に必要なアカウントアクションのみを許可するべきである。ツール機能は分離され、アカウントデータの表示、資格情報の変更、連絡先情報の変更、保護の無効化、投稿またはアクセス復元が安易にバンドルされないようにする。機密アカウントには追加の承認が必要である。一時的なアクセスは期限切れになるべきである。異常なパターンはレビューをトリガーするべきである。

摩擦は常に悪いわけではない。消費者製品設計では、摩擦はしばしば敵として扱われる。特権操作では、いくつかの摩擦は制御である。第二のレビュー担当者、クーリングオフ期間、より強力な認証器、必須の理由コード、または高リスクアラートは、急いだソーシャルエンジニアリング攻撃が公的イベントになるのを防ぐことができる。鍵は、害が正当化される場所に摩擦を適用することである。

サポートツールはまた、強力な可観測性を必要とする。内部アクションが注目アカウントに触れた場合、プラットフォームは誰が、どのデバイスから、どのセッションで、どのチケットで、どの承認で、何を変更したかを知るべきである。ログは改ざんから保護され、調査に十分な期間保持されるべきである。不審なアクションが発生した場合、プラットフォームはタイムラインを迅速に再構築できるべきである。

インシデント後、公的説明責任の質問は、それらの制御が変更されたかどうかである。企業はアクセスを制限したりツールを改善したと言うことができるが、ユーザーと規制当局は、再設計が実際の障害モードに対処したという確信を必要とする。アクセスは縮小したか?認証は強化されたか?監視は改善されたか?注目アカウントは追加の保護を受けたか?ソーシャルエンジニアリングトレーニングは変わったか?緊急制限ツールはより明確になったか?

私的露出は別の証拠問題だった

公的投稿は最も目に見える害だったが、アカウント乗っ取りはより静かな証拠問題も提起する:どの私的アカウント資料に到達できたのか?一般ユーザーは詐欺ツイートを見た。アカウント所有者と規制当局は、ダイレクトメッセージ、メールアドレス、電話番号、アカウント設定、セッション状態、復旧データ、内部メタデータについて問い合わせる必要があった。答えが重要なのは、公的に投稿できる同じ内部アクセスが、私的情報を露出したり将来の攻撃を可能にしたりする可能性があるからである。

Twitter の公的アップデートは、投稿に使用されたアカウントをより広範なアカウントアクセスの質問から区別したが、外部の観察者は依然として証拠の境界を理解する必要があった。攻撃者は影響を受けたアカウントのダイレクトメッセージを表示したか?アカウント情報をダウンロードしたか?メールアドレスや電話番号を変更したか?永続性を作成したか?内部ツールをリセットや投稿のためだけに使用したか、それとも私的アカウントデータを検査するためにも使用したか?これらの質問は誇張ではない。内部システムの権限から直接生じる。

著名ユーザーにとって、私的露出は公的詐欺よりも有害である可能性がある。ジャーナリストのダイレクトメッセージには情報源が含まれている可能性がある。公務員のアカウントには機密の調整が含まれている可能性がある。企業のアカウントには未公開の発表、顧客からの苦情、危機連絡先が含まれている可能性がある。セレブや活動家は個人の安全リスクに直面する可能性がある。したがって、プラットフォームは「虚偽の投稿を削除」と「私的露出をレビュー」を区別すべきである。それらは異なる状態である。

私的露出評価に必要な証拠も異なる。捜査官は内部ツールログ、アカウントアクセスログ、セッション情報、復旧データの変更、API アクティビティ、エクスポートされたデータリクエスト、および異常なメッセージアクセスを必要とする。緊急クリーンアップが痕跡を消す前に記録を保存する必要がある。攻撃者を助ける詳細を明かさずに、アカウント所有者が行動するのに十分な情報を伝える必要がある。

公的通知は階層化されるべきである。一般ユーザーには幅広いガイダンス。影響を受けたアカウント所有者には直接的で具体的な調査結果。特に機密性の高いアカウント所有者には個別のサポート、法執行機関との調整、または連絡先の保護に関するアドバイスが必要な場合がある。プラットフォームは私的アカウントの事実を公衆に過度に開示すべきではないが、リスクを負う人々に不確実性を隠すべきでもない。

これはまた、内部アクセスレビューが単なる人事問題以上になる場所である。従業員ツールがアカウントデータを露出できる場合、アカウント投稿権限だけでなく、各特権アクションはプライバシーの結果をもたらす。アクセスは正当化され、記録され、レビューされるべきである。ツール設計は、タスクが必要としない限り、サポートスタッフが見ることができるものを制限するべきである。機密フィールドは可能な限りマスクされるべきである。高リスクアカウントの表示は、公的投稿が行われなくても監査シグナルをトリガーするべきである。

同じ私的露出の論理がインシデント後にも適用される。攻撃者が投稿したかどうかを問うだけでは不十分である。投稿は可視的なアーティファクトである。より深い問いは、アカウントの私的表面が触れられたかどうかである。成熟したプラットフォームは、その質問にアカウントごとに迅速に、所有者を導くのに十分な確信を持って答えることができるべきである。

緊急制限は公的制御手段である

インシデント中の最も難しい選択の一つは、プラットフォーム機能を制限することだった。Twitter が一部のアカウントの活動を制限したとき、調査中に害を減らすために緊急制御を使用していた。そのような制御は鈍器である。追加の詐欺投稿を防ぐことができるが、急速に動く公的イベントの間に正当なアカウント所有者を沈黙させることもある。そのトレードオフが、緊急制限が即興のパニックボタンではなく、公的制御手段として扱われるべき理由である。

設計上の問いは、何が制限をトリガーするかである。単一の侵害されたセレブアカウントは、1つのアカウントをロックする必要があるかもしれない。多くの著名アカウントにわたるパターンは、アカウントのクラスまたは内部アクションに一時的な制限を必要とするかもしれない。内部ツールが悪用されているという証拠は、特定の従業員ワークフローを無効にする必要があるかもしれない。プラットフォームは緊急前に基準を必要とする。さもなければ、インシデントチームは極度の圧力の下でガバナンス決定を行うことになる。

第二の問いは範囲である。どのアカウントが制限されるか?どのアクションがブロックされるか?アカウント所有者はメッセージを読めるが投稿できないか?詐欺投稿を削除できるか?代替チャネルを通じて通信できるか?政府、緊急、健康、公共安全アカウントは異なる扱いを受けるか?プラットフォームは、著名アカウントが凍結されている間に、攻撃者が制限されていない低プロファイルアカウントを悪用するのを防ぐ方法があるか?狭すぎる制限は失敗する可能性がある。広すぎる制限は不必要な公的混乱を生む可能性がある。

第三の問いは説明可能性である。ユーザーはプラットフォームが緊急制限を課しているときとその理由を知るべきである。アカウント所有者は信頼された制御を取り戻す方法を知るべきである。一般は疑わしい投稿を無視すべきか知るべきである。規制当局は制限がユーザーを保護したのか、単に風評被害を制限したのかを知るべきである。それはすべての技術的詳細を露出する必要はない。原則的な記録が必要である。

緊急制限には内部的な対応物もある。攻撃者が従業員ツールを使用している場合、企業はツールアクセスを制限し、セッションを取り消し、再認証を要求し、ワークフローを無効にし、追加の承認を強制する必要があるかもしれない。これらのアクションはプラットフォーム全体のサポートを遅らせる可能性がある。それらはさらなる害を防ぐこともできる。プラットフォームは、カスタマーサービスの減速と必要な封じ込め措置を区別できるべきである。

このため、取締役会の記録には緊急制御の動詞を含めるべきである。検出、制限、ロック、取り消し、再認証、復元、検査、通知、未解決。各動詞は具体的なものを言う。「迅速に対応した」とだけ聞く取締役会は、制御システムが機能したかどうかを評価できない。動詞を見る取締役会は、どこで時間が失われ、どの機能が存在しなかったかを問うことができる。

インシデント後のレビューは、訓練を通じて緊急制限をテストすべきである。著名アカウントに対する内部ツールの悪用をシミュレートする。アカウントクラス全体での調整された詐欺投稿をシミュレートする。ニュースイベント中の従業員認証情報の侵害をシミュレートする。誰が制限を承認できるか、誰がそれらを伝達するか、アカウント所有者がどのようにサポートされるか、詐欺パートナーがどのように通知されるか、ログがどのように保存されるか、制限がどのように解除されるかを問う。訓練は、製品、法務、ポリシー、エンジニアリング、信頼安全、サポート、コミュニケーション、および経営幹部の引き継ぎを明らかにするべきである。

2020年のインシデントは、プラットフォームが緊急制限を課すことができることを示したが、永続的な問いは、それらの制限が練習された能力になったかどうかである。公的発言を仲介するプラットフォームには、公開ツールと同じくらい慎重に設計された封じ込めツールが必要である。さもなければ、次の内部制御の失敗は、再び企業に速度、正確性、公平性、および公的被害の軽減の間で公衆の面前で選択を強いることになる。

アカウント所有者には復旧記録が必要だった

アカウントが触れられたすべてのアカウント所有者は、投稿能力の復元以上のものを必要とした。彼らは復旧記録を必要とした。その記録は、アカウントに何が起こったか、どのような内部または外部アクセスが観察されたか、どのコンテンツが投稿または試行されたか、どの私的データがアクセスされたかされなかったか、どの設定が変更されたか、どの資格情報またはセッションがリセットされたか、どの保護が追加されたか、どの不確実性が残っているかを示すべきである。

復旧記録が重要なのは、アカウント所有者自身の支持者があるからである。企業は顧客と投資家を安心させる必要があるかもしれない。公務員は虚偽の情報を訂正する必要があるかもしれない。ジャーナリストは情報源を保護する必要があるかもしれない。公的人物はフォロワーに詐欺に注意するよう警告する必要があるかもしれない。取引所や金融サービスは詐欺防止チームと連携する必要があるかもしれない。プラットフォームの内部的な終了は、自動的に関係者に必要な証拠を与えるわけではない。

記録にはタイミングも含まれるべきである。アカウントに最初に触れられたのはいつか?詐欺コンテンツが投稿されたのはいつか?削除されたのはいつか?アカウントがロックされたのはいつか?制御が復元されたのはいつか?所有者が通知を受けたのはいつか?私的露出の質問が解決されたのはいつか?タイミングは、クリーンなインシデントノートと争われる公的ナラティブの違いであることが多い。

アカウント所有者の復旧はリスクによって差別化されるべきである。攻撃に使用された小規模アカウントはサポートに値するが、国家指導者、大手企業、ニュースルーム、医療機関、金融機関は異なる下流の義務を持つ可能性がある。プラットフォームは、強力なユーザーがセキュリティルールを安易に回避することを許さずに、より直接的な調整とより良い証拠を提供する機密アカウント対応レーンを持つべきである。

復旧記録はまたプラットフォームを保護する。企業が影響を受けたアカウント所有者に具体的で正確かつタイムリーな情報を提供したことを示せれば、インシデントを軽視したという非難に対して脆弱ではない。それが示せなければ、アカウント所有者は憶測、スクリーンショット、または矛盾する公的声明でギャップを埋める可能性がある。証拠は噂を減らす。

最後に、復旧記録は製品設計にフィードバックされるべきである。多くのアカウント所有者が同じ質問をする場合、それらの質問は次のインシデントテンプレートの一部になるべきである。所有者がどの制御が自分を保護しているかを理解できない場合、製品はより強力なセキュリティ状態を公開すべきである。機密アカウント所有者が通常のアカウントにはない機能を必要とする場合、プラットフォームはポリシーを明示すべきである。復旧はインシデントの終わりではない。再設計の始まりである。

有用な監査は一つの特権アクションを追跡する

Twitter インシデント後の最も簡単な監査サンプルは、一つの特権アカウントアクションをリクエストから実行まで追跡することである。機密アカウントを選ぶ。誰がそれを表示できるか、誰が復旧詳細を変更できるか、誰がアクセスをリセットできるか、誰が制限を上書きできるか、どの承認が必要か、どのデバイスとネットワーク条件がチェックされたか、どのログイベントが生成されたか、誰がそれらのイベントをレビューしたか、アクションが異常に見えた場合にどのアラートが発生するかを問う。その後、ソーシャルエンジニアリングの圧力の下で同じアクションを再現する。

このサンプルは曖昧な保証を避ける。企業がセキュリティを気にかけているかどうかを問わない。特定の内部アクションが安全に実行できるかどうかを問う。アクションが強力な認証、承認、ログ記録、アラートなしに一人の騙された従業員によって実行できる場合、プラットフォームには具体的な制御ギャップがある。アクションが正当化されたアクセス、二次レビュー、改ざん防止ログ、および事後監視を必要とする場合、プラットフォームには証拠がある。

監査はまた拒否をサンプリングすべきである。従業員は疑わしいリクエストに罰則なしでノーと言えるか?サポートは奇妙な電話を迅速にエスカレーションできるか?緊急アクセスは身元が確認されるまでブロックできるか?企業は特権アクションが発生しなかったことを証明できるか?拒否の証拠が重要なのは、多くのソーシャルエンジニアリング攻撃が緊急性を生み出し、拒否を悪いカスタマーサービスのように感じさせることで成功するからである。

その種の監査は狭いが、まさに公的信頼が存在する場所である。公的アカウントは可視的なアーティファクトである。特権的な内部アクションは隠れた蝶番である。

公的信頼はアップタイムのように練習されるべきである

最後の Twitter の教訓は、公的真正性の失敗は停止時間のように練習されるべきであるということである。プラットフォームは、内部ツールが虚偽の公的発言を生み出したときに何が起こるかを練習すべきである:誰がアカウントを凍結するか、誰がユーザーに警告するか、誰が取引所や支払いパートナーに連絡するか、誰がアカウント所有者をサポートするか、誰が私的露出の不確実性を説明するか。アップタイム訓練は可用性を保護する。真正性訓練は、ユーザーが可視的なアカウントをまったく信頼できるかどうかを保護する。

説明責任のテストは真正な公的制御である

2020年の Twitter ハック後の説明責任の問いは、攻撃者が捕まったかどうかや詐欺投稿が削除されたかどうかだけではない。それは、プラットフォームが公的アカウントの真正性が、ユーザーが可視的なアカウントに置く信頼と同等に強い制御に依存していることを証明できるかどうかである。内部システムは、それが変更できるアカウントの公的意味に一致しなければならなかった。

公的記録は、すべての内部再設計、すべてのアクセス変更、またはすべてのインシデント後のテストを示しているわけではない。それは、攻撃が高レバレッジの内部表面を悪用したこと、および規制当局、検察官、取引所、ジャーナリスト、ユーザーがすべてこの出来事を通常のアカウント悪用以上のものとして扱ったことを示している。それが正しい枠組みである。プラットフォーム自身のツールがリスク対象になった。

ソーシャルプラットフォームにとって、教訓は永続的である。管理およびサポートシステムは、公的発言に影響を与える可能性がある場合、公共安全システムとして設計されるべきである。従業員アクセスは最小化されるべきである。高リスクアカウントには特別な制御が必要である。ソーシャルエンジニアリング耐性はトレーニングだけに任せるのではなく、ワークフローに設計されるべきである。詐欺対策の連携は迅速であるべきである。公的通知は構造化され、耐久性があるべきである。インシデント後の報告書は、既知のこと、変わったこと、不確かなままのことを区別すべきである。

ユーザーにとって、教訓は不快である。認証済みまたは著名なアカウントは、名前の付いた人物や組織がメッセージを入力した証拠ではない。アカウントの真正性は、ユーザーセキュリティ、プラットフォーム内部制御、従業員アクセス、復旧ワークフロー、インシデント対応を含むチェーンに依存する。そのチェーンのほとんどは一般ユーザーには見えない。その見えなさがプラットフォームの説明責任を重要にする。

規制当局と取締役会にとって、教訓は公的信頼の背後にある制御プレーンについて問うことである。誰が著名アカウントに触れることができるか?どの承認が必要か?どのログが存在するか?どの緊急制限が適用できるか?どのソーシャルエンジニアリング防御が従業員を保護するか?どの公的被害シナリオが練習されたか?答えは証拠であるべきであり、ブランドの自信ではない。

Twitter の2020年のインシデントは詐欺のために記憶されるべきだが、それに限定されるべきではない。詐欺は可視的なシグナルだった。根本的な問題は、プラットフォームの内部権限が虚偽の公的発言に変換されうることであった。それが起こるとき、プラットフォームは単に攻撃者の被害者ではない。欺瞞を信頼できるものにした制御システムの運営者である。真正な公的コミュニケーションは、そのシステムが次の攻撃者が信頼された声を借りようとする前に統治され、テストされ、制約されることに依存している。

追加の証拠境界

Twitter が従業員ツールの悪用を公的信頼の制御ミスマッチにした件について、追加の証拠境界は、確認された事実、証拠に基づく推論、未知の情報を分離することである。その分離が重要なのは、twitter 2020 account takeover control mismatch を含む出来事が、技術的問題、契約問題、または通信問題として、どの主体が話すかによって説明されうるからである。したがって、説明責任の分析は実用的な制御に戻らなければならない:誰が構成を変更でき、露出を制限でき、検出を加速でき、通知を承認でき、修復が影響を受けたユーザーに届いたことを証明できたか。

このレンズは、根本原因とトリガーイベントの注意深いテストを追加する。トリガーは、なぜイベントが特定の瞬間に可視化されたかを説明する。根本原因は、その瞬間の前に存在した設計、制御、ガバナンス、検証の選択に関する証拠を必要とする。依存関係、委任、変更ウィンドウ、契約、ログ、インセンティブなどの寄与条件は、企業の声明を完全な真実として扱ったり、可能性を確定した結論に変えたりせずに評価されるべきである。

同じ規律が検出失敗、対応失敗、復旧失敗にも適用される。公的記録は、シグナルがいつ見られたか、誰が行動する権限を持っていたか、どの顧客や規制当局に通知されたか、結論を強めたり弱めたりする追加の証拠を示すべきである。これらの要素が部分的である間、責任ある結論は追加の非難ではなく、責任、不確実性、および後の監査が検証すべきアイデンティティとアクセス制御のより正確なマップである。