Zendesk Data Breach – How Am I Affected?
Zendesk experienced a data breach of 10,000 accounts. Users of Zendesk Support and Zendesk Chat whose accounts were activated prior to November 1, 2016, were affected.
According to Zendesk’s blog, unauthorized access to Zendesk customer information may have included:
- Agent and end-user names and contact information
- Usernames and hashed and salted passwords
- Transport Layer Security (TLS) certificates provided to Zendesk by customers
- App marketplace settings, including a small number of integration keys or passwords used by Zendesk apps to authenticate against third-party services
Source: Zendesk, Updated Notice Regarding 2016 Security Incident
Our Take
The customer contact information may pose a breach of personal privacy, invoking privacy legislation depending on jurisdiction.
Although passwords were hashed and salted, the disclosure of usernames may enable the use and increase success of brute-force attack on the known usernames.
The SSL certificate theft may be of concern. Transport Layer Security uses SSL certificates to enable secure site-to-site communications without the means of a dedicated circuit or VPN Tunnel. Today, SSL certificate validity periods are limited to up to two years, however, in 2016, SSL certificates of up to three years were available. And so, it is theoretically possible that a number of 2016 certificates are still in use, although three months still remain of 2019. This may be of concern to some organizations who are using such certificates in their Zendesk configuration. We recommend that Zendesk customers check their SSL certificate validity dates as soon as possible.
The integration keys and passwords may pose a security vulnerability to some organizations, particularly if those passwords have remained static since 2016. We recommend that Zendesk integration passwords are changed on a regular basis.
No one can predict when their service provider will get hacked and when their data will become exposed, but a number of precautions may help reduce risk and exposure on an on-going basis on any service, on-premises or cloud-based:
- Change your passwords regularly. These include any passwords related to integration accounts or operating system service accounts.
- Security certificates (also known as HTTPS or SSL certificates) should be set to expire/renew more frequently, possibly on an annual basis. Although the current industry Certificate Authority/Browser Forum (“CAB Forum”) specifies a maximum of 27 months, shorter timeframes to ensure that the credentials “renew” more frequently will help mitigate the risks described in this article. Note: It is imperative that you remember to renew the certificates within 30 days of their expiry!
- Review your data governance rules around what information can be stored on which cloud service. Conceivably, some cloud-based systems will require you to store highly confidential data (such as HRIS system storing employee data), however, if you can limit the type of information that is stored on a cloud service (say, nothing confidential on a cloud ITSM system), that will help mitigate privacy concerns around data breaches.