Day 106 手法5: ハンズオン攻撃トレーニング Method 5: Hands-On Attack Training
[シリーズ構造] 柱D｜脅威の現実
セキュリティは、知識ではなく体験で身につく。攻撃を「学ぶ」のではなく「体験する」ことで、脅威は初めて現実になる。意図的に壊し、試す訓練が、設計・実装・運用の判断を変えていく。
▶ シリーズ概要： シリーズ全体マップ：人間のしなやかさ ― サイバー判断力のために
▶ 柱E｜脅威の現実 関連記事：
- Day 59 | 攻撃者をステークホルダーとしてデザインする
- Day 60 | セキュリティトレーニングが失敗する理由
- Day 61 | 経験の科学
- Day 61 | すべてを変えた数字
- Day 63 | AIが攻撃者になる時
- Day 63 | 攻撃を学ぶことの倫理
- Day 65 | 理論から実践へ
- Day 66 | 手法 1: レッドチェア・テクニック
- Day 67 | 手法2: ユースケースの隣に、アビューズケースを置く
- Day 68 | 手法3 : STRIDE
- Day 105 | 手法4：セキュリティ・チャンピオン・ネットワーク
- Day 106 | 手法5: ハンズオン攻撃トレーニング
手法5: ハンズオン攻撃トレーニング
Day 60 を覚えていますか。研究結果ははっきりしていました。知識は行動を変えない。経験が変える。
「水の安全」を いくら本で読んでも泳げるようにはならない。泳げるようになるのは、水に入ったときだ。
セキュリティも同じ。
だから私たちは、チームに「攻撃者はこうする」と説明する代わりに、実際にやってもらう。安全に、意図的に、そして支援つきで。
ここで全部がつながる。
自分が"うっかり"書いたバグを自分で突いてしまった瞬間。
インジェクションがどれだけ簡単かを目で見た瞬間。
API に制限がなくて、システムがあっけなく崩れるのを見た瞬間。
その瞬間、コンプライアンスが「納得」に変わる。
"やらされ感"が "確信"に変わる。
ハンズオン攻撃トレーニングの実装方法
文化と成熟度に合わせて、形式を選ぶ。
オプション A : CTF（Capture The Flag、キャプチャ・ザ・フラッグ）
チャレンジが好きなチーム向け。
- 脆弱な学習用アプリを使う（OWASP Juice Shop / OWASP WebGoat など）
- 脆弱性を見つけて悪用できたら "フラグ" を獲得
- デブリーフで結び直す：「これ、うちのコードベースではこういう形で出ます」
学びがゲームになる。でも、学ぶ内容は現実そのもの。
オプション B : 自分たちのコードを壊す
「自分ごと化」を最短距離でやりたいチーム向け。
- 各チームが"意図的に脆い機能"を作る
- 別チームがそれを壊しにいく
- そしてノートを交換する：なぜ脆かった？どこで判断を間違えた？どう直す？
いい意味で、へこむ。
そして、定着する。
人は、自分が壊したものを忘れない。
オプション C : レッドチーム / ブルーチーム
シミュレーションに耐えられる段階のチーム向け。
- 半分が攻撃（レッド）
- 半分が防御・検知（ブルー）
- そのあと役割を入れ替える
全員がこう言うようになる。
「ああ......だからログが大事なんだ」
トレーニング構成（90〜120分）
マラソンじゃない。制御された、再現可能な "体験" を回す。
- 導入（15分）
何を狙うか。なぜ重要か。現実だとどう起きるか。 - 悪用（45分）
壊す。攻撃する。落とす。 - 予防（30分）
二度と起きないように、防御的に書く。 - 振り返り（15分）
何が意外だった？
どんな前提が崩れた？
明日から何を変える？
振り返りは"任意"じゃない。
ここで学びが刺さる。
定期化する
年1回は、行動変容じゃない。
- Don't：年1の「セキュリティ研修の日」
- Do：四半期ごとに 90 分の攻撃ラボ
- Don't：全部を外部コンサルに丸投げ
- Do：Security Champions が社内で回す
攻撃トレーニングはショーじゃない。習慣だ。練習だ。
続けるほど、開発者はセキュリティチームに言われる前に、設計の段階で自分から脆弱性に気づき始める。
それがゴール。完璧なコードじゃない。予測的な気づきだ。
次に起きること
一度でも自分の手で"悪用"してしまうと、人は「善意前提の設計」をやめる。
代わりに、「悪意があっても壊れない設計」を始める。
それが adversarial thinking。敵から視線の思考。
それが human hardening。人間中心防御。
それが、シフトだ。
――――
[Series Structure] Pillar D | Threat Reality
Hands-on attack training lets teams safely simulate real attacker behavior, turning abstract threats into lived understanding. By breaking systems on purpose, people develop adversarial thinking that actually changes how they design, code, and operate.
▶ Series overview: Series Map - Human Flexibility for Cyber Judgment
▶ Other posts in Pillar E (Pillar D | Threat Reality):
- Day 59 | Design with Attacker as Stakeholder
- Day 60 | Why Security Training Fails
- Day 61 | The Science of Experience
- Day 62 | The Numbers That Changed Everything
- Day 63 | When AI Becomes the Attacker
- Day 64 | The Ethics of Learning to Attack
- Day 65 | From Theory to Practice
- Day 66 | Method 1 :The Red Chair Technique
- Day 67 | Method 2: Abuse Cases Alongside Use Cases
- Day 68 | Method 3: STRIDE
- Day 105 | Method 4: Security Champions Network
- Day 106 | Method 5: Hands-On Attack Training
Method 5: Hands-On Attack Training
If you remember Day 60, the research was clear. Knowledge doesn't change behavior. Experience does.
We don't learn to swim by reading a book on "water safety." We learn by getting in the water. Security is the same.
So instead of telling teams what attackers do, we let them try it--safely, intentionally, and with support.
This is where everything clicks: the moment someone exploits a bug they accidentally wrote, or sees how trivial injection can be, or watches a system fall over because nobody constrained resource consumption.
That's the moment conviction replaces compliance.
How to implement hands-on attack training
Pick the format that matches your culture and maturity.
Option A -- Capture the Flag (CTF)
For teams who like challenges and momentum.
Use deliberately vulnerable apps and turn learning into a scored hunt:
- OWASP Juice Shop (modern, challenge-based, tracks progress via a scoreboard)
- OWASP WebGoat (teaches by explaining the vuln, then "learn by doing," then mitigation)
Run it like this:
- Give teams "flags" for finding and exploiting specific issues.
- Debrief each flag with: "Here's exactly how this shows up in our codebase."
This turns learning into a game--but the consequences are real. (Just contained.)
Option B -- Break Your Own Code
For teams who want direct relevance, fast.
- Each team writes an intentionally vulnerable feature (in a sandbox/staged environment).
- Another team breaks it.
- Then you swap notes: Why was it vulnerable? What signal did the attacker follow? What would we change in the design and the implementation?
This is humbling in the best possible way.
No one forgets what they break.
Option C -- Red Team / Blue Team
For teams ready for simulation and shared empathy.
- Half the group attacks a staged environment.
- Half defends and detects.
- Then you switch roles.
Everyone walks away saying, "Oh. Now I get why logging matters."
The training structure (90-120 minutes)
We're not running a marathon. We're running a controlled, repeatable experience.
- Introduction (15 min)
What you're targeting. Why it matters. What it looks like in the wild. - Exploitation (45 min)
Break it. Attack it. Make it fall down. - Prevention (30 min)
How to code defensively so it doesn't happen again. - Reflection (15 min)
What surprised you?
What assumptions broke?
What will you do differently tomorrow?
Reflection is non-negotiable. That's where learning sticks.
Make it regular
Because once a year ≠ behavior change.
Don't: "Annual security training day."
Do: Quarterly 90-minute attack labs.
Don't: Outsource everything to consultants.
Do: Have Security Champions run internal sessions.
Attack training is not a spectacle. It's a practice.
Over time, developers start seeing vulnerabilities in their own designs before security ever mentions them.
That's the goal: not perfect code--predictive awareness.
What happens next
When people have personally exploited:
- a broken access control path (including IDOR-style "not my object" access)
- injection patterns (including SQL injection as a classic example)
- missing controls around resource consumption and rate limiting (the "we didn't constrain anything" failure mode)
...they stop designing systems that assume good behavior.
They start designing systems that survive bad behavior.
That's adversarial thinking.
That's human hardening.
That's the shift.
-----
References
Ajzen, I. (1991). The theory of planned behavior. Organizational Behavior and Human Decision Processes, 50(2), 179-211. https://doi.org/10.1016/0749-5978(91)90020-T
Bandura, A. (1986). Social foundations of thought and action: A social cognitive theory. Prentice-Hall.
Kolb, D. A. (1984). Experiential learning: Experience as the source of learning and development. Prentice-Hall.
Merritt, M., Hansche, S., Ellis, B., Sanchez-Cherry, K., Snyder, J. N., & Walden, D. (2024). Building a cybersecurity and privacy learning program (NIST Special Publication 800-50r1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-50r1
National Institute of Standards and Technology. (2003). Building an information technology security awareness and training program (NIST Special Publication 800-50). https://csrc.nist.gov/pubs/sp/800/50/final
OWASP. (2021). A01:2021 - Broken access control. https://owasp.org/Top10/2021/A01_2021-Broken_Access_Control/
OWASP. (2021). A03:2021 - Injection. https://owasp.org/Top10/2021/A03_2021-Injection/
OWASP. (2023). API4:2023 - Unrestricted resource consumption. https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/
OWASP. (n.d.). OWASP Juice Shop. https://owasp.org/www-project-juice-shop/
OWASP. (n.d.). OWASP WebGoat. https://owasp.org/www-project-webgoat/
Puri, N., & Hall, K. (2014). When knowledge is not enough: Changing behavior to change vaccination results. Human Vaccines & Immunotherapeutics. https://pmc.ncbi.nlm.nih.gov/articles/PMC4975060/
Shaffer, V. A. (2017). Advocating for behavior change with education. American Journal of Lifestyle Medicine. https://pmc.ncbi.nlm.nih.gov/articles/PMC6124997/