As an enterprise service provider, Epsagon understands that the security of the user data collected and stored by our customers is nothing less than critical. To deliver the peace of mind that our customers deserve, we believe in transparency regarding Epsagon's security standards and practices, which are constantly evolving to protect against security breaches and provide full confidentiality, data integrity, and availability.
Most importantly, you control exactly what data Epsagon records and stores. Please keep in mind as you review the security information below that the most effective way to minimize security exposure is to avoid storing unnecessary sensitive data in the first place.
- Data sent from the Epsagon agents may contain event payloads (e.g. headers in API Gateway, DynamoDB item, SQL queries). By default, only metadata will be sent (duration, timestamp, etc). However, users can enable full payload ingestion as an agent-level configuration to receive a wider scope of information.
- Tracers can be configured to allow/block specific keys or endpoints to ingest data from.
- Trace data is securely sent and encrypted before stored in our data warehouses hosted on AWS utilizing AES-256 encryption.
- Data from AWS Lambda's CloudWatch logs (invocations) is being filtered according to relevant lines only (REPORT, Task timed out, etc).
- Only metrics data is being stored on Epsagon’s end (duration, used memory, and AWS request ID).
Epsagon builds on AWS's compliance with leading standards for privacy and information security, including recurring re-examination by independent auditors. All data is encrypted in-flight and at rest. Administrative access to our servers and data requires login with two-step authentication.
In addition, Epsagon is an AWS advanced technology partner, with 4 competencies:
We force all network exchanges between our agents and servers to take place over TLS v1.2. Data stored in our backend is then both encrypted in transit and at rest utilizing AES-256 encryption.
Epsagon supports SAML, SSO (single sign-on), and/or federated login via Github and Google. Please contact Support if you have further authentication requirements.
If any sensitive data or PII is sent to Epsagon, please contact Support.
We utilize internal and third-party systems to monitor the confidentiality, integrity, and availability of our platform. If an incident occurs, a team of engineers are alerted immediately. Platform availability can be confirmed on our Status Page
We conduct routine vulnerability scans, penetration tests, and ensure our development efforts follow industry-standard guidelines and best practices.
With Epsagon, you can explore, search and view any suspicious sessions in near real-time. Security engineers can replay sessions to quickly understand user behavior, instead of scouring through server log files.
At Epsagon we follow the principle of least privilege.
We use Google SSO to verify employee account identity and require physical security keys and/or two-factor authentication for all internal applications, without exception. Access to administrative interfaces additionally enforce administrator permissions where applicable, and all administrative access is logged and auditable both in the form of traditional web server logs as well as via Epsagon itself to make it easy to find and review any administrative activities with full fidelity. For third-party SaaS providers, we utilize Google as an identity provider wherever possible to provide a single point of access control across all employee facing applications and services.
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.
Epsagon infrastructure utilizes multiple and layered techniques for increasingly reliable uptime, including the use of autoscaling, load balancing, task queues, and rolling deployments. Due to the very large amount of data that Epsagon stores, we do not currently make point-in-time backups, although we do use highly redundant data stores and/or rapid recovery infrastructure, making an unintentional loss of received data due to hardware failures very unlikely.
Updated about a month ago