Platform
Security Assessment Policy
This is the standing process for security testing of the RatCTF platform. It exists so assessments are repeatable rather than ad-hoc — the same scope questions asked, the same boundaries enforced, the same evidence produced every time. It is written to satisfy the planning requirements of NIST SP 800-115 §2.
Version 1.0 · Effective 13 September 2026 · Owner: Wesley Thijs, CEO & CTO, The XSS Rat · Review: annually, or after any security incident.
1. Purpose and scope of this policy
This policy governs all technical security testing of systems operated by The XSS Rat in support of RatCTF: the portal application, the Kubernetes infrastructure that runs it, and the containment boundary around the deliberately vulnerable training machines.
It does not govern the intentional vulnerabilities inside the training machines. Those are the product. They are assessed only for containment — whether they can be used to reach anything they should not.
2. Roles and responsibilities
| Role | Responsibility |
|---|---|
| System owner Wesley Thijs, CEO & CTO |
Accountable for platform security. Authorises every assessment, approves the rules of engagement, accepts residual risk, and owns remediation priority. |
| Assessor | Executes testing strictly within the agreed rules of engagement. Stops and escalates on discovery of real user data exposure or anything affecting availability. |
| Reporter any player or member of the public |
May report issues under §8. No prior authorisation needed to report; authorisation is needed to test anything beyond the designated vulnerable machines. |
3. Assessment frequency
- Full assessment — at least annually.
- Targeted assessment — before any change to authentication, authorisation, payment handling, or the lab containment model.
- Incident-triggered — after any confirmed security incident, scoped to the affected boundary as a minimum.
- Continuous — automated health and exploit-chain tests run against every lab on a schedule; a failure is triaged like any other defect.
4. Planning — required before any testing
No assessment begins until all four are agreed in writing with the system owner:
- Scope. Which assets, named explicitly. Anything not named is out.
- Depth. Which SP 800-115 techniques are permitted (see §5).
- Rules of engagement. Exclusions, prohibited techniques, timing constraints, and data-handling limits.
- Authorisation. Explicit confirmation the owner operates every in-scope asset and authorises testing of it.
5. Permitted techniques
Testing depth follows the SP 800-115 ladder. Each level must be explicitly authorised; a higher level does not imply consent to a lower one being applied more broadly.
| Level | Techniques | Risk |
|---|---|---|
| §3 Review | Source, configuration, network policy, access control and log review | None to production |
| §4 Identification | Service enumeration, TLS and header inspection, route mapping | Low — generates traffic |
| §5 Validation | Authorisation bypass attempts, credential testing, live exploitation | Real — may disrupt |
6. Standing prohibitions
These apply to every assessment and cannot be waived by the assessor:
- No denial-of-service or load testing. Including sustained brute force against live authentication.
- No destructive testing. No deletion or modification of real user data, no state changes that cannot be reversed.
- No third-party systems. Payment processors, email providers, the CDN, the container registry and the hosting control plane are never in scope. We cannot authorise testing of systems we do not operate, and doing so would breach their terms.
- Minimum necessary data access. Real user data is read only to the extent required to evidence a finding, never exfiltrated, and never included verbatim in a report.
- Stop and escalate on discovery of exposed real user data, or of anything that appears to be an active compromise.
7. Findings, remediation and re-test
Findings are rated on exploitability, blast radius, and whether exploitation was confirmed by test rather than inferred from reading code. That distinction is recorded on every finding.
| Severity | Target to remediate |
|---|---|
| Critical | Immediately; take the affected component offline if it cannot be fixed at once |
| High | 7 days |
| Medium | 30 days |
| Low | 90 days, or formally accepted as residual risk |
Every fix must be re-tested by re-running the original proof, not by reviewing the patch. Where a fix touches an authentication or authorisation path, a positive test must also confirm legitimate access still works — a control that blocks everyone is a broken control, not a secure one.
Residual risk that will not be fixed is recorded explicitly, with the reason, and accepted by name by the system owner. It is never left undocumented.
8. Reporting an issue to us
The vulnerable machines listed on /challenges are the only systems open for unsolicited security research. The portal, the cluster, and other players' accounts are not — see Rules & Acceptable Use.
If you find a genuine issue in the platform itself:
- Email info@thexssrat.com, or use the contact in our security.txt.
- Include enough detail to reproduce it. A proof of concept helps.
- Please give us a reasonable window to fix it before publishing.
- Do not access, modify or retain other users' data while demonstrating an issue.
We will acknowledge your report, tell you what we found, fix it, and credit you publicly if you want to be credited. We will not pursue anyone who reports in good faith within these boundaries.
9. Records
Each assessment produces a report recording scope, rules of engagement, methodology, findings with evidence, remediation status and re-test results. Reports containing unremediated findings are held internally. A public summary is published at /security once High findings are closed.
Security Assessment Policy v1.0 · The XSS Rat · Questions: info@thexssrat.com