Selecting Enterprise Email Security: Detection Matters - Security Boulevard

SBN Selecting Enterprise Email Security: Detection Matters

Posted under: Research and Analysis

As we covered in the introduction to the Selecting Enterprise Email Security series, even after over a decade of trying to address the issue, email-borne attacks are still a scourge on pretty much every enterprise. That doesn’t mean that the industry hasn’t made progress, it’s just that between new attacker tactics and the eternal fallibility of humans clicking on things, we’re arguably in the same place we’ve been.

As you are considering upgrading the technologies to address these email threats, let’s focus on detection since that’s the cornerstone of any email security strategy. To improve detection, we’ll need to address the issues on multiple fronts. First, we’ll look at threat research, which is critical to identify attacker tactics and maintain information sources of known malicious activity. Then you need to ensure the detection will scale to your needs, as well as implement some attack specific detections in the case of phishing and business email compromise (BEC). Finally, we’ll evaluate the use of internal email analysis as another mechanism to identify malicious activity within the environment.

Threat Research: The Foundation of Detection

The general tactics used to detect email attacks, like behavioral analysis and file-based antivirus are commoditized. There is very little value in the tactics itself. But leveraging many detection techniques together can yield effective results. It’s kind of like mixing a cocktail. You can have five different liquors, but it’s in knowing the proportions of each liquor to use that yields tasty cocktails. Thus, modern detection is about knowing what tactics/techniques to use and more importantly being able to adapt the composition and mixture of the tactics since attacks are always changing.

Thus, threat research is contingent on a mature and robust analytics capability. It’s about blending sources like multiple AV engines, malicious URL databases, and sender reputation databases to determine the optimal mix and weighting of each tactic. It’s also necessary to have a sufficiently large corpus of both good and bad email to identify common components and patterns of malicious email, which is then filtered back into the detection cocktail.

Thus, threat research requires an analytics infrastructure and the data scientists to run it to proper effect. During the courting process with any potential vendors, it’s helpful to understand their threat research capability, in terms of resourcing/investment, skills, and output. Sure, having a research team find a new and innovative attack and getting tons of press is laudable, but it doesn’t help you detect malicious email. We recommend you focus on meat and potatoes activity like how often are the detections changed and how long does it take a new finding to be rolled out to protect all customers.

Applied Threat Research

Once you are comfortable with a potential provider’s threat research foundation, the next area to evaluate is how is that information put to use within the gateway or service. For instance, how do behavioral detections work within the gateway/service?

You’ll want to know how the offering protects URLs. You learned about their URL database above, but what happens when the URL is not in the database? Do they render it in a sandbox? Do they use techniques like URL rewriting and stripping malicious domains from the email to protect users from these attacks?

Then you focus on finding malicious attachments. How are these inbound files analyzed? Does the provider have a sandbox service to do the analysis? What is the latency involved in analyzing a file and in the meantime is the message held or sent to the user while the sandbox runs in the background? Also, will the service convert files to a safe format and then deliver, while maintaining the availability of the original?

What about impersonation attacks (commonly called Business Email Compromise (BEC)), where the attackers try to convince employees that the message is legitimate and to take unauthorized action (like wiring a ton of money to a random bank account)? Yes, this is another form of social engineering, but these attacks can be detected by looking for header anomalies and watching for sender spoofing approaches (like changing the display name or using look-alike domains). Even something simple like marking messages that come from outside your domain can trigger the employee to scrutinize the message a bit more carefully before clicking on a link or taking action.

And let’s not forget about phishing. Does the provider have a means of tracking phishing campaigns across their customer base? Can they identify phishing sites and help to have them taken down? Phishing seems like old news, but like many email attacks seems to have a half-life measured in decades.

Finally, how easy is it to categorize users and build appropriate policies for the group. For example, some groups have legitimate business requirements to get files from external sources (like HR for resumes or finance for invoices, etc.). But some employee groups should get many email attachments at all or click on a link within an email to a questionable site. Thus, managing these policies on an enterprise scale makes a big difference in the effectiveness of the detection. We’ll discuss this a bit more in the next post.

Internal Analysis to Detect Proliferation

Historically email security happened upon receipt of the email. Once it was deemed legitimate, the message was on it’s way to the user, and if the gateway missed the attack hopefully, you detected the attack using another control. Over the past few years, more enterprises have started evaluating their internal email traffic to detect missed attacks (the dreaded false negative). For example, you can identify the lateral movement of an attack campaign by tracking the same email being sent to multiple employees.

The ability to monitor and even remove malicious emails from a user’s mailbox can offer a measure of retrospective protection, allowing for the fact that you will miss some attacks. But once identifying the message as bad, you can find out which users received the email, how many opened it, if they clicked on the link and remove it from their inbox before more damage ensues.

Another advantage of integrating security with the internal email server is outbound protection. You can check emails for sensitive data and malicious attachments before the message is sent, providing an earlier means of stopping an attack, comparing favorably to having the MTA (or egress filter) inspect the message on the way out.

Optimally you want to detect and block every malicious email, but in the real world having the ability to take action after the fact provides more flexibility in protecting your users.

Sharing Threat Intel

Finally, one last critical capability to evaluate is how the threat intel from your email security vendor can make your other security controls more effective. To the degree that sender reputation or attack patterns are enumerated in machine data, other security devices/services can consume the intel directly. For instance, the email threat intel could be loaded into your SIEM to look for network traffic to known spam or phishing domains. Likewise, those addresses could be used to block outbound traffic within your egress filters.

As we’ve discussed, we’ve made progress in terms of detecting recent email attacks. But evaluating your potential vendors against modern techniques increases the likelihood that you’ll be able to protect your organization’s email more effectively. In the next post, we’ll dig into how to scale email security to your enterprise, including considering a service versus on-prem gateway (or both), direct integration with other enterprise security controls, and complimentary services that when used together can improve your entire security posture.

– Mike Rothman
(0) Comments
Subscribe to our daily email digest

*** This is a Security Bloggers Network syndicated blog from Securosis Blog authored by [email protected] (Securosis). Read the original post at: