Enterprise Security Practices
Everest is designed following enterprise security principles — encrypted credentials, HTTPS-enforced management, tenant isolation, audit logging, and disaster recovery protection.
Important: Everest is designed with enterprise security practices in mind. Formal certifications (SOC2, ISO 27001, etc.) are not currently claimed. The security features described on this page reflect implementation status at the current release. Planned features are clearly marked.
Designed for enterprise deployment
Every component of Everest is designed to handle surveillance infrastructure with the care that operational security requires.
Credentials are never stored in plaintext in version-controlled configuration files
All cloud communication uses HTTPS/TLS — no unencrypted cloud data transfer
Management interface access is enforced over HTTPS with JWT session management
Tenant data is logically isolated using license key-scoped S3 object key prefixes
All administrative actions are recorded in structured audit logs
Health monitoring and auto-recovery reduce manual intervention that could introduce risk
Stub files are self-contained and do not expose cloud credentials directly
Database WAL mode and isolated transactions protect against data corruption
Security feature status
Security feature breakdown
Encrypted Cloud Credentials
Cloud provider access keys and secret keys are stored encrypted at rest. Credentials are never written to disk in plaintext. Encryption key management is handled through the Everest agent with a backup stored to S3 protected by the site license key.
- AES-based credential encryption at rest
- No plaintext credentials in configuration files after initial setup
- Encryption key backed up to S3 with administrator approval
- Credential backup protected using site license key
HTTPS-Enforced Management Interface
The Everest admin portal enforces HTTPS communication. A self-signed certificate is generated at first launch with guidance to replace it with a CA-signed certificate for production environments.
- TLS-enforced admin portal on all interfaces
- Self-signed certificate generated at first launch
- Configurable certificate replacement with CA-signed certificate
- HTTP redirect to HTTPS enforced
Role-Based Access Control
The admin portal supports role-based access control with administrator and read-only roles. JWT token-based session management is used for portal authentication.
- Administrator role: full configuration and management access
- Read-only role: monitoring and metrics access only
- JWT token-based session authentication
- bcrypt password hashing for administrator credentials
Tenant Isolation
Each deployed tenant operates with their own license key, credentials, database, and cloud storage partition. The license key forms part of the S3 object key prefix, ensuring tenant data is logically separated in shared storage environments.
- License key embedded in S3 object key prefix
- Per-tenant SQLite database (local) and optional PostgreSQL (central)
- Per-tenant JWT signing keys
- Separate audit log per tenant
Audit Logs
All lifecycle state changes, cloud deletion events, administrator actions, license events, and configuration changes are recorded in a tamper-evident structured audit log.
- ISO 8601 timestamps on all log entries
- Log includes actor identity, action, component, and file path
- Cloud deletion events recorded with before/after state
- Log rotation with configurable size limits
License Key-Based Site Authentication
Each Everest deployment is tied to a unique license key. License validity is continuously validated against the central licensing service over TLS. A configurable grace period prevents service interruption during brief licensing server outages.
- Per-site unique license key assignment
- Periodic re-validation over TLS
- Grace period for transient network outages
- License expiry triggers configurable alert and eventual service pause
Disaster Recovery Protection
Everest backs up the SQLite metadata database, INI configuration, and encrypted credentials to S3. Post-restore checksum verification ensures data integrity after site recovery.
- Database backup to S3 on configurable schedule
- Configuration and credentials backed up to S3
- Post-restore checksum verification
- DR backup protected with site encryption key
Signed Builds and Driver Signing
Production releases are designed to support code signing for both the .NET agent application and kernel driver packages. Application signing and driver WHQL signing readiness are planned for production distribution releases.
- Application code signing: planned for production release
- Linux .deb package signing: planned
- Windows minifilter driver WHQL signing: planned
- Build pipeline signing integration: in design
Compliance and certification roadmap
Everest is designed with enterprise security practices as a foundational requirement. Formal compliance certifications are not currently claimed and will be pursued as part of the enterprise release roadmap. Security-sensitive deployments are encouraged to perform their own security assessment using the documentation and configuration reference guides available in the Downloads section.
Discuss security requirements with our team
Contact us to review security practices, deployment architecture, and planned certification roadmap for your specific requirements.