The DARE Framework

sarathg.me / framework

The

DDeconstruct

AAttack

RRemediate

EExchange

Framework

A design constraint for cybersecurity training. Four stages. One learner. The same environment. No stage skipped.

Explore the Framework Worksheets & planning tool ↗ Read the Article ↗

The Core Belief

Understanding is not real until it has been experienced in context.

A learner who can describe SQL injection has not understood SQL injection. A learner who has executed it, watched it fail against a patched version, and then defended against it — that learner understands it. Most training stops after the first step. DARE does not stop until all four are complete.

The Four Stages

Each stage is necessary. None is sufficient alone.

The stages must be completed in sequence, by the same learner, in the same environment. Click any tile to expand the full explanation.

Deconstruct

Start from how the system actually works — not from the attack.

Expand

Attack

Execute the attack in a realistic, relatable environment.

Expand

Remediate

Show the fix in the same environment, against the same attack.

Expand

Exchange

Make the learner switch sides and occupy the defensive position.

Expand

Deconstruct

Start from how the system actually works — not from the attack.

The learner builds a functional understanding of the target before anything is broken. How the protocol operates. How the application handles requests. How trust is established. Without this, an attack is a procedure that can be repeated but not adapted. Context converts instruction into understanding.

Attack

Execute the attack in a realistic, relatable environment.

The learner performs the attack against something they can recognise — familiar structure, implied stakes, not a synthetic box. The learner does not observe the attack. They execute it. Recognition produces relevance. Relevance produces retention.

Remediate

Show the fix in the same environment, against the same attack.

The patched version sits beside the broken one. The learner runs the same attack and watches it fail. The fix is not described — it is demonstrated. The failure of the attack is the explanation of the fix.

Exchange

Make the learner switch sides and occupy the defensive position.

The learner moves from attacker to defender against the same target. Same scenario, switched. What does this look like in a log? How would you detect it? What would remove it? A practitioner who has only attacked is half-trained.

The DARE Diagnostic

Four questions every training environment must answer yes to.

0/4 answered yes

DARE is not a curriculum. It doesn't tell you which vulnerabilities to cover or which tools to teach. It's a design constraint. Evaluate your training environment — click each question it answers yes to.

D Does the learner understand how the system works before they attack it?

A Are they executing the attack themselves, not watching someone else do it?

R Can they see the fix stop the attack in the same environment?

E Have they been required to defend against what they just executed?

Click each question to evaluate your training environment against the DARE constraint.

If any answer is no, the environment is incomplete. It might still be useful. But it isn't producing the understanding it could.

For The Learner

Run this against any vulnerability you are studying.

A no answer is not a failure — it tells you exactly what you have not done yet.

0 / 9

Deconstruct

Understand how the system works before anything is broken

Can you explain how this system works in normal operation — without mentioning the attack?

Describe the request/response flow, where data goes, and what happens step by step.

Can you identify all the inputs that come from the client, and how the system checks whether that information is valid?

List every field, parameter, or value the user can send. For each one, ask: does the system verify this, or does it just use it?

Have you demonstrated your understanding to someone else — by explaining it or answering questions about it?

The format does not matter. What matters is that your mental model has been checked by another person.

Attack

Execute the attack yourself — not watch someone else do it

Have you executed the attack yourself and observed the actual impact?

Getting a result is not enough. You must have seen what the attack actually does to the system.

Can you replicate the attack on a different target without guidance?

If you can only execute it on the original target with the original steps, you followed instructions. Transfer is the proof of understanding.

Remediate

Watch the fix stop the attack in the same environment

Have you run the same attack against a patched version of the same environment — and watched it fail?

Reading about the fix is not the same as seeing the fix stop the attack you just executed.

Can you explain why the fix works — not just what the fix is?

For example: parameterized queries stop SQL injection because the query structure is fixed before user input is added. The input cannot change the structure.

Exchange hardest stage

Defend against what you just attacked

Could you detect this attack if someone ran it against a system you were defending?

What would it look like in logs, traffic, or behaviour? What would alert you?

Have you actively taken the defender's position — not just understood the fix, but thought from the defender's perspective?

This stage is incomplete in most training. If you cannot answer yes, you know what to work on next.

DARE in Action

SQL injection via a login form.

The same vulnerability, walked through all four stages. This is what DARE looks like in practice.

Deconstruct

Understand how the login form works before anything is broken

A login form sends a username and password to the server. The server builds a database query using those values — something like: find the user where the username matches and the password matches. If a matching record is found, the user is granted access.

The learner maps every input the user can send — the username field, the password field, any hidden fields — and asks: does the server check these values before putting them into the query, or does it use them directly?

What the server does with your input

SELECT * FROM users
WHERE username = 'user_input'
AND password = 'user_input'

✓ The learner now understands the system before the attack begins.

Attack

Execute the injection and observe what happens

The learner types a crafted value into the username field. They do not observe this — they type it themselves, submit the form, and watch what the server returns.

What the learner types into the username field

admin' OR '1'='1

What the server query becomes

SELECT * FROM users
WHERE username = 'admin' OR '1'='1'
AND password = ''

The condition OR '1'='1' is always true. The query returns the first user in the database — typically an admin account. The learner is now logged in without a valid password.

✓ The learner has executed the attack and seen the actual impact — unauthorised access, not just a flag.

Remediate

Run the same attack against the patched version — watch it fail

The patched version of the same login form is now presented. The learner types the exact same input and submits. This time, access is denied.

The patched server uses a parameterized query

SELECT * FROM users
WHERE username = ?
AND password = ?

-- The query structure is fixed first.
-- User input is passed separately as data.
-- It cannot change the structure of the query.

The injected value admin' OR '1'='1 is treated as a literal string — not as SQL. The database looks for a user whose username is exactly that string. No such user exists. Login fails.

✓ The learner has seen the fix stop the attack — not read about it.

Exchange

Switch sides — now you are the defender

The learner has just executed a SQL injection attack. Now they take the defender's position against the same login form.

01You are monitoring the application logs. What pattern in the login attempts would alert you that this attack is being attempted?

02A developer on your team has written a new login form. What do you check in the code before it goes to production?

03The attack succeeded against an older part of the system before it was patched. What data was at risk and what would you tell the affected users?

✓ The learner has stood on both sides of the same vulnerability. That is DARE complete.

For The Trainer

Design environments that produce real understanding.

Two tools for trainers — a build sequence for designing from scratch, and an audit checklist for reviewing environments you have already built.

Choose the vulnerability

Start with what you need to teach — not with the application, not with the tools. The vulnerability is the anchor. Everything else is built around it.

Be specific. "Injection attacks" is too broad to build around. "SQL injection via login form" is a starting point.

Choose the application context — the resonance principle

The application must come from the learner's world. A learner who recognises the environment they are attacking will engage faster and retain longer.

Banking / financeInternet banking portal, transaction system

HealthcarePatient portal, medical records system

Government / public sectorCitizen services portal, document submission

Unknown / mixed audienceE-commerce — almost everyone has been a customer. Default to this when you cannot identify their industry.

D — Build the Deconstruct layer

Before any attack is possible, the learner must be able to explain how the application works in normal operation. Prepare the materials that let them map the system — the request flow, the inputs, and what the application does with each one.

Verification is flexible. Some learners demonstrate understanding by explaining. Others demonstrate it by answering questions correctly. Both are valid. The goal is to confirm the mental model is accurate before moving forward.

A — Build the vulnerable version

The learner must execute the attack themselves — not observe it. Build an environment where the vulnerability is real and exploitable, and where the learner can see the actual impact of a successful attack.

In-person: the emotional response at the moment of execution tells you whether they understood or just got a result. Online: have them replicate the attack on a second target without guidance. Transfer is the proof of understanding.

R — Build the patched version

The patched environment lives beside the vulnerable one. The learner runs the same attack and watches it fail. The trainer owns the fix — the learner's job at this stage is not to implement the fix but to experience what the fix does to the attack.

After the attack fails, explain why the fix works — not just what it is. The failure of the attack is the best moment to deliver that explanation.

E — Design the Exchange

The learner switches from attacker to defender. They must engage with the same scenario from the opposite position. This is the stage most training environments do not reach — design it deliberately or it will not happen.

Exchange does not require a live red/blue exercise. It can be as simple as: given what you just executed, what would you look for in logs to detect it? What alert would you write? What policy would you change? The question must be asked. It will not arise on its own.

0 / 8

D Deconstruct

Does the environment require the learner to understand how the system works before they can attempt the attack?

If the learner can jump straight to the attack without any system context, Deconstruct is missing.

Is there a mechanism to verify the learner's understanding — not just assume it?

A question, a demonstration, an explanation back to the trainer. Something that confirms the mental model before the attack begins.

A Attack

Does the learner execute the attack themselves — not watch a demonstration?

Observation is not Attack. The learner must execute.

Does the environment make the impact of the attack visible — not just the result?

Getting a flag or a response code is a result. Seeing data exposed, access granted, or a system compromised is impact. The learner must see impact.

R Remediate

Is there a patched version of the same environment where the learner can re-run the attack?

A description of the fix is not Remediate. The patched environment must exist and the attack must fail in it.

Is the explanation of the fix tied to the moment the attack fails — not delivered separately as theory?

The failure of the attack is the best moment to explain why the fix works. If the explanation happens before or after, that connection is weakened.

E Exchange most commonly missing

Does the environment require the learner to engage with the scenario from the defender's perspective?

This does not require a live exercise. A question like "what would you look for in logs to detect this attack?" is a valid Exchange activity.

Is the Exchange stage designed deliberately — or left as something that might happen if time allows?

If it is not built into the session plan, it will not happen. Exchange must be a scheduled requirement, not an optional extension.

The Framework in Practice

DARE applied — three training environments.

Each project below was built around the DARE constraint. Click any card to see how each stage appears in that environment.

01 / Simulation

Parallax

A browser-based cybersecurity training simulation with dual-role scenarios. Six real-world attack sequences played from both the attacker and SOC analyst position — in the same environment, back to back.

Dual POV Six Scenarios Three.js parallax.sarathg.me

DDeconstruct

Each scenario opens with the system context — how the target environment is structured, what the normal state looks like, and what the attacker is about to exploit. The learner understands the ground before the attack begins.

AAttack

The learner executes the attack using real tool syntax and decision branches across six scenarios: OSINT Reconnaissance, Phishing, Network Intrusion, Social Engineering, Privilege Escalation, and Ransomware.

RRemediate

Each scenario ends with a debrief screen showing what defensive control would have stopped the attack at each decision point — in the same scenario context, not as a separate module.

EExchange

The same scenario is then played again — mandatory — from the SOC analyst position. The learner detects, investigates, and responds to the attack they just executed. The Exchange is built into the structure, not optional.

02 / Vulnerable Application

VulnShop

A deliberately vulnerable Laravel e-commerce application with ten intentional CVEs. Built as a SAST/DAST training environment — the familiar e-commerce context makes every vulnerability feel real rather than academic.

Laravel 10 CVEs SAST · DAST E-commerce Context

DDeconstruct

The e-commerce context does the deconstruction work. Every learner already understands what a shop is, what an order is, what an account is. The application structure is immediately legible before any vulnerability is touched.

AAttack

Ten intentional vulnerabilities across SQL injection, stored XSS, IDOR, CSRF, weak hashing, hardcoded credentials, insecure file upload, missing rate limiting, debug exposure, and information disclosure.

RRemediate

Each CVE has a corresponding remediation exercise — fixing the vulnerable code, validating the fix, and re-running the attack to confirm it fails. The fix lives in the same codebase as the vulnerability.

EExchange

After exploiting each vulnerability, learners switch to the developer/defender position — reviewing the code that made it possible, understanding the design decision that introduced it, and writing the fix themselves.

03 / API Security Lab

ShopEasy

A Flask API application pair — vulnerable on port 5000, patched on port 5001. The same application, two states, running simultaneously. Built for API security training covering BOLA, JWT forgery, and endpoint fuzzing.

Flask API Security BOLA · JWT Dual Instance

DDeconstruct

The session begins with how the API authorisation model works — how JWT tokens are issued, how object-level permissions are meant to be enforced, and what the intended trust boundaries are before any of them are broken.

AAttack

Learners attack the vulnerable instance on port 5000 — forging JWT tokens, accessing other users' resources via BOLA, and fuzzing endpoints with ffuf to discover undocumented routes. Real attacks, real tool output.

RRemediate

The patched instance runs simultaneously on port 5001. The learner runs the same attacks and receives correct 401 and 403 responses. The fix is not described — it is visible in the response headers and code, in the same session.

EExchange

After the attack phase, learners review the secure implementation — reading the authorisation middleware, understanding what the patched code does differently, and explaining why each control stops the attack they just executed.

"A learner hasn't understood a security concept until they have broken it in context, watched it defended, and stood on both sides of it."

The argument behind the framework.

Why most cybersecurity training produces people who can pass exams and fail incidents — and what DARE does differently.

Read on Medium ↗

The DARE Framework — A Cybersecurity Lab Methodology

Understanding is not real until it has been experienced in context.

Each stage is necessary. None is sufficient alone.

Four questions every training environment must answer yes to.

Run this against any vulnerability you are studying.

SQL injection via a login form.

Design environments that produce real understanding.

DARE applied — three training environments.

The argument behind the framework.