Here at Tessian we’ve built the world’s most comprehensive and intelligent cloud email security platform that deploys in minutes via a single API. But what does that ‘soup to nuts’ deployment look like? And when’s best to do it? Well someone who knows in detail is our Senior Sales Engineer, Tam Huynh. We caught up with him to hear how previous Tessian customers have done it in the past.
Briefly explain the history of Integrated Cloud Email Security
Integrated Cloud Email Security evolved because of the way Secure Email Gateways handle threats. Historically, you took a look at established data sets and threat signals. You have a static analysis which looks at the hashes of the file, or simply checks the reputation of that hash.
Beyond that they may sandbox that hash to be able to do some behavioral analysis. But a lot of times with account takeovers and business email compromise today, there’s no malicious payloads. ICES evolved to leverage behavioral intelligence or machine learning to analyze the threat signals or the data sets that are missed or ignored by secure email gateways.
So Tessian examines things like the unique writing styles between one person and another, looking for anomalies such as a sudden switch to a more formal salutation or sign off, or unusual IP address location. These are just some of the thousands of threat signals and variables Tessian can analyze.
How long does it take to deploy an Integrated Cloud Email Security solution?
The application programming interfaces (APIs) that Tessian uses have given us a way to be able to deploy advanced and intricate solutions to Microsoft 365 in around 20 minutes, depending on how quickly the administrator can get the author credentials. Users enter the credentials inside of our portal, and they grant permissions to the Tessian console, let us know which groups to sync, and they’re done.
If we look back a decade on how SEG were deployed, it could take well over a month or more of multiple phase approaches, changing control windows, testing within a lab or a sandbox first, and then rolling over to production. This is much faster.
How does Tessian work with existing tech stacks as well as new ones?
So from what we’re seeing, many customers are looking to essentially replace their SEGs. So what we’ll typically do is a full feature map of their SEG, and then recommend Microsoft 365 E5 license that allows them to be able to leverage features such as sandboxing and behavioral analysis as well as several other regular features that are found in a SEG. And if some clients choose to retain their SEGs and have 365 E5, that’s fine too.
For organizations not looking to move to Microsoft 365, who might have an on premise exchange server, or are using G Suite, Tessian can leverage a gateway testing deployment, which means an install time of around an hour. And that’s from start to finish. Either way, deploying via the APIs or Gateway means no worrying about modifying MX records.
How should companies communicate ICES to the rest of the business?
So as we’ve seen you can deploy an ICES in under an hour, but that might come as a shock to other teams around the organization, so a clear communication strategy is as important as the technical deployment strategy.
You need to ensure all of the relevant teams have a heads up well ahead of time, especially the non-technical teams. For example, is this going to affect any imminent sales? Does the Customer Success team need to inform customers? Also don’t forget to let the leadership team know. Finally, use the skills of the comms team to help get the information out to the wider organization, and have them on standby in the rare case of there being an issue.
Finally, is there a right time to deploy an ICES?
Yes! Not at 5pm on the penultimate Thursday or Friday in the quarter when sales might be trying to hit target! The ideal time we’ve found with Tessian customers is after business hours on a Monday. The mail volume is down, so it wouldn’t be noticed by the end users.
