Platform
NIST CSF 2.0 Profile
This is our Cybersecurity Framework profile: an honest read of where our security programme stands today against NIST CSF 2.0, where we intend it to be, and what sits between the two. It covers all six Functions, including the ones where we score badly.
Version 1.0 · 13 September 2026 · Owner: Wesley Thijs, CEO & CTO, The XSS Rat · Review: annually.
Organisational Tier
CSF Tiers describe how rigorous and repeatable a security programme is — not how secure a system is. They run from 1 (Partial) to 4 (Adaptive).
| Current | Tier 2 — Risk Informed, trending to Tier 3. Risk-aware practice with controls in place and now-documented process, but not yet a full cycle of evidence behind every policy. |
| Target | Tier 3 — Repeatable. Formally approved, organisation-wide policy; practices regularly updated; process survives its author being unavailable. |
Why not Tier 4? Adaptive requires continuous, metrics-driven improvement informed by threat intelligence. We are a single-operator company. Claiming Tier 4 would be a lie, and a profile you cannot trust on one line is worthless on all of them.
Profile at a glance
| Function | Current | Target | Headline gap |
|---|---|---|---|
| GOVERN | 2 | 3 | Single-operator concentration |
| IDENTIFY | 3 | 3 | Supply-chain inventory |
| PROTECT | 3 | 3 | CSP allows inline scripts |
| DETECT | 2 | 3 | No egress anomaly alerting |
| RESPOND | 2 | 3 | Plan written but never exercised |
| RECOVER | 3 | 3 | Quarterly restore cadence to establish |
GOVERN — our weakest Function
Current 2 → Target 3. CSF 2.0 added GOVERN precisely because technical controls without organisational process do not survive contact with reality.
In place: a published Security Assessment Policy defining roles, scope, permitted techniques, standing prohibitions and remediation timeframes; a published Terms & Privacy policy with explicit data commitments; a documented incident response plan; named accountability resting with the CTO.
The gap, stated plainly: this is a one-person company. One person writes the policy, performs the work and signs it off. Segregation of duties does not exist and cannot be manufactured. The mitigating control is a named deputy holding independent access to hosting, DNS and registry accounts, so the platform is recoverable if that person is unavailable. That deputy access is to be verified annually.
IDENTIFY
Current 3. Assets are enumerable rather than guessed: the lab estate and supporting workloads are queryable live from the cluster, the challenge catalogue is authoritative in source control, and an internal operations view shows live state.
Risk is assessed through a documented technical assessment programme — the most recent covering the application, infrastructure and lab containment boundary, with findings tracked to closure. Improvement is fed by post-incident review.
Gap: third-party dependency inventory is informal. We know what we run; we do not systematically track advisories against every dependency.
PROTECT
Current 3. The strongest Function, and the one most recently tested.
- Identity. Passwords hashed with bcrypt at a high work factor, never stored in plaintext. Optional time-based multi-factor authentication. Optional single sign-on. Rate limiting on sign-in, password reset and verification codes.
- Data. Modern TLS with strict transport security. Session cookies are HTTP-only, same-site and transmitted over TLS only. Password reset tokens are randomly generated, stored hashed, and expire.
- Platform. Deliberately vulnerable workloads are denied outbound internet access by network policy. Lab workloads carry no cluster credentials. The in-browser attack box runs unprivileged with all Linux capabilities dropped, network isolated, on a hard time limit.
- Application. Content security policy, clickjacking protection and strict content-type handling on every response.
Gap: the content security policy currently permits inline scripts, because the site uses many. It restricts where external scripts may load from and prevents clickjacking, but it is not full cross-site-scripting mitigation. Migration to per-request nonces is planned.
DETECT
Current 2 → Target 3.
In place: automated exploit-chain tests run continuously against every lab — a failure means a machine's expected behaviour changed, which is as often a security signal as a functional one. Scheduled health checks run every fifteen minutes. Security and operational events are raised to an internal alert log.
The gap, and we are not going to dress it up: in our July 2026 incident, compromised lab machines were used to generate outbound attack traffic, and we learned about it from our hosting provider rather than from our own monitoring. Egress denial now prevents that class of event across the estate, which is a stronger control than detecting it — but prevention is not detection. Alerting on anomalous outbound behaviour is the main open item in this profile.
RESPOND
Current 2 → Target 3. A written incident response plan now exists, aligned to NIST SP 800-61r3. It defines severity levels specific to this platform — notably that a player rooting a lab is not an incident, whereas anything crossing a containment boundary is — along with containment playbooks, evidence-preservation steps, communication obligations and a post-incident review requirement.
We have handled a real incident and can describe its root cause, actions and outstanding items honestly.
Gap: the plan has not been exercised since it was written. An untested plan is a document, not a capability. A tabletop exercise is required before we claim Tier 3.
RECOVER
Current 3. Platform data is archived every six hours to durable storage, with retained history, and pushed off-site to separate object storage on the same schedule.
Critically, restoration has been verified rather than assumed. On 13 September 2026 the most recent archive was extracted and every datastore checked for integrity and record count against production — a complete match, with no corruption. The off-site copy was confirmed present and under an hour old. Restore verification is now required quarterly.
Gap: that quarterly cadence is newly set and has one data point. A backup you have restored once is credible; a backup you restore on a schedule is dependable.
What we are working on next
- Egress anomaly detection — closes the DETECT gap that our real incident exposed.
- Tabletop the incident response plan — turns RESPOND from a document into a capability.
- Content security policy nonces — upgrades PROTECT to genuine XSS mitigation.
- Verify deputy access annually — the only meaningful control against single-operator concentration.
- Quarterly restore verification — establishes the cadence RECOVER needs.
- Dependency advisory tracking — closes the IDENTIFY supply-chain gap.
Why publish this at all?
We run a platform that teaches people to break into things. Asking you to trust us with an email address and a password, while saying nothing about how we operate, would be a poor look. A profile that claimed top marks everywhere would be worse — you would be right not to believe it.
So this one names its weakest Function first, states that our worst incident was found by somebody else, and admits which plan has never been tested. Those are the parts worth reading.
Assessment summary Assessment policy
NIST CSF 2.0 Profile v1.0 · The XSS Rat · Questions or corrections: info@thexssrat.com