2023年感謝祭のセキュリティインシデント

 (blog.cloudflare.com)
1 ポイント 投稿者 GN⁺ 2024-02-02 | 1件のコメント | WhatsAppで共有

2023年感謝祭のセキュリティインシデント

  • 2023年11月23日の感謝祭の日に、Cloudflareは自社ホスティングのAtlassianサーバー上で脅威アクターを検知した。
  • セキュリティチームは直ちに調査を開始し、脅威アクターのアクセスを遮断した。
  • 11月26日には、独立した分析のためにCrowdStrikeのフォレンジックチームを招いた。
  • CrowdStrikeは調査を完了し、Cloudflareはこのブログポストを通じてセキュリティインシデントの詳細を共有した。
  • Cloudflareの顧客データやシステムは、このインシデントの影響を受けていないことが強調されている。
  • アクセス制御、ファイアウォールルール、Zero Trustツールを用いたハードウェアセキュリティキーの強制適用により、脅威アクターの水平移動能力は制限された。

「コードレッド」復旧および強化作業

  • 脅威アクターが環境から排除された後、セキュリティチームは社内全体で必要なすべての人員を動員し、侵入調査とアクセス遮断を完了した。
  • 11月27日から、技術スタッフを動員して「コードレッド」と呼ばれるプロジェクトに集中した。
  • このプロジェクトの目標は、環境内のすべての制御を強化・検証し、将来の侵入に備えるとともに、脅威アクターが環境へ再アクセスできないようにすることだった。
  • CrowdStrikeは、脅威アクターの活動範囲と程度について独立した評価を実施した。

攻撃タイムライン

  • 攻撃は10月のOktaのセキュリティ侵害から始まり、脅威アクターは11月中旬から、Okta侵害で入手した認証情報を使ってCloudflareのシステムを標的にした。
  • 10月18日のOkta侵害により、脅威アクターは認証情報にアクセスした。
  • 11月14日から、脅威アクターはシステム探索とアクセスの試行を開始した。
  • 11月15日には、Atlassian JiraとConfluenceへのアクセスに成功した。
  • 11月16日には、Atlassianのユーザーアカウントを作成した。
  • 11月17日から20日までは、Cloudflareのシステムにアクセスしなかった。
  • 11月22日には、持続的アクセスのためにSliver Adversary Emulation Frameworkをインストールした。
  • 11月23日には、セキュリティチームが脅威アクターの存在を検知し、アクセス遮断を開始した。

結論

  • このインシデントは国家支援型の攻撃者によるものと推定されており、Cloudflareはその影響を限定し、将来の攻撃に備えるために多大な努力を払った。
  • Cloudflareのエンジニアリングチームは、システムを保護し、脅威アクターのアクセスを理解し、緊急の優先課題に対処するとともに、全体的なセキュリティを改善するための計画を策定した。
  • CrowdStrikeは独立した評価を実施しており、最終報告書の完成後、Cloudflareは内部分析と侵入への対応について十分な自信を持って、このブログポストを公開した。

GN⁺の見解:

  1. このインシデントは、CloudflareのZero Trustアーキテクチャの重要性を強調している。これはシステム間の分離を通じて、組織全体への脅威の拡散を抑える形で機能する。
  2. Cloudflareの迅速な対応と、「コードレッド」プロジェクトを通じたセキュリティ強化の取り組みは、企業がサイバーセキュリティ脅威にどう対応するかについての示唆を与えている。
  3. この記事は、サイバーセキュリティ事故が発生した際に組織がどのように対応し、どのような措置を取るべきかを理解するうえで有益な事例となっている。

関連記事

1件のコメント

 
GN⁺ 2024-02-02
Hacker Newsの意見

  • Cloudflareのブログ記事のような対応が信頼を与える理由

    • Cloudflareは完璧ではないが、工学的な思考方式と深刻な問題への対処により信頼できる。
    • ブログ記事への感謝の表明。

  • データ流出の問題点

    • データは一度流出すると、永久に制御不能になる。
    • 事件後の強化作業と対話は重要だが、すでに起きたことを防ぐことはできない。

  • Oktaシステムのセキュリティ問題

    • Oktaシステムが二度目の被害を受けたことへの懸念。

  • ローテーションされていないサービストークンとアカウント

    • 使用されていないと誤って信じられていたため、ローテーションされなかった。
    • なぜ完全に取り消されなかったのかという疑問。

  • 攻撃者の限定的なアクセスと対応措置

    • 攻撃者のアクセスは限定的だと考えられていたが、すべての本番環境の認証情報をローテーションし、システムをフォレンジック分析し、再イメージ化および再起動するなどの広範な措置を取った。
    • ブラジルのデータセンターにある新しいシステムへのアクセス試行は失敗し、機器は検査と交換のためにメーカーへ返送された。

  • 攻撃者の目的の分析

    • Wikiページ、バグデータベース、ソースコードリポジトリの分析を通じて、Cloudflareのグローバルネットワークアーキテクチャ、セキュリティ、管理情報を探していたように見える。

  • CloudflareのBitBucket利用への驚き

    • CloudflareがBitBucketを使用しているという事実への驚き。

  • 使用されていない認証情報の扱い

    • 使用されていないと考えられていた認証情報については、ローテーションではなく削除が適切だったはずだ。

  • Okta事件後の認証情報ローテーションとハニーポットの提案

    • 流出した認証情報をローテーションした後、攻撃者の行動を観察するためにハニーポットを使うことを提案。

  • ゼロトラスト(ZT)への疑問

    • 単一のベアラートークンでアプリケーションにアクセスできることは、ゼロトラストの定義に合致しないと指摘。

背景知識: Cloudflareはインターネットセキュリティサービスおよび分散ドメインネームサーバーサービスを提供する企業であり、Oktaはアイデンティティおよびアクセス管理サービスを提供する企業である。ゼロトラストはネットワークセキュリティのモデルの一つで、基本的にすべてのユーザーとデバイスを信頼せず検証するアプローチを指す。