Fine Tuning: Optimizing security in your Zendesk
Manda hosted this discussion!
You can still participate:
- Read the best practices below that Manda shared during the day.
- Add a comment to ask a question or to share your own ideas!
This Fine Tuning session was about Security, including:
- Securing access to Zendesk
- Identifying sensitive data in your account
- Preventing phishing or social engineering attacks
Zendesk Customer Success Executive Manda Choi has been with Zendesk since February of 2014 but brings over ten years' of experience in customer success with various SaaS companies.
See all the Fine Tuning series discussions.
How to make your Zendesk as secure as possible
With more than 40,000 customers who use Zendesk, security isn’t a one-size-fits-all solution for everyone. The risk or threat each company faces is dependent on a number of factors such as their industry, brand recognition, and the type of customer data they have access to. Although there are default security settings in place, we also provide a wide range of security options to ensure that your information is protected.
Today, with the help of the security team, I will cover three main security topics:
- Securing access to Zendesk
- What to do with potentially sensitive data in your account
- How to prevent phishing and social engineering attacks
Part 1, 8am: Securing Zendesk access
As a rule of thumb, we recommend the following to ensure that your Zendesk account is as secure as possible:
- Enhancing Password Security : Who isn’t guilty of having the same password for multiple accounts? However, if an account is hacked and your login information is discovered, this compromises the security of any other account you have that uses that same username and password. By requiring your agents to use unique logins and prompting agents to change passwords every x number of days, you lower your risk of having a compromised account. Because the default setting is set to low, you’ll want to immediately change this if you’re on the Professional or Enterprise plan (click here for more information) in order to enforce strong passwords.
- Limiting Admin Access : Because admins have greater access to the account than a typical agent, we recommend limiting the number of individuals who have this access. This ultimately reduces your security risk because you can quickly determine which admin made which change.
- Authenticate Users With Single Sign-On : Single sign-on (SSO) is an authentication process that allows a user to access multiple applications with one set of login credentials. This can be achieved in one of two ways: either through social media by logging in with your Gmail or Facebook login, for example, OR by logging into your corporate network and then accessing Zendesk via a link. Click here for more information.
- IP Restrictions : By restricting access to specific IP addresses, only users from those IP addresses will be able to sign into Zendesk. Note that this setting, which is available on Professional and Enterprise plans only, can be applied to all users or to agents only (learn more here).
- Routine Account Audits : From time to time, monitor your account for any suspicious activity via the audit log. Review the list of admins and agents to confirm that there are no unknown individuals or email addresses. If you’re using targets or email archiving, confirm the validity of the email address(es). Also, if you are on the Enterprise plan, you can monitor such security events as user suspensions, password policy changes, user assumptions, device authentications and data exports.
- Spam Filtering : Take advantage of the spam protection offered in your Zendesk. Not only can you mark a ticket as spam, but you can also suspend the requestor at the same time. Tickets that are marked as spam can be permanently deleted and the user suspended indefinitely. In addition, we also offer a spam filter for the Help Center which prevents posts from being published if they appear to be spam (more info here).
Now that we’ve talked about what Zendesk recommends for general best practices, what are some general best practices that you follow?
Part 2, 11am, Identifying sensitive data in your account
If Personally Identifiable Information (PII) such as credit card data or social security numbers in your Zendesk is a concern, there are a few approaches available to ensure that sensitive information isn’t being stored. If credit card data within your Zendesk is a concern, we’ve developed a new feature that can redact this structured data. The Ticket Redaction App (a Zendesk Labs app that is not supported) uses the Redaction API to permanently redact this data from your Zendesk. Another tool you can use is the new Automatic Redaction feature to block credit card information from even entering your Zendesk. Using the Luhn algorithm, the data is redacted when the ticket is incoming to prevent the full credit card number from being stored in Zendesk. This helps keep confidential information out of your account.
But what if you have compliance requirements to prevent storage of other PII, such as healthcare information or social security numbers? Furthermore, how can you provide access to your security team or auditors to verify this data doesn’t exist in your Zendesk?
The following details how you can export ticket data and scan for PII using third-party tools.
- Exporting Data : There are two ways to export your ticket data so that it can be scanned for PII: (a) export all ticket data, including comments, via XML; OR (b) use Zendesk’s incremental API to retrieve a list of modified tickets during a specific time period, then use the ticket API to retrieve all ticket data for those ticket IDs.
- Scanning : When you have a data file of your tickets, utilize a custom script or employ a Data Loss Prevention (DLP) tool to look for PII (note that your security operations team may have a commercial DLP tool, or you can use an open source tool such as Spider or SENF). This process will alert you to any tickets that may contain PII.
- Cleanup : After you understand which tickets have PII, you can permanently remove this data from your Zendesk using ticket redaction.
What processes do you have in place for identifying sensitive data?
Part 3, 2pm: Preventing phishing or social engineering attacks
Customer support agents are often the target of malicious behavior because of their access to sensitive information such as customer and/or company data. This type of data can include, but is not limited, to: contact information, billing information, passwords and password resets, organizational charts, account ownership changes and data lookups. If this information were to be accessed in a malicious manner, it could lead to your company or account being compromised.
The most common ways for support agents to be targeted is through phishing or social engineering. Phishing is an attempt to acquire sensitive information such as usernames, passwords or credit card details from a malicious group posing as a trustworthy entity. Social engineering is a term to describe an attempt to gain confidential information through human interaction. Because support agents are trained to help, the bad guys exploit this trait to gain the agent’s trust in the hopes that the agent will eventually provide sensitive information.
So what can you do to prevent this from happening? Based on our experience in managing incidents and helping customers manage attacks against them, we recommend the following:
- Develop a strong security structure : Set policies and promote a culture of data protection by reminding employees that they are not data owners, but data custodians. Make it easy for them to report any suspicious activity in their accounts to their managers or to the Information Security team by ensuring that clear processes are in place.
- Utilize technology solutions : Consider implementing a content filtering service (whether on the local machine or at the network level) to actively analyze and block any malicious links or attachments. Additionally, utilize browsers that take advantage of services like Google’s Safe Browsing that can block known phishing attempts.
- Regular training on phishing and social engineering : On a regular basis, conduct security awareness training. Consider reinforcing this education by conducting phishing or social engineering attacks against your own employees (there are many third-party tools and services available to assist with this). Record the number of employees who clicked a malicious link, the number who actually provided sensitive info, and, finally, the number of employees who did not click the link, but instead reported the attack to the Information Security team. Share the macro results within your company to gamify and improve on the numbers.
- Implement strong security identity processes : Customer service organizations should have tight processes in place around password resets and requests for account owner changes. Ensure that you have defined and communicated how to confirm an individual’s identity before any change is made in order to lower the risk of customer impersonations.
Last question: What methods do you employ to ensure your support agents aren’t providing information to malicious parties?
We hope you found today’s posts helpful. As mentioned, security isn’t a one-size-fits-all solution so we’re here to help you determine what’s right for you so that you can focus on what’s most important: your customers.
-
Hi everyone! Part 1 is now posted - come and check it out!
-
Manda, thanks for posting. I am going to start with a bugbear of mine and that is that you can only assign the Spam permission to agents if you are willing to give them rights to delete tickets. Currently I give them a SPAM macro which simply puts the tickets in a queue for me. It is quite surprising what some of my agents consider as spam (even emails form the CEO) so perhaps the way I do things is best for now :)
I haven't implemented IP Restrictions as part of why I chose Zendesk in the first place was for the ability to use it from anywhere. One thing that would help however is if the Audit log also included where and when agents logged in.
-
Thanks for your feedback on both points, Colin. We're constantly looking for ways to improve our product, so I'll be sure to share your feedback with the appropriate teams here.
-
Part 2 is now up...feel free to post comments or questions here!
-
Come by to read my final piece on optimizing security in your Zendesk accounts.
-
@Collin, I understand your frustration but we've restricted the ability to mark as spam for that very reason. Also, the resulting user suspension has serious consequences.
Your request to add more agent authentication events to the Audit Log is a good one, but I'm wondering if it would be more useful if shown instead on a user's profile? I'm concerned about a high level of noise in the Audit Log for accounts with a large number of users.
-
Ben, it was not "frustration", just a bugbear. You can unsuspend a user but you cannot undelete a ticket so when agents delete a ticket for any other reason, I have an issue. At least when they delete a ticket as spam, there is a strong possibility that we did not want that ticket.
I understand what you mean about the audit log but "noise" does not seem like a good reason to split similar data in to multiple places. Perhaps a filter option would be beneficial for the type of audit entry.
-
@Colin: a filter option would be a great way to hide/show these type of events
-
We are using ZenDesk in a setting where some of our clients are working on topics that require sensitivity to the visibility of their support requests and confidence that only a limited set of approved agents can see and work with those tickets. Does ZenDesk support such constraints?
Furthermore, these same clients would prefer to use anonymized accounts where their only interaction with the support system is via the web interface: they do not expect to receive emails and will not provide email addresses.
Is that kind of interaction pattern possible?
-
Hello Ian,
yes, it is possible to define such access restrictions as you described them. In Zendesk that means defining "custom agent roles". That is feature which is available on Enterprise plans and you find more about this here:
Through that you can define an agent's access to tickets, the types of comments they can make, and their editing permissions.
Also customers could create a generic Mailaccount for themselves and use that to login to your Help Center. From there they can access their tickets, see the communication and reply. In this video, starting from 1:04 min, you will see how the user perspective looks like. They see a list of their tickets in "My activities":
You find all infos about creating your own Help Center here:
I hope that helps,
Please sign in to leave a comment.
10 Comments