レッドチームのエンゲージメントルール
このページは、レッドチームが実施するすべての作業に適用される一般的なルールを概説します。個々のオペレーションには、計画段階で定義された追加のルールが含まれる場合があります。
私たちのチームと活動内容について詳しくは、一般的なハンドブックページを参照してください。
スコープ内のシステム
一般的なシステム
一部のシステムは、任意のタイプのレッドチームオペレーション中にアクセスする前に、GitLab 法務からの特別な承認が必要です。GitLab チームメンバーは、そのリストをこちらで確認できます。
GitLab が公式の業務目的で使用するサードパーティシステムもスコープ内とみなされますが、これらはしばしばシステムオーナーからの許可が必要です。この許可は必要に応じて取得されます。
GitLab が管理するその他すべてのシステムは、すべてのタイプのレッドチームオペレーションのスコープ内です。
チームメンバーは、こちらで Issue を開くことで、システムを私たちのスコープから除外するようリクエストできます。
ステルスオペレーション
ステルスオペレーションには慎重な計画が必要です。ロジスティクスフェーズ中に、目的を提案し、模倣する脅威の概要を述べ、このテンプレートで承認を求めます。
以下のセクションには、すべてのステルスオペレーションに適用される一般的なルールが含まれています。
事前承認
- 少なくとも 1 階層の SIRT リーダーシップからの承認が必要です。これは SIRT マネージャーから始まり、CISO まで上がります。
- レッドチームを担当するシニアマネージャーからの承認が必要です。
- ロジスティクスフェーズで「信頼された参加者」として定義された全員からの承認が必要です。
- 承認はすべてのステルスオペレーションのロジスティクスフェーズの一部として提供されます。承認のスコープは、承認が記録されるロジスティクス Issue の一部として含まれます。
開示リクエスト
- アクティブなステルスオペレーションには、すべての信頼された参加者が招待される専用の Slack チャンネルがあります。
- プライベートな
#is-this-the-redteamチャンネルは、セキュリティディレクター以上のレッドチーム活動について問い合わせるためにいつでも利用できます。 - マネージャー以上はこのテンプレートを使用して Issue を提出し、レッドチーム活動の開示をリクエストできます。このテンプレートには、これらの Issue がどのように処理されるかの詳細が含まれています。
- チームメンバーが、これらの指定されたチャンネル外で、特定の活動または IoC がレッドチームに属しているかどうかを尋ねる場合、私たちは「これはレッドチームですか？」に文書化されたプロセスに従います。
- 指定された Slack チャンネルの 1 つで尋ねられた場合、以下が起こります:
- 確定的な回答が提供できるまで、進行中のステルス活動は一時停止されます。
- レッドチームではなかった場合、リクエスト者は問題が解決されるまですべての活動を一時停止し続けるよう依頼することもできます。
- レッドチームがステルスオペレーションを実施していた場合、次に何が起こるかについて文書化された計画（「ロジスティクス」フェーズから）があります。いくつかの例:
- オペレーションはステルスのまま継続され、信頼された参加者がエスカレーションがオペレーション目標と一致するように支援します。
- オペレーションは内部で開示され、セキュリティ制御と検知メカニズムをさらに検証するためにオープンに継続されます。既知のレッドチーム活動についてはインシデント対応が中止されます。
- オペレーション全体は内部で開示されませんが、信頼された参加者がチームに、特定の活動または IoC がレッドチームに属することを知らせます。関連するシステムは「仮想的に封じ込められた」とみなされ、レッドチームはそれらのシステムへのアクセスを放棄します。
- オペレーションは完全に終了します。
- 私たちは常に組織のセキュリティとチームメンバーの幸福を優先するべきです。公式チャンネル外で、これらの質問に迅速に判断を下し回答する必要がある場合があります。
SIRT との協力
GitLab では、レッドチームとブルーチームには共通の目標に向けて協力的に取り組んできた長い歴史があります。本質的に敵対的な役割を演じているにもかかわらず、私たちはチーム間で非常に高いレベルの信頼と尊敬を維持したいと考えています。
以下に具体的なルールを定義しますが、一般的に、私たちは仕事において常に親切で思いやりを持つことを忘れたくありません。何かが GitLab のバリューと矛盾するように感じる場合、私たちは正確に何をしているのか、なぜそれをしているのかを再評価する必要があります。
- レッドチームは、チームの正当なユーザーアカウントの下で、公式の会社のコミュニケーションチャンネルを使用して SIRT を意図的に気を散らしたり誤導したりしません。
- レッドチームは、通常の業務時間外にオンコールインシデントをトリガーすることを避けるよう努めます。一般的に、これは、世界的に週末または休日である時間帯には攻撃技術を実施しないことを意味します。オペレーションの目標が業務時間外プロセスを特にテストすることである場合、これは承認される必要があります。
- SIRT は、特定のレッドチームリソースを先回り的にモニタリングしません。アラートまたは標準的なインシデント対応手順がこれらのリソースにつながる場合、もちろん SIRT が調査することができます。このルールの意図は、非現実的な方法でレッドチームオペレーションを早期に発見することを避けることです。これらのリソースには以下が含まれます:
- レッドチームメンバーのラップトップ
- Google Cloud 内のレッドチームのグループプロジェクト
- GitLab.com 上のレッドチームのプライベートプロジェクト
- レッドチームのプライベート Slack チャンネルとダイレクトメッセージ
一般的な安全ガイドライン
以下のセクションは、すべてのレッドチームオペレーションに対する一般的なルールを概説します。
チームメンバーのプライバシー
セキュリティ専門家として、私たちは現実世界の攻撃を模倣する精神を維持しながら、すべてのエンゲージメントで倫理的であることを目指しています。私たちは GitLab の従業員のプライバシーを尊重し、エンゲージメント中に従業員プライバシーポリシーに記載されているガイドラインに従います。
クリティカルな脆弱性とエクスプロイト
レッドチームはエンゲージメント中に脆弱性を発見し悪用することがあります。これらの悪用を検知し対応する現実的な機会を提供したいので、これらは常にすぐには SIRT に報告されるわけではありません。
以下の基準を満たす脆弱性が露出された場合、私たちは Issue を文書化し、すぐに SIRT を関与させるプロセスに従います:
- 脆弱性が公開されている
- 脆弱性が現実的に悪用可能である
- 脆弱性の悪用が事業運営に影響を及ぼし、かつ／または機密データを露出する
緊急事態
レッドチームのオペレーションは、本番システムと顧客活動への影響を避けるために慎重に計画されています。しかし、事故が発生し、本番システムが予測不能な方法で応答する可能性があります。
本番への影響を疑った場合、私たちは以下を行います:
- 影響に関連するすべての活動を一時停止する
- オペレーションの「信頼された参加者」として定義された全員に直ちに通知する
- セキュリティインシデントが必要な場合、SIRT を関与させる
- インフラストラクチャインシデントが必要な場合、オンコール SRE を関与させる
- インシデントの解決後、適切な根本原因分析を実施する
一般的な技術
このセクションでは、レッドチームによって一般的に使用される技術について説明します。これらのリストはすべてを網羅しているわけではありませんが、レッドチームが行う可能性のあること、または行わない可能性のあることについて、チームメンバーに合理的な期待を提供することを目的としています。
これらのオペレーションについて質問や懸念があるチームメンバーは、#g_security_redteam Slack チャンネルでお問い合わせください。
機会主義的攻撃技術
機会主義的攻撃で使用される技術には以下が含まれます:
- ポートスキャン。
- ウェブクローリングとスクレイピング。
- 手動または自動の脆弱性スキャン。
- 脆弱なソフトウェアまたはインフラストラクチャに対する手動または自動のエクスプロイト試行。
- 誤設定の悪用に対する手動または自動の試行。
- 手動およびプログラム的に GitLab API をクエリする。
- www.gitlab.com 上のあらゆるパブリックプロジェクト、Issue、スニペットなどへのアクセスとクローン。
- ロギングプラットフォームなど、一般に公開することを意図した他のデータへのアクセス。
- 一般的かつデフォルトの認証情報で、公開された任意の管理インターフェイスにログインを試みる。
- パブリックな場所で見つかった GCP サービスアカウント、SSH キー、API キーなどの認証情報データの検証を試みる。
- GitLab が管理していないものを含む、あらゆるソースからオープンソースインテリジェンス (OSINT) を収集する。
ステルスオペレーション技術
ステルスオペレーション中、レッドチームは以下を行うことがあります:
- 侵害が発生したと想定してオペレーションを開始すること。これは、チームが公開されていないリソースに対して何らかのレベルのアクセスを持つことを意味します。
- 任意の GitLab 管理プラットフォーム（GitLab.com、Google、Slack、Zoom など）上のチームメンバーアカウントへのアクセスを試みる。
- ドライブバイ攻撃、添付ファイル付きスピアフィッシング、サプライチェーン侵害などの技術を使用して、会社支給のラップトップへのアクセスを試みる。この技術に対する具体的な除外事項は内部ハンドブックに記載されています。
- 侵害されたシステム上で認証情報データを検索する。これには環境変数、設定ファイル、シェル履歴などが含まれます。
- 任意の GitLab 管理リソース上で発見された認証情報データ（パスワード、アクセストークン、SSH キーなど）を使用して、任意のチームメンバーとして認証する。
- GitLab のクラウド環境内の任意のリソースへのアクセスを試み、それらのリソースを使用してクラウド内で権限を昇格させ、横方向に移動する。
- GitLab が所有および管理する任意のシステムで、脆弱性を悪用し、セキュアでない設定を悪用する。
- 以下のような技術を使用してソーシャルエンジニアリングを実施する:
- 偽の身元を作成し、メール、Slack、Zoom、GitLab.com の Issue やマージリクエストなどの GitLab 管理チャンネル上でチームメンバーと交流するためにそれらを使用する。
- 私たちのテックスタックの正当なコピーに見えるウェブサイトを作成し、それらの GitLab 管理チャンネル上でチームメンバーに URL を送信し、それらのサイトに入力された認証情報を収集し、正当なアプリケーションでそれらを再利用しようとする。
- それらの GitLab 管理チャンネル上でカレンダー招待や会議リクエストを送信し、それらの会議に参加したり提供された番号に電話をかけたりするチームメンバーと音声またはビデオ通話で話す。
- GitLab チームメンバー、ベンダー、顧客、パートナーなどになりすまし、ソーシャルエンジニアリングの試みが個人のデバイスやサービスを直接侵害しない、メール、ビジネス電話番号、認証プロバイダー、求人投稿などの GitLab 所有または管理サービスを対象とする他の形式のソーシャルエンジニアリング。
- 依存関係の混乱、パイプラインインジェクション、悪意のあるコードコミットなどのサプライチェーン関連の攻撃技術を実行する。
GitLab のチームメンバーで、日々の業務の過程でステルスレッドチームオペレーションを発見したと疑う場合は、まずマネージャーに報告し、「これはレッドチームですか？」セクションを参照してください。
現時点で、レッドチームは以下を 行いません:
- GitLab チームメンバーの自宅内のリソース（ワイヤレスネットワーク、非 GitLab マシンなど）へのアクセスを試みる。
- 所有者からの明示的な許可なしに、任意のデバイスのカメラまたはマイクへのアクセスを試みる。
- GitLab の雇用関係に関連付けられていない個人のメールアドレスやソーシャルネットワークを標的にしてチームメンバーをソーシャルエンジニアリングしようと試みる。
- GitLab の業務関連の目的で公開されている番号の場合を除き、チームメンバーの個人電話番号に直接電話または SMS を送信する。
- 任意のチームメンバーのウェブブラウジング履歴へのアクセスを試みる。
- GitLab によって厳密に業務関連で管理／所有されていないものへのアクセスを試みる。
レッドチーム攻撃技術の監査
レッドチームは、私たちが実施した攻撃技術、タイムスタンプ、ソース IP アドレスなどの具体的な詳細を含むオペレーターログを維持しています。これらのサブセットはオペレーションの最終レポートに含まれますが、侵害された可能性のあるアカウントやラップトップの具体的な名前を表示しないように編集されます。
オペレーション中にチームメンバーのアカウントまたはラップトップが侵害された場合、レッドチームはすべての関連活動の具体的な詳細をそのチームメンバーと共有します。これにはオペレーターログが含まれます。レッドチームは、チームメンバーが希望する場合、これらのログを説明するために同期的に会うことを申し出ます。
これらの手動ログの他に、私たちの活動は、実際の悪意のある活動を調査するために GitLab が持つのと同じ機能を使用して監査できます。例えば、私たちが「侵害された」ラップトップ上で実行する可能性のあるコマンドは、エンドポイント検知応答 (EDR) ソフトウェアによってキャプチャされアーカイブされる必要があります。
bfd74782)