Frequently Asked Questions
Here are some of the questions that are frequently asked regarding Pia's Security and our answers to them.
If you have more questions, please contact your Partner Success Manager and we will get back to you.
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 login to using their Pia account credentials via Microsoft Office 365 Authentication.
Our staff require 2FA to authenticate to all of our systems, including this portal. In the tenant admin portal, our staff each are assigned specific roles which correspond 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 do we have now or what strategies do we have in place for SIEM, SOC etc?
We have Microsoft Defender enabled on most services in Azure, including VM's, 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.
Do you 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.
Do you work with other third parties to deliver your SaaS solution? If so (and if they have access to your data) then what do their security protocols look like?
By virtue of hosting Pia in Azure, we leverage Microsoft’s platform. Our relationship with Microsoft 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, there are no third parties with 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 is/are Pia’s disaster recovery plans?
Our disaster recovery approach is centred 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 (DRP) allows us to:
- Perform point in time recovery of a database for a Pia tenant in the event of data corruption.
- Perform Tenant restore (which is 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:
Once an issue is identified (either internally or via partner) it must be logged by the person receiving the information to the Pia Service Desk.
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
If the Service Desk are 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 initial assessment
c. If the services can be restored by the service desk, 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
The DevOps team will perform troubleshooting and analysis of the issue to identify components affected by the disaster scenario to determine the extent of any damage to the partner(s) tenant.
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)
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 perform their own recovery actions on their platform which may result in the restoration of services within a reasonable time frame.
Once the recovery plan is executed, the service desk will update the partner and inform them of restored services.
Our DevOps team will continue to monitor the tenant until normal operations have been restored and the incident can be closed.
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.
Do you perform routine disaster recovery tests?
During the year we do partial disaster recovery tests of limited scenarios such as recovery of a tenant from only a tenant database backup and restoration of 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 a third-party report, preferably Soc 2 Type 2 (an ISO 27001 report would be great too), that we can review? If they have both types of reports, can we see both?
Yes! These can be provided on request to our CIO/CISO – please reach out to your Partner Success Manager to request this and they will make sure it gets to the right place.
Can we review Pia’s latest penetration testing report as well as will they share if they have remediated their findings?
Yes! These can be provided on request to our CIO/CISO – please reach out to your Partner Success Manager to request this and they will make sure it gets to the right place.
Can Pia provide more detailed information around the following items listed in Cloud Security?
Vulnerability Scanning
- What product does Pia use?
- Microsoft Defender
Logging and Monitoring
- Are those logs and alerts monitored 24/7? Does the Security/Support team monitor and act on those alerts around the clock?
- 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