Cybersecurity Policy
Version 1.0 · Effective 2026-07-19 · Something Awesome Games LLC d/b/a Ice Juice Trading · Policy owner: Founder & Managing Member
This policy governs how Ice Juice Trading ("we") protects customer data, brokerage access credentials, and production systems.
1. Data classification and handling
| Class | Examples | Handling |
|---|
| Restricted | Brokerage OAuth access tokens; application signing secrets | Application-layer AES-256-GCM encryption before storage; readable only by server-side code; never sent to browsers, logs, or third parties; never stored on workstations or worker machines. |
| Confidential | Customer emails, strategy configurations, positions and trade history, sessions | Stored with database permissions locked to server-only (master key) access; exposed only to the owning user via authenticated server functions; never sold or shared. |
| Internal | Source code, infrastructure configuration, operational logs | Private repositories; access limited to authorized personnel; logs exclude secrets and tokens. |
| Public | This website and legal pages | No special handling. |
Every new database class is created with locked, server-only permissions as a standing rule, enforced by an automated script run against every environment.
2. Access control and privileged access management
- Least privilege by default: client applications hold no database privileges; all access flows through authenticated server-side functions scoped to the requesting user.
- Privileged credentials exist only in the platform's environment store and the CI secret store — never in source code or on workstations.
- Server access is public-key-only SSH (passwords disabled); automation uses dedicated single-purpose keys with pinned host keys.
- User sign-in is passwordless: single-use, time-limited, rate-limited email codes, hashed at rest. A session kill switch lets users revoke all other sessions. Authenticator-app (TOTP) step-up is required before live-money brokerage connections are enabled.
- Administrative access is limited to the founder; there are no shared accounts.
3. Encryption in transit and at rest
- In transit: TLS on every hop — browser to site, site and servers to the backend, and all outbound calls to brokerage and email providers. No plaintext transport.
- At rest: brokerage tokens carry application-layer AES-256-GCM authenticated encryption on top of managed database protections; the OAuth client secret never leaves server-side code; token exchange happens exclusively server-side; login codes are stored only as salted hashes; workstations use full-disk encryption.
4. Vulnerability and patch management
- The backend runs on a managed platform patched and hardened by the provider.
- Our worker server runs a minimal-footprint Ubuntu LTS with regular security updates and holds no secrets, making it rebuildable from version control at any time.
- Every code change is peer-reviewed (including automated review on every pull request) and gated by an automated test suite before deployment.
- Dependencies are deliberately minimal; security advisories for our platforms and libraries are monitored and patched by severity.
5. Incident response and disaster recovery
- Detection: centralized server-side error logging, scheduled health checks, and deploy pipelines that fail loudly rather than degrade silently.
- Containment: per-strategy pause/stop; account-wide entry freeze; a user-facing emergency liquidation control requiring typed confirmation; a platform-wide kill switch for live-money order placement; immediate token revocation (users can also revoke from their broker at any time). A failing brokerage token automatically freezes that connection.
- Response: on suspected compromise we freeze affected accounts, revoke and rotate credentials, preserve logs, remediate, and review. Affected users are notified without undue delay — target within 72 hours of confirmation.
- Recovery: all infrastructure and code is in version control; the database is operated and backed up by the managed platform; worker infrastructure is stateless and rebuildable within hours.
6. Physical security
We operate no physical server infrastructure. Production runs in the data centers of established cloud providers with industry-standard physical controls. Company workstations are physically controlled, full-disk encrypted, and auto-locking.
7. Vendor risk management
Vendors (managed backend platform, cloud hosting, source control/CI, transactional email, payments, brokerage integration) are selected for established security programs, given the minimum data and privileges required, and reviewed at least annually and after any material incident. We store no cardholder data; billing is handled by our merchant of record.
Review
This policy is reviewed at least annually and upon material changes to systems, vendors, or regulatory expectations. Contact: hello@icejuicetrading.com.
← Back to icejuicetrading.com