Pia’s Security: Essential Q&A

In today’s digital landscape, understanding the security measures of technology services is crucial. At Pia, we recognize the importance of transparent communication regarding our security practices. This blog post addresses some of the most common questions about our security protocols, offering insights into how we ensure the protection and privacy of your data.

How does Pia control, monitor, and store credentials for access to partner tenants?

Our support teams do not have access to your tenant portal directly, we use a separately hosted and controlled tenant admin portal, which our staff logs into using their Pia account credentials via Microsoft Office 365 authentication.

Our staff requires 2FA to authenticate to all our systems, including the Knowledge@Pia  portal. In the tenant admin portal, each staff member is assigned a specific role that corresponds to their job role at Pia:

• Administrator – Full access to partner tenants (heavily restricted)
• Solutions Engineer – Can perform all actions on your tenant while your tenant is in “onboarding mode” until your tenant leaves onboarding
• BAU Engineer – Can access live packages view and client configuration. Cannot use the Pia chatbot, execute automations or modify automations
• Partner Reports – Can only access reporting, such as the adoption report. Used by our Partner Success Team

Credentials for the backend hosting environment (Azure) are on a per-user basis – this is a separate Azure tenant to our main Pia business account with separate Azure AD and users.

There are 3 people in Pia with privileged access to the Azure subscription (Our CIO/CISO, CTO, and Head of Development) and a further 3 people in our BAU support team with heavily restricted access to perform basic support operations (restart services and view logs). Each user authenticates with a separate set of credentials to their normal Pia accounts with MFA enabled.

What strategies does Pia have in place for SIEM, SOC, etc?

We have Microsoft Defender enabled on most services in Azure, including VMs, Storage, and Databases (Azure SQL)

Alerts are configured to go to our CIO/CISO, CTO, Head of Development, and Service Desk teams, who have processes to deal with security incident notifications if they occur.

Does Pia separate customer data from the main infrastructure?

Yes. All data is isolated into separate databases per tenant and stored on a separate Azure Tenant. Any Pia staff who have access to the hosting platform for Pia have a separate username and password to authenticate to it.

Does Pia work with other third parties to deliver its SaaS solution and what are their security protocols?

By virtue of hosting Pia in Azure, we leverage Microsoft’s platform. Our relationship with Microsoft is primarily at an account/billing level and occasional “arm’s length” technical consultation. We purchase Microsoft services via a Cloud Service Provider/Reseller, which has limited access to our Azure Tenants for licensing and billing purposes (they do not have access to the Azure subscriptions themselves).

Aside from the above, no third parties have access to the Pia platform – we do not work with third parties to deliver the Pia SaaS solution. We do not send your data externally to Pia’s platform.

What are Pia’s disaster recovery plans?

Our disaster recovery approach is centered around the Microsoft Azure platform. Our architecture incorporates components available in Azure to ensure our ability to recover from a disaster scenario.

At a summary level, our disaster recovery plan allows us to:

• Perform point-in-time database recovery for a Pia tenant in the event of data corruption.
• Perform Tenant restore (typically done via a rebuild of the tenant) from just the database (and Azure IOT Hub service for agent connection recovery).
• Recover from an Azure regional outage to a new region at the service level (i.e., Virtual Machine, Storage, DNS, etc.).

Our process is:

1. Once an issue is identified (either internally or via a partner), it must be logged by the person receiving the information to the Pia Service Desk
   
   
2. The Service Desk will perform an initial assessment of the issue to verify a disaster scenario, such as:

   a. How many partners are affected?
   b. Are services offline? Can they be restarted?
   c. Are there outage notifications on Microsoft Azure’s monitoring dashboard?
   
   

3. If the Service Desk is unable to restore services via their standard operating procedures, they are to escalate internally to our DevOps team for confirmation of an outage and further investigation.

   a. At this point, the Service Desk must notify the COO and CTO of a possible outage/disaster scenario. The COO and CTO will further forward the outage to the entire Pia executive team depending on the severity and tenants affected
   b. The Service Desk shall communicate back to the partner within our standard response times with information about the issue and notify the partner that the issue has been escalated internally upon completion of the initial assessment
   c. If the service desk can restore the services, they will respond to the partner and inform them of the outcome and work with the partner until a resolution is reached or escalation is required
   
   

4. The DevOps team will troubleshoot and analyze the issue to identify components affected by the disaster scenario to determine the extent of any damage to the partner(s) tenant.
   
   
5. The DevOps team will select the appropriate recovery plan for the services affected (which may range from restoring a database to rebuilding a tenant to restoring a tenant into a different region)
   
   
6. The DevOps team will execute the most appropriate recovery plan for the scenario.

   a. The DevOps team may also use a “wait and see” approach depending on the actual outage observed and services affected on the Microsoft Azure platform, as Microsoft performs their own recovery actions on their platform, which may result in restoring services within a reasonable timeframe.
   
   

7. Once the recovery plan is executed, the service desk will update the partner and inform them of restored services.
   
   
8. Our DevOps team will continue to monitor the tenant until normal operations have been restored and the incident can be closed.
   
   
9. Once the incident has been closed, an incident report will be completed by our DevOps and Service Desk teams and disseminated to the Pia Executive team.

Does Pia perform routine disaster recovery tests?

During the year, we do partial disaster recovery tests of limited scenarios, such as recovering a tenant from only a tenant database backup and restoring differential backup into an otherwise fully functional tenant.

During our annual compliance review, we perform a full disaster recovery test, which includes recovery of agent communications to our backend infrastructure, Azure Subscription failure recovery to another region, and Azure Subscription as well as partial tests as mentioned above.

Does Pia have third-party security reports, and can we see them?

Yes! Pia is SOC2, ISO 27001, HIPAA, and GDPR certified. You can find the letter of attestation for each of these certifications here: https://pia.ai/security-commitments.

Can Pia provide more detailed information about its Cloud Security?

Yes! Please refer to detailed information below

Vulnerability Scanning

What product does Pia use?
Microsoft Defender

Logging and Monitoring

Are those logs and alerts monitored 24/7?
Alerts are generated to our Service Desk which will triage and escalate as appropriate. High urgency alerts are SMS alerted to our DevOps team who are on call 24/7.

Encryption at rest and in transit

Which Specific TLS/SSL protocols does Pia utilize?
Encryption at rest for the primary data store of your Pia Tenant is done using TDE provided by Microsoft Azure. For more information, you can read this article: https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption?view=sql-server-ver16

• Encryption in transit is a broader concept, as there are multiple protocols in use on Pia’s platform:
  • All Web traffic is HTTPS only and is encrypted using TLS1.2
    • For TLS1.2 the ciphers are defined on Microsoft’s website for Azure Web App
  • Websocket communication is encrypted using TLS1.2
  • All communication between the agent and your tenant’s REST API is double encrypted, first with TLS1.2 and then with an individual agent certificate pair.
    • For the Pia Agent (Agent Client), we use RSA Encryption (4096 bit), certificates and keys are stored in the certificate store on the relevant machine where agents are installed
    • For agent server certificates, we use RSA Encryption (4096 bit). Keys are stored in the tenant database. This key is further encrypted at rest using AES Encryption (AES key stored in Azure Key Vault).
  • All SQL connections are encrypted using TLS, refer to Microsoft’s article here: https://learn.microsoft.com/en-us/azure/azure-sql/database/connect-query-content-reference-guide?view=azuresql#tls-considerations-for-database-connectivity

Security at Pia is a top priority. We hope this Q&A has provided valuable insights into our security measures and practices. If you have any more questions or need further information, feel free to reach out to us.