Security Principles
Last updated
Was this helpful?
Last updated
Was this helpful?
Whaly production data is processed and stored within , which use state-of-the-art multilayer access, alerting, and auditing measures, including
perimeter fencing
vehicle access barriers
custom-designed electronic access cards
biometric checks
laser beam intrusion detection
continuous external and internal security camera surveillance
24x7 trained security guards
All servers that run Whaly software in production are recent, continuously patched Linux systems. Additional hosted services that we utilize, such as Google Cloud Storage, are comprehensively hardened Google infrastructure-as-a-service (IaaS) platforms.
Our web servers encrypt data in transit using the strongest grade of HTTPS security (TLS 1.2) so that requests are protected from eavesdroppers and man-in-the-middle attacks. Our SSL certificates are 2048 bit RSA, signed with SHA256.
Internal tier-to-tier requests are signed and authenticated to prevent request forgery, tampering, and replay.
All persistent data is encrypted at rest using the AES-128 standards or similarly high standards, allowing Google Compute Engine to have successfully completed ISO 27001, SSAE-16, SOC 1, SOC 2, and SOC 3 certifications.
Employee computers have strong passwords, encrypted disks, firewalls, and, where applicable, inbound and outbound network traffic monitoring and alerting. No Windows computers or servers are used at all other than in isolated testing environments. A large and increasing percentage of employees use Macbooks exclusively for maximum defense against malware.
We follow the principle of least privilege in how we write software as well as the level of access employees are instructed to utilize in diagnosing and resolving problems in our software and in response to customer support requests.
All changes to source code destined for production systems are subject to pre-commit code review by a qualified engineering peer that includes security, performance, and potential-for-abuse analysis.
Prior to updating production services, all contributors to the updated software version are required to approve that their changes are working as intended on staging servers.
Whaly infrastructure utilizes multiple and layered techniques for increasingly reliable uptime, including the use of autoscaling, load balancing, task queues and rolling deployments. We make point-in-time backups that are stored and encrypted in a private Google Cloud Storage Bucket.
Exposed server endpoints are recurrently tested for vulnerabilities using multiple types of scanning software as well as manual testing. Request-handling code paths have frequent user re-authorization checks, payload size restrictions, rate limiting where appropriate, and other request verification techniques. All requests are logged and made searchable to operations staff.
Client code utilizes multiple techniques to ensure that using the Whaly application is safe and that requests are authentic, including
IFRAME sandboxing
XSS and CSRF protection
signed and encrypted user auth cookies
remote invalidation of extant sessions upon password change/user deactivation
All access to Whaly REST API endpoints require an access key that can be regenerated on demand by customers.
Integrations with other applications are all opt-in and authenticate via OAuth or other applicable mechanisms required by the third party application. Integrations can be disabled at any time.
We use Stripe for payment processing and do not store any credit card information. Stripe is a trusted, Level 1 PCI Service Provider.