Protecting Zendesk Against Email Threats Using Material Security

Introduction

If you’re a security practitioner, you know the real-world email attack surface isn't just your Google or Microsoft inbox: it’s the entire ecosystem of cloud applications linked to support and other accounts your company uses. 

In particular, support platforms like Zendesk are often fed by widely-publicized email addresses like support@yourcompany.com. Since these addresses are public, they’re a ripe target for attackers. 

One of the most common integration methods for these platforms is a simple email forward, and that by itself should set off a few alarm bells. Forwarding rules can create a significant visibility gap, routing potentially malicious emails around your primary mailbox security controls. This isn’t a theoretical problem; it’s a practical one that demands a practical solution.

We came up with a simple, repeatable automation for extending threat detection and response into these third-party applications combining Material's protections, a SOAR or workflow automation tool, and the platforms' own APIs.

The challenge: Forwarding breaks the security chain

Like all modern email security solutions, Material uses Google Workspace and Microsoft 365 APIs to analyze and remediate messages shortly after they are delivered to a mailbox. Zendesk, like other support platforms, typically uses email forwarding to get mail from a company’s support email address into their platform. 

This presents two main challenges: messages are typically forwarded and not retained in the support mailbox so there is nothing for Material to analyze. Even if messages are retained, Zendesk doesn't pick up any updates. Note that while Zendesk supports using an OAuth integration (instead of forwarding) for smaller volumes, this only solves for the first problem, but the second remains.

The solution: An API-driven security workflow

To solve this, we need to let Material inspect the email and then programmatically extend our remediation actions into the support platform. The "glue" for this is a perfect use case for a SOAR (e.g., Tines, Torq, Palo Alto XSOAR) or an iPaaS/automation tool (e.g., Okta Workflows, Workato). Material provides an event notification system and a robust API, and Zendesk has its own APIs: all we need is a workflow to connect them.

The pattern is straightforward and adaptable for almost any platform with an API:

1. Retain the Message: First, configure the support mailbox (such as support@yourcompany.com) to retain a copy of all forwarded mail. This gives Material a message to analyze.
2. Detect and Alert: Material analyzes the message upon delivery. If a threat is found, our platform emits a detailed event notification, which can be sent to a webhook.
3. Trigger the Playbook: Your SOAR platform ingests this webhook, triggering a specific playbook for what is now a new malicious ticket in Zendesk.
4. Execute Remediation via API: The playbook uses Zendesk's API to find the ticket created by the forwarded email and take direct action on it.

In practice: Executing remediation via the Zendesk API

We used Tines to build the workflow automation between Material and Zendesk for this exact scenario and have published the story in the Tines Library. Even if you aren’t using Tines, it’s a great reference for the necessary API calls and logic.

Let's walk through an example. Material flags an email containing a credential phishing link that was sent to support@yourcompany.com. The SOAR playbook kicks off and executes a series of API calls to Zendesk to:

• Add a private warning comment. The first action should be to add a private comment to the top of the ticket. This immediately alerts the support agent to a potential threat and can provide context on what’s being done automatically.
• Redact the malicious link. We use Zendesk's comment redaction API endpoint to redact any links in the ticket. The original link text remains but the link will be inactive.
• Flag malicious attachments. If the email contained malware, a separate API call can flag the specific attachment, visually warning the agent not to open it.

The result is a ticket that is triaged and largely neutralized by automation before a human agent even sees it.

This interactive shows the full automation: 

‍

That the workflow can also restore the ticket to its original state if an analyst determines that the message was legitimate and marks the case “Safe” in Material.

• A message sent to Zendesk is detected as malicious in Material
• The Zendesk ticket is protected
• An analyst marks the message as safe in Material
• The Zendesk ticket is restored 

Finally, note that this Detect -> Notify -> Orchestrate -> Remediate recipe is not a point solution for Zendesk. It's a flexible pattern you can adapt for other business-critical tools that ingest data via email. In Hubspot and Salesforce, for example, you would follow the same pattern above, searching for email engagements in Hubspot to protect. This is especially useful for users that email directly from the CRM platform instead of their email client.

The principle remains the same: use APIs to bridge the security gap and enforce policy wherever your data flows.

Build resilient, automated security

You don't have to accept the security gaps created by essential business applications. Material already delivers robust security automations across the cloud office, and by leveraging event-driven automation and the APIs you already have access to, you can build resilient security workflows that protect your colleagues and your data across many of the platforms you use every day. This approach is not only more effective at hardening your security posture but it reduces manual toil for your security team at the same time.

Want to see how Material can fit into your security automation stack? Request a demo.

‍