Chapter 34: Red Team, Purple Team, and Safe Control Testing

34.1 Why.

Welcome to Chapter 34.

I am Ravindra Bagale.

Raju had no engineering degree. He had a list of dramatic names and a wish to "try an attack" so the course would feel finished. Guru-ji closed the laptop until the wish left the room.

"Validation is a test of your control, not a performance," Guru-ji said. "A red team imagines an adversary's goal. A blue team defends and detects. A purple team sits them at one table so a hypothesis becomes a detection, a fix, and a regression test. If you do not own the system, you do not have a table. You have someone else's incident."

Raju still wanted steps. Guru-ji gave him a card instead. "Suppose we are Paytm or PayFast and the control is that a new admin role pages a human. The safe test is to create a lab admin role and see if the page arrives. Suppose we are Swiggy or Zomato and the control is that an unsigned image never runs. The safe test is to offer your own unsigned lab image and see it refused. Suppose we are Netflix and the control is that a canary rolls back when errors burn. You already did that without harming a stranger. Suppose we are Amazon and the control is that a sandbox role cannot read a production-shaped bucket. The safe test is the deny you saved in Chapter 33. Suppose we are Infosys and the client wants evidence the alert works. Evidence is the lab log line, not a story about a break-in. Suppose we are BHIM UPI or WhatsApp-shaped systems and someone asks you to phish a coworker as homework. The answer is no. Test the control you were hired to trust. Do not test people who did not agree, and do not write a recipe."

34.2 What.

Goals, not procedures. Adversary emulation means you name a goal an adversary might want: reach a secret, deploy an image, read another tenant's row, disable a log. You then ask which control should make that goal fail or become visible. This chapter stops at the goal and the control. It does not list steps that would achieve the goal against a weak system. Names of tactic families, such as those used in ATT&CK for initial access or credential access, are a vocabulary for the hypothesis. They are not a workbook. If a sentence starts to tell you how to steal, forge, or bypass, it does not belong in your notes.

Purple workflow. Write a hypothesis. "If a lab user is granted an admin role, alert A fires within ten minutes." Prepare the benign stimulus you are explicitly allowed to generate on your own lab: the grant, the failed login of a test account, the unsigned image, the synthetic bulk read of fake rows. Run it. Compare the alert to the hypothesis. If it missed, fix the rule or the log pipeline, then run the same benign stimulus again. File the result as a regression test so the next pipeline change does not silently delete the alert. That loop is purple teaming. It is also ordinary engineering.

Breach and attack simulation, as a concept. Some products replay many techniques in a lab to see whether sensors notice. The concept is coverage: which detections exist, which are noisy, which never fire. The safety rule is the same. The simulator runs only where the owner authorized it, against systems built for the test, with a stop time and a named human. A simulator pointed at a production payment path because a license was expensive is not validation. It is an outage you chose. In this course you do not need a simulator product. Your own fixtures are enough.

Classes of path, described by impact. A CI token that can deploy is a crown jewel because the impact is a signed-looking release you did not intend. The safe test is to use a lab token with no rights and confirm the deploy is denied, and to confirm a real lab deploy identity cannot also rewrite the audit log. A cloud role that can grant itself more roles is a design defect. The safe test is a policy unit test that such a grant is denied, not an exploration of how far a grant could go. A cluster role that can do anything in every namespace is a design defect. The safe test is the namespace deny from Chapter 32. Credential theft is a goal you design against with hardware-backed login, short sessions, and alerts on new admins. You do not practice theft. Supply-chain doubt is a goal you design against with signatures. The safe test is your unsigned image being refused.

Detection validation. For each alert you claim, keep a fixture. The fixture is a benign action plus the expected log fields: time, actor, action, object, result. Run the fixture after you tune the rule so you do not train a page that never comes. Run it after an upgrade of the log pipeline. A detection you cannot fire on purpose in a lab is a rumor. Chapter 22 built the pipeline. This chapter asks you to prove one rule still breathes.

After a fix. When you patch a control, the purple loop repeats. Hypothesis, benign stimulus, evidence, regression test. A fix without a retest is a hope. Attach the evidence to the exception or the ticket so Chapter 24's auditor sees a query, not a slogan. Retire detections that duplicate each other and add noise. Noise is how a real page gets ignored.

Authorization and lab boundaries. Written scope is part of the test. What systems, what dates, what you will not do, who can halt the work. In this course the scope is a lab you own and synthetic data. Production customer data is out of scope even if you work there, unless a real program with real rules says otherwise, and even then you do not turn that program into public notes. No scanning of companies. No surprise tests of coworkers. No purchased malware. No instructions traded as "samples." If a tool vendor's sample crosses into an exploit recipe, you do not copy it into the notebook.

From lesson to regression. The output of a purple exercise is a test that runs unattended. The pipeline rejects an unsigned digest. The policy test rejects a public bucket. The alert test fires on a lab grant and fails the drill job if no alert appears. Offensive curiosity that does not become a test will be repeated as heroics next quarter. Heroics do not scale. Tests do.

What this chapter refuses. It refuses exploit steps, payloads, phishing scripts, credential-dumping methods, and privilege-escalation how-tos. It refuses them in labs framed as practice against real companies. It refuses them in fiction that is actually a recipe. Safe control testing is already ambitious. Make the deny real. Make the alert real. Make the rollback real. That is the craft.

A teaching sample: a hypothesis card. Lab only.

hypothesis: granting lab-admin in account lab-1 emits alert ADMIN-GRANT within 10 minutes
stimulus: a lab break-glass role performs one grant, then removes it
expect: one alert, one ticket, no customer data involved
out of scope: any system not in lab-1, any person, any payload
regression: job test-admin-grant runs weekly against lab-1 only

Seminar notes. Raju brought a list of tactic names and wanted a story under each. Guru-ji allowed the names and took the stories away. A name such as credential access or lateral movement is a label for a goal. Your card holds the control that should make the goal loud or impossible, and the fixture that proves it. Under the name you write "lab grant triggers ADMIN-GRANT," not a method. If the line could be followed by a stranger against a company, delete the line. Purple work is a table. Red brings a goal. Blue brings telemetry. Both leave with a test. There is no prize for a shell prompt.

Breach and attack simulation, as a product category, claims to run many checks and draw a coverage map. The useful part of the claim is the map: which controls have a fixture, which alerts have never fired, which logs never arrive. You can draw that map with a spreadsheet and the labs you already ran. You do not need to import a library of techniques to learn the habit. If a future job uses a simulator, the charter still rules. Own systems. Synthetic data. Stop time. Output is tickets and tests. A simulator in production because the lab was too much trouble is how validation becomes the incident.

Continuous validation means the fixture runs after the control can rot. Pipeline changes rot signature checks. Log-pipeline changes rot alerts. Policy exceptions rot denies. Schedule the benign stimulus. Fail the job if the evidence does not appear. That is how Chapter 25's SLA and Chapter 27's indicator stay honest. A monthly human hero who "checks the SIEM" will be on leave during the month that matters. The job will not be on leave.

CI and cloud and cluster paths are in scope as design questions. Can the build role rewrite the audit archive. Can the sandbox list production objects. Can a namespace admin bind a cluster role. Each question is answered by a deny you attempt with a lab identity that should fail, or by a policy unit test that evaluates a manifest without ever applying it to a live cluster. Unit tests of policy are the safest stimulus. Prefer them when a live apply would be hard to revert. When you do apply, the charter names the namespace and the revert step is written first.

Detection validation after a fix is the second half of every incident lesson. Chapter 23 ends with lessons. This chapter turns one lesson into a fixture so the lesson cannot evaporate. Keep the fixture kind. A failed login of a test user. A grant. An unsigned digest. A synthetic read of a fake table you filled. Not a phishing mail. Not a stolen-looking token. Not a payload. People are not fixtures. Coworkers are not fixtures. Customers are not fixtures. If the control is "our staff report suspicious messages," the test is a tabletop conversation with volunteers who were told, using a harmless note you wrote, and a check that the report channel works. You still do not write a persuasive lure.

The regression you keep is the real deliverable of the whole course's last chapter. A future Raju should be able to run one command, or merge one commit, and see the control breathe. Evidence goes to the catalog. The charter goes next to it. The notebook does not gain a private appendix of tricks. There is no private appendix. What you cannot say in the lab review does not belong in the lab. Own lab only, one more time, because this is the chapter where curiosity dresses up as thoroughness. Thoroughness is a green regression job. Curiosity that leaves the lab is out of scope.

A short close. The charter, the fixture, and the regression job are the whole craft. A fancy name for the team does not add a step. When you are unsure whether a sentence is a procedure, read it as if it were posted in public under your name. If you would not want a stranger to follow it against a company, it does not go in the notes. Keep the deny, the alert, and the revert. That is enough to finish the road.

34.3 How.

1. Write a one-page charter: lab name, dates, owner, and the sentence "no other systems."
2. Choose one control you already built: signed images, admin alert, private bucket, or least-privilege role.
3. Write the hypothesis in one sentence with the expected evidence.
4. List the benign stimulus and confirm it changes nothing you cannot revert.
5. Confirm the lab contains only synthetic data.
6. Tell a second lab identity, if you have one, that the stimulus will happen. Do not surprise people.
7. Run the stimulus once.
8. Capture the log line or the deny. Redact nothing that is not a secret, and redact every secret.
9. If the evidence is missing, fix the detection or the control in the lab.
10. Run the same stimulus again and show the evidence appears.
11. Revert the grant, the object, or the config so the lab is quiet.
12. Add a regression check the pipeline or a scheduled job can run without you.
13. Map the hypothesis to a tactic name only, such as "privilege misuse," with no procedure under it.
14. Attach the evidence to the catalog row for the service.
15. Write what you will not test, including phishing, malware, and anything outside the lab.
16. Schedule the regression monthly or on each pipeline change that touches logging or policy.
17. Review whether the alert is so noisy that you would ignore it. Tune or delete duplicates.
18. Practice a halt: stop the job halfway and show that partial changes were reverted.
19. Store the charter next to the evidence for a fictional audit packet.
20. Read the card aloud and delete any line that tells someone how to cause harm outside the fixture.
21. Stop. Do not point tests at Swiggy, Paytm, Amazon, BHIM UPI, WhatsApp, Zomato, Netflix, Infosys, PayFast, coworkers, or any system the charter does not name.

34.4 A real public incident.

Name. LastPass security incident disclosed in 2022.

Date. LastPass published an initial security notice on 25 August 2022. A further update on 22 December 2022 described copying of backup data from cloud storage, including encrypted customer password vaults, after an earlier compromise of a developer environment.

Source. LastPass blog notices of 25 August 2022 and 22 December 2022. This chapter does not describe how the developer environment was entered and does not describe vault encryption attacks.

What happened. A password-manager company told customers that an unauthorized party had reached a developer environment and, later, that backup copies of customer vault data had been copied from cloud storage. The public lesson for validation is uncomfortable. Controls around a developer environment and around backups are not side quests. They are production controls. A purple team that only tests the customer login page would have been looking away from the path that mattered. The safe translation into your lab is a hypothesis about the places you actually keep crown jewels: the pipeline identity, the backup bucket, the admin role. Would an alert fire if a lab role read the backup prefix? Would a second person have to approve a new access key? Would the regression test fail if someone turned the alert off? Those questions do not require you to break into anything. They require you to perform the allowed action in a lab and watch. Customers of a password manager were told to treat the event seriously, including rotating important passwords over time as the company advised. Your job in this chapter is the detection and the backup boundary, practiced where you are allowed.

How to stop.

1. Contain the affected developer and backup paths you own: revoke sessions and keys, and stop further copies.
2. Preserve logs of who read the backup store.
3. Rotate credentials that the affected environment could reach.
4. Notify people whose data was in the copy, as the duty requires, without creating a new exposure in the notice.
5. Stand up a clean build path before you trust new releases.

How to prevent it again.

1. Treat developer environments and backup buckets as in-scope for detection tests.
2. Alert on unusual reads of backup prefixes and on new access keys. Fire that alert with a lab fixture.
3. Separate the identity that builds software from the identity that can read customer backups.
4. Keep a regression test that fails if the backup alert is disabled.
5. Require a second person for access changes to crown-jewel stores.
6. Practice only in a lab you own. Do not attempt to validate LastPass or anyone else's cloud.

This is for learning only, and only inside a system you are allowed to test.

34.5 A simple picture.

A hypothesis names a control. A benign stimulus in your lab produces evidence. A regression test keeps the evidence alive. There is no arrow that leaves the lab.

34.6 A short animation.

A lab grant happens. An alert pulse appears. The grant is removed. The regression job stays green.

34.7 Conclusion.

Raju's card had a grant, an alert, and a revert. It did not have a recipe. Guru-ji put the card with the architecture page. "This is the end of the numbered road in this volume. You can inventory a finding, pave a path, share an error budget, lock a database, distrust an event, distrust a phone, distrust a model, reconcile from Git, draw the planes, and prove one control with a fixture. None of that requires you to harm a stranger. The city stays standing when the tests are boring and the boundaries are real."

• Purple testing proves a control with a benign fixture and a written scope.
• Tactic names are vocabulary. They are not permission to write procedures.
• The output is a regression test, not a story.
• LastPass, notices on 25 August 2022 and 22 December 2022, shows why backups and developer environments belong in the test charter.
• Own lab only.

END OF CHAPTER 34 MASTER CLASS