Epsagon Documentation

Welcome to the Epsagon Documentation. You'll find comprehensive guides and documentation to help you start working with our product as quickly as possible. Let's jump right in!

Get Started

Security and Privacy

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 unnecessarily sensitive data in the first place.

Data Stored in Epsagon

Data sent by Epsagonโ€™s tracing library

  • Data sent from the Epsagon library (traces) may contain events payload (e.g. headers in API Gateway, DynamoDB item, SQL queries). This is according to the userโ€™s configuration - by default, only metadata will be sent (duration, timestamp, ...) but if the user opts-in via a code configuration, the payloads will be sent as well.
  • Tracers can be configured to allow or disallow specific keys and endpoints to get data from. For more information get into the relevant tracing library.
  • Traces information is being sent securely and stored encrypted on our data warehouses, on AWS.

Data from CloudWatch logs

  • Data from AWS Lambda's CloudWatch logs (invocations) is being filtered according to relevant lines only (REPORT, Task timed out, ..).
  • Only metrics data is being stored on Epsagonโ€™s end (duration, used memory, and AWS request ID).

Compliance and Certifications

Epsagon Security Compliance

Epsagon is SOC2 Type II, ISO27001, CSA (Cloud Security Alliance), and Privacy Shield certified, and HIPAA and GDPR compliant.

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:

Application-Level Security

Data Encryption

We force all network exchanges between our code library and servers to take place over TLS v1.2. At our backend, all data is encrypted both at transit and at rest.

Sign-on Security

Epsagon supports SAML, SSO (Single sign-on), and/or social login. Please reach out with specific authentication requirements, and we will happily work with you to develop a custom security plan.

Data Erasure

At any time, an Epsagon client can send an email to [email protected] and request that all their customer data be erased from all Epsagon systems. The request will be carried out by the Epsagon operations team within 24 hours and be followed by an email response confirming the deletion of the data.

Data Retention

By default, any ingested payloads (traces, invocations, etc.) are being stored encrypted on our databases and retained for 7 days.
After 7 days, the data is being removed completely for our storage.

Monitoring and Testing

We use internal and third-party systems to monitor the confidentiality, integrity, and availability of our platform. If an incident occurs, a team of engineers is alerted immediately. And, if needed, we'll alert you (the customer) without delay.

We conduct routine vulnerability scans, penetration tests, and ensure our development efforts follow industry-standard guidelines/best practices.

Security Benefits of Using Epsagon

Epsagon can also produce substantial security enhancements for your own security practices.

Monitor and Audit Suspicious Activity

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.

Additional Policies

Employee Access

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.

We use Google account infrastructure 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 whenever possible to provide a single point of access control across all the apps that employees access as part of their job.

Code Reviews and Production Signoff

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.

Service Levels, Backups, and Recovery

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 2 days ago

Security and Privacy

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.