Security Policy

CYBERCOM is a cybersecurity company, so we hold ourselves to the standard we teach. This page lists the controls we run, and says plainly when something is an option we arrange per engagement rather than a default. We update it as our practices change.

If your institution needs more detail than this page gives (for a procurement or security review), email us and we will answer in writing.

Controls enforced on cybercomctf.com:

• HTTPS only, with HSTS (preload) so browsers refuse to downgrade to HTTP.
• A strict, per-request nonce-based Content Security Policy with no inline-script allowance. Framing is blocked (X-Frame-Options DENY and frame-ancestors none).
• Cross-Origin-Opener-Policy, Referrer-Policy and Permissions-Policy headers set; camera, microphone and geolocation access are disabled.
• Form and API endpoints validate input with schemas, run behind bot detection and rate limiting, and return uncached responses.
• Analytics are privacy-first: Plausible is cookieless, and certificate verification pages are excluded from all third-party analytics.
• Secret scanning (Gitleaks) and a dependency vulnerability audit run in CI for this site, and installs are made from a lockfile.

Controls in the CYBERCOM platform that runs events and labs:

Higher-assurance event setups, such as offline or on-premise operation with physical monitoring and device lockdown, are arranged per event on request and scoped in writing. They are not part of the standard platform.

Our incident response process:

1. 01DetectionMonitoring and alerts flag anomalous behavior to the engineering team.
2. 02ContainmentAffected systems are isolated and impacted user sessions are terminated to stop the issue spreading.
3. 03AssessmentWe determine scope and impact. Affected users and institutions are notified within 72 hours of a confirmed breach.
4. 04RemediationThe root cause is fixed, systems are patched, and a post-incident review is held within 7 days.
5. 05DisclosureMaterial incidents affecting user data are disclosed after remediation, in line with applicable law including the Digital Personal Data Protection Act, 2023.

If you find a security vulnerability in CYBERCOM's website or platform, please tell us before disclosing it publicly.

We do not currently run a paid bug bounty. We will acknowledge valid reports publicly (with your permission).

• Dependencies are reviewed for known vulnerabilities before integration and pinned to exact versions in production.
• Third-party providers are evaluated for SOC 2 compliance or an equivalent security standard.
• Our CTF and labs platform is proprietary. It is not built on an open-source CTF platform, which reduces shared attack surface.

See our Privacy Policy for what we collect, how long we keep it and your rights. From a security standpoint:

• Data is encrypted in transit (TLS 1.2+) and at rest (AES-256).
• Passwords are bcrypt hashed and never stored in plaintext.
• Session tokens are cryptographically random and invalidated on logout.
• Assessment and anti-cheat data is encrypted at rest, with access limited to engineering and the relevant client admins.
• Backups are encrypted and kept separate from production.

For security issues, vulnerability reports, or questions about this policy: