Security Policy

Updated

August 30, 2026

Legal Docs

1. SECURITY POSTURE

CYBERCOM is a cybersecurity company. We hold ourselves to a higher standard than most. This document describes our security practices across infrastructure, data, and operations - and how to report vulnerabilities responsibly.

We do not treat security as a compliance checkbox. Real attacks, real defenses, and real stakes are what we teach. We apply the same rigor to our own systems.

2. INFRASTRUCTURE SECURITY

Isolation

›Every lab and CTF environment is spawned in an isolated compute instance per user.
›No cross-tenant access is possible by design - environments are network-segmented.
›Lab environments are ephemeral: destroyed and rebuilt between sessions.

Encryption

›All traffic between clients and CYBERCOM servers uses TLS 1.2 minimum (TLS 1.3 preferred).
›Sensitive data at rest (credentials, assessment data, anti-cheat logs) is encrypted using AES-256.
›Passwords are hashed with bcrypt (cost factor ≥ 12). Plaintext passwords are never stored.

Access Control

›Production system access is restricted to core engineering team members (Guru Prasanth M as CTO oversees final technical approval).
›Access is role-based, least-privilege by default.
›All privileged access is logged and auditable.
›Multi-factor authentication is required for all internal CYBERCOM admin accounts.

Monitoring

›Platform activity is monitored in real time for anomalies.
›Anti-cheat systems produce encrypted, tamper-evident logs.
›Extreme Anti-Cheat Mode (for government events): fully air-gapped, offline internal network, physical CCTV, and device lockdown. RF jamming is not used (requires government authorization) - the air-gapped approach achieves equivalent containment.

3. INCIDENT RESPONSE

Our incident response process:

Detection

Automated monitoring alerts the engineering team within minutes of anomalous behavior.

Containment

Affected systems are isolated. Impacted user sessions are terminated to prevent propagation.

Assessment

Scope and impact are determined. Affected users and institutions are notified within 72 hours of confirmed breach.

Remediation

Root cause is fixed, systems are patched, and a post-incident review is conducted within 7 days.

Disclosure

Material security incidents affecting user data are disclosed publicly after remediation, in accordance with applicable law.

4. RESPONSIBLE DISCLOSURE (BUG BOUNTY)

We are a cybersecurity company - we take vulnerability reports seriously. If you discover a security vulnerability in CYBERCOM's platform:

Report a Vulnerability

Email: founders@cybercomctf.com

Subject line: [SECURITY] Brief description

Encrypt sensitive reports with our PGP key. Request it in your initial email.

Rules of Engagement

-Do not access, modify, or delete data belonging to other users.

-Do not disrupt service availability (no DoS/DDoS).

-Do not test against production systems of our clients without their explicit consent.

-Provide sufficient detail for us to reproduce the vulnerability.

-Allow us 30 days to investigate and remediate before public disclosure.

In Scope

›cybercomctf.com and subdomains

›CYBERCOM platform (app, API endpoints)

›Lab environment isolation boundaries

›Authentication and session management

Out of Scope

×Physical security attacks

×Social engineering of CYBERCOM staff

×Third-party services we use (report directly to them)

×Denial of service attacks

We do not currently offer monetary bounties, but we will acknowledge valid reports publicly (with your permission) and may invite contributors to participate in CYBERCOM events at no cost.

5. SUPPLY CHAIN AND THIRD-PARTY SECURITY

We audit our third-party dependencies and infrastructure providers for security posture:

›Dependencies are reviewed for known CVEs before integration.
›We pin versions in production to prevent unexpected updates from introducing vulnerabilities.
›Third-party service providers are evaluated for SOC 2 compliance or equivalent.
›We do not use open-source CTF platforms as our base - our infrastructure is proprietary, reducing shared attack surface.

6. DATA SECURITY

See our Privacy Policy for full details on data retention, access controls, and user rights. Key security-relevant data practices:

›User passwords: bcrypt hashed, never stored in plaintext.
›Session tokens: cryptographically random, invalidated on logout, rotate on privilege escalation.
›Assessment and anti-cheat data: encrypted at rest, access restricted to engineering and relevant client admins.
›Backup snapshots: encrypted and stored in geographically separate infrastructure.

7. SECURITY CONTACT

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

Guru Prasanth M - CTO (primary security contact)

founders@cybercomctf.com

QUESTIONS?

If you have questions about this document, contact us:

contact@cybercomctf.com

CYBERCOM FOUNDRY PRIVATE LIMITED · CHENNAI, TAMIL NADU, INDIA