๐Ÿšจ Problem โ€” Cumulative: draws on all of Unit 2

E-Commerce Enrichment

The Unit 2 Cyber Case, revisited: pen testing what you built ย ยทย  Approx. 3โ€“4 class days

StarringIdentify โ†’ Detect โ†’ Protect โ†’ Respond (no Recover)

๐ŸŽฌ The Cyber Case, Revisited

Back in Project 2.1.3, your cyber team designed the network architecture for a company called Bikes, Boards, and Beyond โ€” deciding where public data should live, where the sensitive customer and employee data needed to stay hidden, and how the whole thing would hold together under a defense-in-depth strategy.

That architecture has now actually been built. And your team has just been hired again โ€” this time as an outside security firm, brought in to pen test the very system you designed. Nobody knows the intended architecture better than you do, which makes you exactly the right team to find out whether it actually holds up.

Every activity and project since 2.1.1 has been building toward this exact test.

๐Ÿงญ What You're Actually Doing

This is a Problem, not an Activity or a Project โ€” fully cumulative, drawing on everything from this unit at once. You and your cyber team are conducting an authorized, ethical penetration test of the Bikes, Boards, and Beyond site and its web server โ€” testing for four exploit types: command execution, SQL injection, reflected XSS, and stored XSS.

The outcome is a report, not a fixed system. You are not authorized to modify the customer's live site โ€” your deliverable is a thorough, accurate pen test report documenting exactly what you found and exactly what you recommend, using the same high/medium/low security script comparisons you've studied throughout this unit.

Everything this problem pulls from

๐Ÿ’ก Tips & Tricks for Moving Forward

Confirm the architecture before you try to break it
Start with Identify โ€” verify the public/private data separation you designed back in 2.1.3 is actually holding up, before hunting for exploits.
You're writing a report, not fixing the site
This is the single most common mix-up in this problem. The deliverable is a thorough, accurate pen test report for the customer โ€” you are not authorized to modify their live system.
Reuse the four security scripts from Bank of Virgil
The high/medium/low security coding comparisons from earlier in this unit are your template for what a real fix looks like โ€” match each exploit you find to the correct one.
Authorization is what makes this legal
Pen testing is only ethical when it's fully disclosed ahead of time and specific people are explicitly authorized to perform it. Keep that framing in your report's language too.
The Lifecycle won't go in order here โ€” and that's fine
As a pen tester you'll bounce between Identify, Detect, and Protect, then Respond with your report. There's no Recover โ€” nothing is actually broken, so there's nothing to restore.

โœ… Self-Check Before You Roll On

Check off each item as you get there. These are not grades โ€” they are your own signal.