thinking-red-team

レッドチーム

評価の許可を得ているシステムの敵対的なセキュリティレビューです。第三者に攻撃される前に攻撃しますが、実際に突破できるものだけを報告してください。すべての指摘には、具体的な悪用経路と、提案した修正でその経路を塞げることの確認が必要です。

使用する場面

• 自分が管理し、調査の許可を得ているコード、認証、認可、API、データ処理、インフラのセキュリティレビュー。
• 認証、金銭、個人データ、特権操作を扱うシステムのリリース前の強化。
• 特定の脆弱性クラス（インジェクション、XSS、IDOR、認証バイパス、SSRF、秘密情報の漏えいなど）が、実際の経路で存在するかの確認。
• スキャナーが何も検出しなかったことだけでなく、主張されている制御が実際に攻撃を阻止するかの検証。

使用しない場面

• 対象を攻撃する許可がない場合 — 中止してください。所有していないシステムや、書面によるテスト許可を得ていないシステムを調査してはいけません。
• 再現可能な悪用経路を伴わない、推測に基づく「ベストプラクティス」の指摘 — 除外してください。指摘事項には該当しません。
• 計画、戦略、意思決定のストレステスト — プレモーテム（計画がどう失敗するか）またはスティールマン（意思決定に反対する最も強い論拠）を使用してください。
• セキュリティ上の目的がないアーキテクチャのレジリエンス評価 — systems または pre-mortem を使用してください。
• スキャナー出力だけのレポート — パターンは手がかりです。レッドチームには悪用経路が必要です。
• セキュリティ以外の根本原因や仮説の特定 — scientific-method または five-whys-plus を使用してください。

手順

1. 許可と目的を確認します。 対象、許可された範囲、対象外の資産、成功条件（例：未許可のデータ読み取り、権限昇格）、停止条件を明示します。許可が不明確な場合は、拒否するか範囲を絞ります。
2. 脅威モデルを構築します。 現実的なアクセス条件に基づき、攻撃者のプロファイル（匿名の外部ユーザー、認証済みユーザー、特権を持つ内部関係者）とその目標を挙げます。行為者と目標を伴わない攻撃はノイズです。
3. 攻撃対象領域をマッピングします。 入口と信頼境界を列挙します。公開エンドポイント、認証フロー、API、アップロード、管理画面、ジョブ、Webhook、秘密情報、データストアなどが含まれます。露出状況と必要な権限を記録します。
4. 悪用経路をたどります。 価値の高い対象ごとに、具体的な不正利用を試みます。入力の改ざん、認可の不備、トークンやセッションの不正使用、インジェクション、SSRF、IDOR、Mass Assignment、レート制限の回避、秘密情報の漏えいなどです。正確な手順と観測された挙動を記録します。
5. 捏造防止チェックを適用します。 入口 → 順序立てた手順 → このコード／設定で実現した影響、という一連の経路を最後まで確認できた場合に限り、指摘事項として残します。経路が未完成の場合は「参考情報」として掲載せず、除外します。
6. 深刻度を評価し、防御の回避を試みます。 影響度と悪用可能性を評価します。関連する制御（レート制限、入力検証、セッション確認など）ごとに、現実的な回避を試し、機能したか突破されたかを記録します。
7. 緩和策を提示して検証します。 残した指摘事項ごとに、最小限の具体的な修正を示し、その経路が塞がれたことを再テストする方法を記載します。悪用の前提条件を取り除く修正を優先します。対象範囲内の調査が完了するか、許可または予算が尽きた時点で終了します。指摘事項がゼロでも問題ありません。

出力

Target/scope: <in | out | goal | authorization>
Threat model: <actors, access, goals>
Attack surface: <entry points + trust boundaries>
Findings (only complete paths):
  - Title | Severity
    Entry: <endpoint/param/file>
    Steps: <1..n>
    Impact: <realized effect>
    Bypass attempts: <control → result>
    Mitigation: <minimal fix>
    Re-test: <how to confirm closed>
Summary: <kept count; dropped speculative count>

検証

• 入口、手順、または実現した影響が欠けている指摘事項は反証します。「脆弱性がある可能性がある」は指摘事項として扱いません。
• 許可された範囲内で攻撃対象領域を調べ尽くした場合、または再テストで緩和策が経路を塞いだと確認できた場合は終了します。
• 過剰適用を防ぐための注意：ベストプラクティスの羅列で内容を水増ししないでください。セキュリティ以外の計画批評にこのスキルを使用しないでください。許可なく攻撃してはいけません。