01 · Research
Understand what makes a gateway test credible.
The research framing focused on the gap between control configuration and observable protection. NIST assessment guidance reinforced a complete testing loop—plan the test, conduct it safely, analyse findings, and connect them to mitigation. MITRE ATT&CK provided a recognised vocabulary for the threat behaviours.
Scenario quality
Does the test represent a real threat behaviour?
Every scenario needs an explicit behaviour, expected gateway response, and safe execution boundary.
Control evidence
Does the result show what the gateway actually did?
A conclusion must remain attached to policy, event, and observed network evidence.
Residual risk
What remains possible after the validation?
Protected cannot read as absolute safety; the report must expose remaining risk and test boundaries.
Key insight
A test is useful only when its conclusion can be defended.
Security teams need the technical evidence to reproduce a result. Decision-makers need the outcome, business meaning, and residual risk. SWG Audit therefore treats interpretation as part of the test—not a report assembled afterwards.
Security team
Reproduce the scenario and inspect the evidence behind the result.
CISO
See protection gaps and residual risk without translating raw gateway output.
IT decision-maker
Understand priority, ownership, and the action required next.
02 · Define
Validate protection without hiding the security evidence.
The product scope covers scenario selection, safe execution, gateway evidence, outcome clarity, and remediation. Infrastructure configuration and endpoint-level controls remain outside the audit so the result stays focused on Secure Web Gateway behaviour.
Problem statement
Teams could configure a gateway, but lacked one repeatable experience for proving what it stopped and what risk remained.
How might we
Let teams run realistic validations and reach a defensible security decision without manual interpretation?
Test real behaviour
What the research showed
Policy configuration alone does not demonstrate what happens when a threat reaches the gateway.
Product response
Define each audit around an observable threat behaviour and expected control response.
Make outcomes interpretable
What the research showed
Raw events require specialists to reconstruct whether the control worked and why.
Product response
Lead with Protected or Exposed, then keep the supporting evidence immediately inspectable.
Expose residual risk
What the research showed
A passed scenario covers one behaviour at one point in time—not every possible variant.
Product response
State what was validated, what remains untested, and which action closes the identified gap.
03 · Model
Turn four threat families into repeatable audit scenarios.
The concept maps its four categories to recognisable adversary behaviours. Each scenario defines what is exercised and which evidence must be captured, while keeping live malware and sensitive data outside the test.
Scroll through scenarios ↓
Phishing
ATT&CK T1566 / T1204.001Controlled exercise
A controlled link tests whether deceptive web access is blocked before the user reaches the destination.
Evidence required
Requested URL, category or policy match, gateway action, and user-facing block response.
Malware delivery
ATT&CK T1204.002Controlled exercise
A harmless test file exercises download inspection without introducing a live malicious payload.
Evidence required
File request, inspection event, signature or policy response, and download disposition.
Data exfiltration
ATT&CK T1567 / T1041Controlled exercise
A synthetic data transfer tests whether outbound policy identifies and interrupts prohibited movement.
Evidence required
Destination, transfer method, matched DLP rule, gateway action, and remaining egress path.
Resource hijacking
ATT&CK T1496Controlled exercise
A safe browser-based simulation checks access to infrastructure associated with unauthorised resource use.
Evidence required
Requested service, category or reputation signal, gateway action, and unresolved endpoint risk.
Audit logic
Keep the test, evidence, decision, and action in one chain.
01
Define
Select a threat behaviour and state the expected gateway response.
02
Prepare
Confirm scope, safe test data, destination, policy, and rules of engagement.
03
Run
Execute the controlled scenario through the Secure Web Gateway.
04
Capture
Attach request, policy, gateway event, response, and timestamp as one evidence packet.
05
Decide
Classify the tested behaviour as Protected or Exposed.
06
Act
Explain residual risk, remediation priority, owner, and the retest path.
04 · Design
Make three product decisions before styling the interface.
The interaction model prioritises threat intent, evidence-backed outcomes, and operational follow-through. Each decision changes the structure that the final UI images will demonstrate.
Scroll through decisions ↓
Start from the threat, not the control panel
Evidence
The product must answer whether a realistic behaviour is stopped, not ask users to interpret configuration first.
Decision
The home experience begins with threat families and test intent; policy details enter when a scenario is prepared.
Expected impact
Teams can choose a meaningful validation without first translating gateway terminology.
Separate outcome from confidence
Evidence
Protected and Exposed are useful conclusions, but evidence completeness determines how confidently they can be used.
Decision
Outcome remains binary for scanability while evidence status and residual risk remain separate, visible fields.
Expected impact
The interface stays decisive without presenting a single test as universal proof of protection.
Keep remediation inside the finding
Evidence
OWASP reporting guidance connects a finding to impact, technical detail, and concrete remediation.
Decision
Every exposed result carries priority, recommendation, owner, and a direct retest action.
Expected impact
The audit ends in an operational handoff instead of another interpretation task.
Result architecture
One evidence packet makes every conclusion inspectable.
Scenario
What behaviour was exercised
Expected control
What the gateway should have done
Observed response
What actually occurred
Evidence
Policy, event, request, response, and time
Outcome
Protected or Exposed
Residual risk
What this result does not prove
Next action
Priority, owner, remediation, and retest
Need image by Mukund
Scenario library and audit setup
Show the home state, four threat families, scenario intent, prerequisites, expected gateway response, and the setup required before a controlled test runs.
Need image by Mukund
Test execution and evidence capture
Show the active audit, progress, scope and safety context, gateway events, observed response, and the evidence being attached to the result.
05 · Review
Review the prototype against three security decisions.
The final design QA used decision tasks rather than visual preference: choose the right scenario, defend the outcome with evidence, and move an exposed result into remediation.
Choose the right validation
Review question
Can the user distinguish four threat families and understand what each scenario exercises before running it?
Final refinement
Scenario cards expose behaviour, expected response, and prerequisites before configuration begins.
Defend the conclusion
Review question
Can the user explain why a result is Protected or Exposed without leaving the finding?
Final refinement
The outcome and evidence packet remain in one reading path, with raw details available beneath the conclusion.
Move from gap to action
Review question
Can the user identify residual risk, remediation owner, and the next retest step?
Final refinement
Exposed findings end with priority, action, ownership, and a repeatable retest path.
Need image by Mukund
Audit results overview
Show Protected and Exposed outcomes across the executed scenarios, with evidence completeness, residual risk, and priority visible at scan level.
Need image by Mukund
Finding detail and remediation
Show the final result hierarchy: tested behaviour, expected control, observed response, technical evidence, residual risk, remediation owner, action, and retest.
Outcome
Turn gateway testing into a defensible security decision.
The concept replaces disconnected test output with a repeatable audit model. Each result states what was exercised, what the gateway did, why the conclusion is credible, which risk remains, and who acts next.
04
Threat families
Phishing, malware, data exfiltration, and resource hijacking
02
Audit outcomes
Protected or Exposed
07
Evidence fields
One defensible result packet
01
Action path
Owner, remediation, and retest stay connected
Before
Configuration and raw output still required manual interpretation.
After
Every scenario ends in evidence, residual risk, ownership, and action.