The Case for Email Security Posture Management (ESPM)

Setting the stage

It’s 2024 and we’re still talking about email as an unsolved problem. If you think about email as purely a communication channel, you might ask yourself why this is the case. Sure, attacks are more sophisticated and coming at a higher volume than ever before, but can’t we just improve our detection logic and incident response procedures, and call it a day? When you think about email as a cloud system, however, it’s understandable why this is a growing problem, not just an unsolved one.

The reasoning comes down to the total attack surface of email. We’re not simply talking about which messages are coming in and going out, we’re talking about the inherent risk of email messages, accounts, and data. As a dynamic cloud system, the attack surface of email is multi-dimensional:

Email as an attack method (the “way in”): the many flavors of phishing, BEC, malware, and ransomware attacks delivered via email with the goal of stealing credentials or committing fraud.

Email as an attack vector (the “once in”): an email account is the de facto identity layer for a wide range of downstream systems and applications. Compromising an email account enables attackers to move laterally or live off the land for long durations of time.

Email as an attack target (the “gets out”): aside from systems and application access, every employee’s mailbox itself contains a treasure trove of sensitive information that an attacker could exfiltrate with impactful consequences – IP theft, financial loss, or reputational damage.

In many ways, the market is still playing catch up to the total attack surface. The traditional perimeter-based approach to email security – Secure Email Gateway (SEG) inspecting traffic coming in and Data Loss Prevention (DLP) inspecting traffic going out – are insufficient at addressing all angles of email-based attacks, as they have limited to no visibility within the system itself. Newer attack flavors are purposefully designed to evade traditional blockers via highly personalized social engineering and smart obfuscation techniques.

Emerging API-based solutions – referred to by Gartner as Integrated Cloud Email Security (ICES) – are capable of addressing more of the risk within by interfacing directly with the underlying APIs provided by Google Workspace and Microsoft 365. This allows for more expanded detections within the system, such as suspicious user behaviors, application access, and sensitive data exposure. Only with API access can you gain visibility into all email attack angles.

With a growing attack surface, however, more detections may not necessarily equate to less risk. Detections that hit generate alerts, and the more alerts coming into the SOC, the harder it is to keep up. APIs provide more surrounding context to help prioritize, but for the sake of this discussion, a better question is whether we can make email as a system less susceptible to attacks in the first place.

Before we answer that question for email, let’s investigate XSPM as a category of categories.

‍

What justifies an XSPM category?

A number of XSPM categories have sprung up in recent years – CSPM, DSPM, SSPM, KSPM, AISPM just to name a few. They emerge largely in part due to the underlying complexity and depth of dynamic systems. From a Security & Risk Management perspective, if the attack surface is greater than the team’s ability to apply protections, you just might need an XSPM solution. I often use this image to illustrate the risk gap associated with email – I’d say it’s general purpose for this topic.

To get more specific, my mental model for an XSPM solution (where X = a system) is as follows:

System is an attack target: regardless of motivation, the system itself must be proven to be a high-value target by attackers, thereby requiring layers of defenses.

Entities carry outsized risk: within the system, assets such as workloads, accounts, and data carry a significant risk profile, thereby requiring visibility and control.

Configurations change risk: from an operational perspective, turning a knob to make a change potentially impacts the risk profile, thereby requiring frequent assessments.

Behaviors indicate threats: select activities of human and non-human users of the system may be signals of an impending threat, malicious or accidental, thereby requiring continuous monitoring.

Events require investigation: through continuous monitoring, the alerts generated by and around the system must be triaged by the SOC, thereby requiring incident response procedures.

Note that I purposefully left out compliance and governance as key attributes here as that may muddy the waters, but there are implications of such.

‍

The case for Email Security Posture Management (ESPM)

With the mental model provided, the short answer to whether email as a system warrants its own XSPM solution is a resounding yes.

System: The email attack surface encompasses the vast number of user accounts, downstream systems and applications, and all accessible sensitive information, making it a prime target for phishing, BEC, malware, and other email-based attacks.

Entities: Email accounts often serve as gateways to other critical systems and sensitive data. Compromised accounts can result in data exposure, financial loss, and reputational damage, underscoring the need for robust security measures.

Configurations: Email settings, such as account-level multi-factor authentication (MFA), group membership, and auto-forwarding rules, can increase the organization’s vulnerability to phishing attacks if not properly managed.

Behaviors: Unusual login patterns, external forwarding, spikes in sensitive data retrieval, or emails sent to risky domains may indicate compromised accounts or insider threats, necessitating continuous monitoring and analysis.

Events: Phishing attacks are a constant threat, requiring timely detection, accurate alerting, and efficient investigation to mitigate potential damage and protect the organization.

A question may arise whether email occupies its own space. An argument we frequently make at Material is that your productivity suite that serves email – whether Microsoft 365 or Google Workspace – isn’t just another application, it’s critical infrastructure to the business. These systems are home base for all of your people, content, and communications over all time. They carry an outsized risk profile on par with, or even gasp greater than your cloud infrastructure. As such, we would argue that email occupies its own space to justify a dedicated XSPM solution.

‍

What should ESPM entail?

Returning to the earlier question whether we can make email less susceptible to attacks in the first place, knowing what belongs in an ESPM solution starts by inspecting the job to be done today. As illustrated by market forces, the primary task attributed to email security is threat detection and response (XDR) – the tools and procedures to handle inbound email-based attacks (note: EDR is taken, acronym collision is inevitable). However, with attacks coming from all angles, we need to expand our detection coverage to include elements within the system to address “once-in” and “gets-out” scenarios.

Specific to email, broad detection coverage from an XDR solution should include:

Inbound email threats: malicious links and attachments, suggestive messaging, person and brand impersonation, etc.

Account compromise/insider risk signals: email forwarding rules, password resets, new app signups, etc.

Data exposure: email forwarding, sensitive data retrieval, public file sharing, etc.

With an understanding of the types of threats we need to detect across your email system, we can start to identify particular risk areas that an ESPM solution connected via API could uncover and provide mitigation for, with the aim of answering the original question of this thought experiment – can we make email less susceptible to attacks?

A few examples of email risk that an ESPM solution should identify include are:

Email configuration: IMAP/POP settings, moderation settings, autoforwarding rules, etc. that impact account-level security.

MFA status: MFA is still the most important measure you can take to prevent unauthorized access to an email account.

Group membership: externally accessible mailing lists are easy to guess and are subject to less anti-spam and anti-spoofing filtering.

Mailbox contents: no matter the role or time at company, every employee mailbox contains sensitive information.

On the surface, one might perceive identifying risk via ESPM as a “nice to have fire prevention” tool and XDR as the “need to have fire fighting” tool. I would argue that they’re intrinsically complementary, however, and act as a mutual force multiplier. By addressing non-adversarial risks as preventative measures for potential adversarial threats, ESPM lays the groundwork for a more resilient email system as a whole.

Additionally, a well-designed ESPM solution not only identifies risks but also implements protections in critical areas. For instance, if you’re going to monitor user behaviors for account takeover signals, it makes sense to also restrict what compromised accounts can access and do.

A few examples of email protections that an ESPM solution should include are:

Emails containing sensitive data: apply an added layer of authentication to retrieve messages or attachments that contain sensitive information (as defined by data classification).

Account-related emails: apply an added layer of authentication to password reset emails.

Confirmation emails: apply an added layer of authentication or outright block emails sent to confirm signups.

Email protections such as these examples are intended to limit the blast radius of a compromised account, and limit the capabilities of malicious or accidental insiders. If an email account must pass an additional challenge to sign up for a new service, or to reset a password on an application, or to retrieve a message containing confidential information, then we have effectively answered a follow-on question to this thought experiment – can we make email attacks less successful?

‍

ESPM + XDR = email resilience

Putting the pieces together, we can visualize how ESPM and XDR work together for a more complete email security solution that addresses the total attack surface in a continuous manner.

Note: I am liberally borrowing the following image from an excellent presentation at the Gartner Security & Risk Management Summit by Neil MacDonald.

‍

An Email Security maturity curve

Email resilience is illustrated by a shrinking attack surface, but it’s something to take in stride. In the context of this thought experiment, I would generally recommend getting XDR tools and procedures fully implemented across the security organization before tackling something like ESPM as it’s critical to address threats first and foremost, then identify risk areas that heighten the security posture of the system as a whole.

At Material, we provide a complete solution that combines the aspects of XDR and ESPM as illustrated in this post. Our customers of all shapes and sizes deploy Material for a variety of use cases – the following maturity curve is a generalization of how we typically see adoption evolve. Where do you think you are today, and where would you like to get to? We can help!

‍

Looking ahead

Let’s say you generally agree that we’ve made a compelling case for ESPM. Let’s also say that you generally agree that your productivity suite is critical infrastructure to the business. Another case can be made that the productivity suite is the Cloud Office for every modern organization.

So rather than limit ourselves to ESPM, what if we instead looked at the larger space as Cloud Office Security Posture Management, or COSPM (coz-pee-emm)? This is a larger topic, but the seed has been planted. I’m still not a Gartner analyst, but I do feel like I could play one on TV.

‍

Want to see how Material covers more of what is typically considered email security? Schedule a demo today.