Information Security Policy

Red Mesa Studios LLC
Owner and responsible party: David Barkman, support@redmesastudios.com
Last reviewed: September 3, 2026 · Review cadence: annually, and on any material change

1. Scope and organization

Red Mesa Studios LLC is a single-operator business. One person, the owner, has administrative access to all production systems, performs all development, and is responsible for information security. There are no employees or contractors with system access.

In scope:

One Linux server (Rocky Linux 9) at a US infrastructure provider, running the company's web applications and databases.
One macOS workstation used for development and administration. It holds the SSH key to production and the password manager, and is therefore treated as a production asset.
Third-party services holding company or consumer data, principally Plaid.

Controls that assume a separation of duties (access reviews of one another's accounts, de-provisioning workflows, approval chains) are not applicable to an organization of one person.

2. Access control

The server is reachable only by SSH public key. Password authentication is disabled, root login is disabled, and the firewall (firewalld) permits only SSH, HTTP and HTTPS. No database port is exposed. MariaDB listens on localhost only.
Exactly one individual holds shell access to the server. No shared or service accounts are used for interactive login.
Applications do not run as root. Each service runs as an unprivileged system user, and each application is confined to its own directory and database.
Administrative escalation is via sudo, logged, with a time-limited authentication window.
Automated failed-login blocking is enforced by fail2ban on SSH and on web authentication, including a recidive jail for repeat offenders.
Credentials are held in a password manager (1Password). Application secrets are held in environment files readable only by the service account (mode 600), never in source control. .gitignore covers key and environment files.

3. Workstation security

Full-disk encryption (FileVault) is enabled.
The application firewall is enabled.
The screen locks automatically on sleep.
All credentials are held in a password manager.
The operating system and applications automatically receive vendor security updates.

Each of the above is verified weekly by an automated check and reported alongside the server.

4. Encryption

In transit: all web traffic is served over TLS 1.2 or better, with certificates from Let's Encrypt renewed automatically by a scheduled job. Certificate expiry is independently checked by the daily health report. Administrative access is over SSH. No service accepts unencrypted traffic.
At rest, credentials: third-party access tokens capable of retrieving consumer financial data are encrypted before storage using authenticated encryption (AES via Fernet), with the key held in an environment file readable only by the service account and never in the database.
At rest, swap: operating system swap is encrypted (AES-256) with an ephemeral key regenerated at boot.
At rest, databases: InnoDB tablespaces, the redo log and temporary tables are encrypted on disk (AES, via the server's file key management plugin), with the key held in a root-owned file outside the data directory. Every application tablespace on the shared host is encrypted.

5. Vulnerability management and patching

Operating system: vendor security updates are installed automatically every day by dnf-automatic. Updates that only take effect after a restart, such as the kernel and core libraries, are applied at the next scheduled maintenance, which runs at least every 30 days and includes a full package update and a reboot. A vulnerability that is both critical and known to be actively exploited is patched and rebooted out of band, within 72 hours.
Host packages: published advisories are mapped to installed packages daily and reported. An advisory that persists beyond 48 hours is raised as requiring action.
Application dependencies: every project pins exact versions and commits a lock file carrying package hashes, so an install cannot silently pull a different artifact. Dependencies are scanned against public vulnerability databases weekly and automatically, across every application on the host. Identified vulnerabilities are triaged within 7 days and remediated within 30 days, or a reason for not doing so is recorded. Upgrades are targeted rather than bulk, and exact pins are preserved.
Configuration hardening is audited weekly by an automated system auditor. It reports on how a system is configured, not on which packages carry known flaws.
Workstation is checked weekly. Full-disk encryption, the application firewall, screen lock and pending security updates are each verified and reported.
End-of-life software: production runs a current long-term-support Linux release and current language runtimes. End-of-life status is tracked automatically and reported when anything falls within six months of its end of life.
Scheduled work is monitored for having run. Every scheduled scan and backup records a success stamp, and a stale stamp is reported as a failure.
Change control: all application code is deployed from version control by pulling a committed change. Nothing is edited in place on a server, and files are never copied to production outside of git.

6. Monitoring and logging

The server is reviewed weekly for anomalies, resource trends, stale configuration and security posture, beyond what the automated checks verify.
One automated daily report goes to a single monitored channel and assembles every check described above. It covers disk and memory, out-of-memory events, service state, authentication logs, fail2ban activity, TLS certificate expiry, and per-process memory. It alerts on change rather than state.
System logs are persisted to disk with a retention cap.

Backups. Databases are dumped nightly, compressed and encrypted at rest with a key held outside the backup directory. Each dump is verified at the moment it is written, by decrypting it, decompressing it and checking for the marker the dump tool writes only on completion. A dump is written to a temporary file and moved into place only after it has been read back. Retention is fourteen days for data that exists nowhere else. Restores are exercised into a scratch database and verified against live row counts.

These dumps sit on the same host as the databases, so they answer a bad migration or a corrupted table rather than the loss of the machine. That second case is covered separately: the infrastructure provider takes nightly and weekly whole-server backups held off the host, retaining at least seven days.

7. Incident response

With a single operator, incident response is a sequence rather than a staffed rota:

Contain. Revoke the affected credential first. For a third-party data connection this means revoking the item in the provider's dashboard, which invalidates the stored token immediately.
Assess. Determine what the credential could reach and over what period, from the authentication and application logs.
Notify. Inform affected individuals and the data provider without undue delay where consumer data may have been exposed.
Remediate. Close the cause before restoring the service.
Record. Write down what happened and what changed, and correct any control that the cause showed to be missing.

Security concerns may be reported to support@redmesastudios.com.

8. Consumer data, retention and third parties

Consumer financial data is obtained only with the individual's explicit consent, given through the data provider's own authorization flow. The company never sees or stores the individual's bank credentials.
Data is used solely to provide the service the individual asked for. It is not sold, rented, licensed or shared with third parties, and is not used for advertising or marketing.
Retention: financial records are retained for as long as the individual keeps the account.
Deletion: an individual may revoke a bank connection at any time, which stops all further data collection immediately. On request, all stored data for that individual is deleted within 30 days, except where retention is required by law.
Data providers are reviewed before use for their security posture, their handling of consumer data, and their own contractual restrictions.