Twitter、内部ツール悪用は公共信頼の制御ミスマッチ

概要

• 2020年7月の Twitter アカウント乗っ取り事件は、内部サポート制御の問題を公共の信頼イベントに変えた。なぜなら、侵害された内部アクセスにより、攻撃者が知名度の高いアカウントから投稿できたからだ。
• 公開記録には、Twitter の企業アップデート、ニューヨーク州金融サービス局（NYDFS）の調査、司法省（DOJ）の訴追記録、SEC（証券取引委員会）のリスク開示、FTC（連邦取引委員会）のガバナンスに関するコンテキスト、Coinbase の被害軽減措置、および攻撃に関するセキュリティ報道が含まれる。
• 制御に関する問いは、攻撃者がどのようにアクセスを取得したかだけではない。Twitter が、特権的な従業員ツールが制限され、監視され、再設計され、アカウントレベルの権限がもたらす公共の結果に見合ったものであることを証明できたかどうかだ。
• 責任は分散していたが、対称的ではなかった。攻撃者とソーシャルエンジニアが直接的な悪用を引き起こした。Twitter は内部ツール、従業員のアクセス、認証、トレーニング、監視、著名アカウントの保護、インシデント対応、パブリック通知を管理していた。
• 持続的な教訓は、ソーシャルプラットフォームのサポートツールは公共インフラとして統治されなければならないということだ。内部制御が公共の発言を書き換えることができる場合、それらは単なるバックオフィスツールではない。

大衆は発言を見たが、攻撃者は制御プレーンを見ていた

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

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

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

ミスマッチは簡単に言い表せる。大衆はアカウント所有者に意味を紐付ける。プラットフォームは従業員とツールに操作的な権限を与える。従業員・ツール層が公共の信頼層よりも弱い場合、制御システムがそれを保証できないところで、大衆は真正性を見ることになる。Twitter ハックは、混乱の数時間の間にそのミスマッチを可視化した。

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

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

ソーシャルエンジニアリングはしばしば人間の弱点として論じられる。Twitter の記録においては、それはシステム設計のテストとして扱われるべきだ。従業員が標的だったが、プラットフォームは、機密アクセスを持つ従業員の数、ツールが使用される条件、必要な認証、ツール使用に関する監視、異常な要求に対するワークフロー、そして従業員の資格情報が悪用された場合の影響範囲を選択していたのだ。

NYDFS のレポート概要を伝えるプレスリリースは、攻撃の深刻さと、大規模ソーシャルメディア企業に対するより強力なサイバーセキュリティ規制の必要性を強調した。このレポートの詳細が有用なのは、「従業員が騙された」で終わらず、なぜ攻撃者が従業員のアクセスを公共の規模でのアカウント乗っ取りに転換できたのかを問うているからだ。

これは正しい説明責任の枠組みだ。企業はソーシャルエンジニアリングのリスクを完全に排除することはできないが、ソーシャルエンジニアリングをより有用性の低いものにすることはできる。特権アクセスを減らし、より強力な認証を要求し、サポートツールを分割し、異常な操作を監視し、リスクの高いアカウント変更には二重管理を義務付け、機密性の高い操作にはレート制限を設け、ジャストインタイムの承認を求め、追加の制限で著名アカウントを保護し、従業員に不審な電話をエスカレーションするよう訓練することができる。それぞれの設計選択は、一度の成功した騙しが公共の悪用になる可能性を減らす。

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

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

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

これらの問いは、議論を非難から制御へと移す。それらは欺瞞を許すものではない。それらは、プラットフォームが欺瞞をあまりにも強力にしてしまったかどうかを問うているのだ。

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

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

司法省（DOJ）がアーカイブした、Twitter ハックにおける役割で3名が起訴されたという発表は、法執行の対応を記録している。その後の SDNY（ニューヨーク南部地区連邦検事局）の発表で、ジョセフ・ジェームズ・オコナーに対する5年の実刑判決が説明されており、この事件がより広範なサイバー犯罪の記録の一部であり続けたことを示している。刑事責任は重要だが、プラットフォームガバナンスの問題を解決するものではない。プラットフォームは、ハイリスクなアカウントが内部ツールの悪用からどのように保護されるかを示す必要が依然としてあった。

著名アカウントの保護には、バッジや公共の知名度以上のものが含まれるべきだ。それは異なる管理ルールを意味するべきだ。センシティブなアカウントは、メールアドレスの変更、電話番号の変更、パスワードリセット、セッションの無効化、または投稿制限に二重の承認を必要とするかもしれない。内部ツールがそれに触れる際に、より強力なアラートをトリガーするかもしれない。単一のサポートアクションでは完了できない、強化された回復パスを持つかもしれない。突然の詐欺文言や支払いアドレスパターンを監視するかもしれない。

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

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

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

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

即時のペイロードは暗号通貨詐欺であり、いくつかの対策はプラットフォームの外で行われた。Coinbase は後に、詐欺アドレスへのビットコイン送金を1000人以上の顧客に対してブロックしたと発表した。この記録は重要だ。なぜなら、プラットフォームインシデントが隣接システムに義務を生み出すことを示しているからだ。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 が一部のアカウントのアクティビティを制限したとき、それは調査中に害を減らすために緊急制御を使用していた。そのような制御は鈍器だ。追加の詐欺投稿を防ぐことができるが、急速に進展する公的イベントの最中に、正当なアカウント所有者を沈黙させることもある。そのトレードオフが、緊急制限を即興のパニックボタンではなく、公共制御の手段として扱うべき理由だ。

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

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

第三の問いは説明可能性だ。ユーザーは、プラットフォームがいつ緊急制限を課しているか、そしてなぜかを知るべきだ。アカウント所有者は、どのようにして信頼された制御を取り戻すかを知るべきだ。一般大衆は、疑わしい投稿を無視すべきかどうかを知るべきだ。規制当局は、制限がユーザーを保護したのか、それとも単に評判の損害を限定したのかを知るべきだ。それには、すべての技術的詳細を露出する必要はない。それは原則に基づいた記録を必要とする。

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

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

インシデント後のレビューは、演習を通じて緊急制限をテストすべきだ。著名アカウントに対する内部ツールの悪用をシミュレートする。アカウントクラス全体での協調的な詐欺投稿をシミュレートする。ニュースイベント中の従業員資格情報の漏洩をシミュレートする。誰が制限を承認できるか、誰がそれを伝えるか、アカウント所有者がどのようにサポートされるか、詐欺パートナーにどのように通知されるか、ログがどのように保存されるか、そして制限がどのように解除されるかを問う。演習は、製品、法務、ポリシー、エンジニアリング、トラストアンドセーフティ、サポート、コミュニケーション、そしてエグゼクティブの引き継ぎを露呈すべきだ。

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

アカウント所有者は回復記録を必要とした

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

回復記録は、アカウント所有者が独自の構成員を持っているため重要だ。企業は顧客や投資家を安心させる必要があるかもしれない。公務員は虚偽の情報を正す必要があるかもしれない。ジャーナリストは情報源を保護する必要があるかもしれない。公人はフォロワーに詐欺に対して警告する必要があるかもしれない。取引所や金融サービスは詐欺対策チームと連携する必要があるかもしれない。プラットフォームの内部的な終結は、それらの当事者に必要な証拠を自動的に与えるわけではない。

記録にはタイミングも含めるべきだ。アカウントはいつ最初に触れられたか？詐欺コンテンツはいつ投稿されたか？それはいつ削除されたか？アカウントはいつロックされたか？制御はいつ復旧したか？所有者はいつ通知を受けたか？プライベート露出の質問はいつ解決したか？タイミングはしばしば、クリーンなインシデントノートと論争のある公的な物語との違いになる。

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

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

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

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

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

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

監査は拒否のサンプルも取るべきだ。従業員は、ペナルティなしに疑わしい要求を拒否できるか？サポートは奇妙な電話を迅速にエスカレーションできるか？緊急アクセスは本人確認までブロックできるか？企業は特権的なアクションが発生しなかったことを証明できるか？拒否の証拠は重要だ。なぜなら、多くのソーシャルエンジニアリング攻撃は緊急性を作り出し、拒否することが質の悪いカスタマーサービスのように感じさせることで成功するからだ。

その種の監査は狭いが、それはまさに公共の信頼が宿るところだ。公的なアカウントは可視的な成果物である。特権的な内部アクションは隠れた蝶番である。

公共の信頼はアップタイムのようにリハーサルされるべき

最後の Twitter の教訓は、公共の真正性の失敗は停止のようにリハーサルされるべきだということだ。プラットフォームは、内部ツールが虚偽の公共の発言を生み出した場合に何が起こるかを練習すべきだ：誰がアカウントを凍結するか、誰がユーザーに警告するか、誰が取引所や決済パートナーに連絡するか、誰がアカウント所有者をサポートするか、誰がプライベート露出の不確実性を説明するか。アップタイム演習は可用性を保護する。真正性演習は、ユーザーが可視的なアカウントをそもそも信じられるかどうかを保護する。

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

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

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

ソーシャルプラットフォームにとって、教訓は永続的だ。管理・サポートシステムは、公共の発言に影響を与えうる場合、公共安全システムとして設計されるべきだ。従業員のアクセスは最小化されるべきだ。ハイリスクなアカウントには特別な制御があるべきだ。ソーシャルエンジニアリングへの耐性はワークフローに組み込まれるべきであり、トレーニングだけに任せるべきではない。詐欺連携は迅速であるべきだ。公的告知は構造化され、永続的であるべきだ。インシデント後のレポートは、何が知られているか、何が変わったか、そして何が不確実であるかを区別すべきだ。

ユーザーにとって、教訓は心地よくない。認証済みまたは著名なアカウントは、その名前の人や組織がメッセージを入力したことの証明ではない。アカウントの真正性は、ユーザーセキュリティ、プラットフォームの内部統制、従業員アクセス、回復ワークフロー、インシデント対応を含む連鎖に依存している。その連鎖のほとんどは一般ユーザーには見えない。その不可視性こそが、プラットフォームの説明責任が重要である理由だ。

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

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