Security Overview

A deep respect for our customers and their sensitive data workflows has always been central to our values at Perguidex. This is why we have implemented rigorous security policies that we continue to build upon, with every product release.

We are Committed to Information Security and Privacy

Perguidex maintains a comprehensive information security program that includes appropriate technical and organizational measures designed to protect our customers' cluster data against unauthorized access, modification or deletion.

We isolate customers from each other

All customers are isolated within their own Postgres database with unique and randomly generated credentials, secured and encrypted using Kubernetes Secrets. All customers are isolated inside of their own namespace within Kubernetes, with network policies, roles, and other security measures in place to ensure each tenant is truly isolated.

We provide SSO access to the platform

Workspace owners have the option to enable secure Single Sign-On access to the platform.

We proactively monitor the service

We regularly check our service monitoring dashboards and have alerts set up to notify our team if anything ever looks out of place. 

Unusual network patterns or suspicious behavior is monitored. Google Cloud Platform’s intrusion detection and prevention systems (IDS/IPS) rely on both signature-based security and algorithm-based security to identify traffic patterns that are similar to known attack methods. IDS/IPS involves tightly controlling the size and make-up of the attack surface, employing intelligent detection controls at data entry points, and developing and deploying technologies that automatically remedy dangerous situations, as well as preventing known threats from accessing the system in the first place. 

Perguidex does not provide direct access to security event forensics, but does provide access to the engineering and customer support teams during and after any unscheduled downtime.

We audit continuously during the development process

Perguidex audits changes to our application throughout the development lifecycle via architecture reviews and stringent automated and manual code review processes.

We've Built In Security Controls

We've taken significant measures to ensure that Perguidex customer data cannot be read, copied, modified, or deleted during electronic transmission, transport, or storage through unauthorized means. 

To reduce the likelihood of vulnerability-related incidents, the Perguidex team deploys stances based on the latest operating system kernels, and patches the computing “fleet” whenever a critical CVE (i.e., "Common Vulnerability and Exposure," in security-speak) is discovered in any component software. 

Clusters are deployed behind proxies and are not visible to internet scanning. Transport Layer Security (TLS) encrypted communication from the Internet is provided in the default configuration. Perguidex nodes run in isolated containers, configured according to the principle of least privilege, and with restrictions on system calls and allowed root operations. Perguidex nodes communicate using TLS. Cluster data is encrypted at rest. API access is limited to Perguidex APIs, and no remote access to the instance or container at the Linux level is allowed. Containers have no means of setting up communication with containers from another cluster.

We do not perform Internet-based penetration testing against production Perguidex offerings, however, we do use third parties to perform application security assessments against the Perguidex software components used to deliver these services.

We Practice Responsible Vulnerability Management

Perguidex recognizes that software development inherently includes the possibility of introducing vulnerabilities. We accept and disclose vulnerabilities discovered in our software in a transparent manner.

We Operate in Compliance with the Principles of GDPR

Perguidex is operating in compliance with the principles of GDPR. Perguidex customers are covered via the Perguidex Data Processing Addendum (DPA).

Protecting Your Account

At Perguidex, we know that security is everyone's responsibility. That's why we bake security into the development of our products and into the foundation of Perguidex Cloud. The security and privacy of your Perguidex Cloud SaaS data also relies on you maintaining the confidentiality of your Perguidex Cloud login credentials.

Here's a quick checklist:

  • Don't share your credentials with others.
  • Update your account profile to make sure information is correct and current.
  • Ensure that you've set secure passwords.
  • If you believe an account has been compromised, please contact us.
  • If you need to make an erasure request, please contact us.

Our Privacy Statement is Transparent and Clear

Perguidex respects the privacy rights of individuals. Our privacy policy makes it very clear when we collect personal data and how we use it. We've written our privacy policy in plain language to be transparent to our users and customers.

We Operate on a Modern Cloud SaaS Platform

We use Google Cloud Platform for our Cloud datacenter, which means our customers benefit from GCP's comprehensive security practices and compliance certifications. We do not host customer data on our premises or store customer data with any other third party services. GCP is a leading cloud provider that holds industry best security certifications such as SOC2 and ISO 27001 and provides encryption in transit and at rest.

Perguidex Cloud is hosted on infrastructure that we control via GCP's Google Kubernetes Engine, in GCP. To allow it to communicate with your systems, we run a single NAT that all internet bound traffic flows through. We don't persist any of your data, and all computation runs in short-lived containers that terminate after tasks are completed.

Our cluster and databases are all hosted in a private VPC with all private IPs. We connect to the cluster via SSH to a bastion node set up with authorized networks. We use the GKE managed firewall rules at the VPC layer.

Physical Access Control

Perguidex is hosted on the Google Cloud Platform. Google data centers feature a layered security model, including extensive safeguards such as:

  • Custom-designed electronic access cards
  • Alarms
  • Vehicle access barriers
  • Perimeter fencing
  • Metal detectors
  • Biometrics

According to the Google Security Whitepaper: “The data center floor features laser beam intrusion detection. Data centers are monitored 24/7 by high-resolution interior and exterior cameras that can detect and track intruders. Access logs, activity records, and camera footage are reviewed in case an incident occurs. Data centers are also routinely patrolled by professional security guards who have undergone rigorous background checks and training.”

Perguidex employees do not have physical access to Google data centers, servers, network equipment, or storage.

Network Access Control

Perguidex is the assigned administrator of its infrastructure on Google Cloud Platform, and only designated authorized Perguidex operations team members have access to configure the infrastructure on an as-needed basis behind a two-factor authenticated virtual private network. Specific private keys are required for individual servers, and keys are stored in a secure and encrypted location.

Penetration Testing

Perguidex undergoes vulnerability assessment and penetration testing, conducted by an independent, third-party agency on an annual basis. For our enterprise level customers we're happy to provide the results of their findings and the mitigation we applied.

Third-Party Audit

Google Cloud Platform undergoes various third-party independent audits on a regular basis and can provide verification of compliance controls for its data centers, infrastructure, and operations. This includes, but is not limited, to SSAE 16-compliant SOC 2 certification and ISO 27001 certification.

Business Continuity and Disaster Recovery

High Availability

Every part of the Perguidex service uses properly-provisioned, redundant servers (e.g., multiple load balancers, web servers, replica databases) in the case of failure. As part of regular maintenance, servers are taken out of operation without impacting availability.

Business Continuity

Perguidex keeps continuous encrypted backups of data on the Google Cloud Platform. While never expected, in the case of production data loss (i.e., primary data stores lost), we will restore organizational data from these backups.

Disaster Recovery

In the event of a region-wide outage, Perguidex will bring up a duplicate environment in a different Google Cloud Platform region.

Data transit

Data into servers

All the incoming connections towards our servers are required to be encrypted with industry standard SSL encryption. Latest SSL Labs report can be found here.

Data between our servers

Connections between our servers (i.e. web servers <-> databases) are encrypted via TLS with a AES-256bit encryption method. Secrets such as database password, API secrets are encrypted using the same AES-256bit method.</->

Data out of our servers

Once the request is processed, the response is sent back using the same HTTPs SSL encrypted connection.

Data Security and Privacy

Data Encryption

All data in Perguidex servers is automatically encrypted at rest. Google Cloud Platform stores and manages data cryptography keys in its redundant and globally distributed Key Management Service. So, if an intruder were ever able to access any of the physical storage devices, the Perguidex data contained therein would still be impossible to decrypt without the keys, rendering the information a useless jumble of random characters.

Encryption at rest also enables continuity measures like backup and infrastructure management without compromising data security and privacy.

Perguidex exclusively sends data over HTTPS transport layer security (TLS) encrypted connections for additional security as data transits to and from the application.

Data Retention & Removal

We do store all data for up to 6 years unless your account is deleted. In which case, we dispose of all data in accordance with our Terms of Service and Privacy Policy, within 60 days. Information regarding legal transactions between customers and Perguidex will be stored for up to 10 years.

Security Training

All new employees receive onboarding and systems training, including environment and permissions setup, formal software development training (if pertinent), security policies review, company policies review, and corporate values and ethics training.

All engineers review security policies as part of onboarding and are encouraged to review and contribute to policies via internal documentation. Any change to policy affecting the product is communicated as a pull request, such that all engineers can review and contribute before internal publication. Major updates are communicated via email to all employees.

Disclosure Policy

Perguidex follows the incident handling and response process recommended by SANS, which includes identifying, containing, eradicating, recovering from, communicating, and documenting security events. Perguidex notifies customers of any data breaches within 2 business days via email or phone call, followed by periodic updates throughout, addressing progress and impact.

Systems status live report

Perguidex maintains a live report of operational uptime and issues on our status page

Incident response plan

In case of a security incident it's best to have a clearly defined plan and responsibilities. Below you will find more details regarding the response plan that Perguidex has in place in the unlikely case of a security breach.

Responsibilities

Level 1: Depending on how the incident is reported/discovered we generally have the first level of technical support that is likely to triage/escalate the issue. Normally that role is reserved for whoever is on the level 1 tech support shift at the time.

Level 2: Is a senior engineer or CTO that classifies the impact of the security incident. 

Level 3: CTO or CEO is responsible for the communication with the affected parties regarding the details of the breach.

Triage process

Before escalating the incident to the next level, the person that first finds out about it needs to verify the incident and its initial impact.

Escalation process

Once verified the escalation process should be immediate to level 2 and then level 3 verbally, by phone, email, whatever medium available.

Classification process

Once escalated the rank/severity of the incident must be determined. Does it affect all customers? A single company? An individual? What type of data was affected if any? Was it encrypted? If so, how?

Investigation process

Analyze all elements of the incident in order to identify all the causes or where a failure occurred including the software, hardware, people, and internal processes.

Lessons learned

Based on the result of the investigation, determine what could be done to prevent this attack and what defensive mechanisms failed and take immediate action to re-mediate the cause and improve the future process.