A Revolutionary Approach to API-Based Inline Email Security

2A REVOLUTIONARY APPROACH TO API-BASED INLINE EMAIL SECURITY

Highlights In 2016, Avanan introduced inline email security based fully on APIs. This

revolutionary approach meant that Avanan could connect to cloud email

services via API, and provide security protection before the mailbox.

Since then, a number of other API-based email security companies have hit the

market. None of these companies, however, are inline.

We use the word inline a lot. However, it’s not a naturally intuitive term. And its

true meaning—and value—can sometimes be lost.

In this whitepaper, we’re going back to basics and will answer the following:

• What does inline security mean?

• Why is it important?

• Why is it an improvement upon Secure Email Gateways?

• Why is it different from other API solutions?

When you hear the word inline, we want you to be empowered to know what

that means and why it matters. This whitepaper aims to do just that.

3A REVOLUTIONARY APPROACH TO API-BASED INLINE EMAIL SECURITY

What Is Inline Security? For years, the standard approach for securing email was that of a Secure Email Gateway. These became popular back when email was on-prem. Simply bolt the gateway to the server. All mail flows through the gateway. Good mail goes in, bad mail goes out. Simple and effective.

Then email moved to the cloud—but gateways weren’t and aren’t a natural fit. Why? Consider this analogy. You have a phone charger cord that is fraying. You know it’s fraying and yet, as everybody else would, you try to get as much juice out of it as possible. However, you know that it only works when it’s at a certain angle, or when you’re physically holding in the charger. Sometimes you have to bend it, or hold it under a cup for it to stay in place. The second you move the cord or yourself, it stops charging.

That’s the effect of gateways today. In the right position at the right time, it’ll stop malicious emails. But to rely on it for every single malicious email is like a fraying cord about to snap.

Nowadays, the standard way of securing email is via API. Nearly every company–including the gateways–has products that connect via API.

Before we dive deeper into the mechanics of how it works, let’s start by answering this: What the heck is an API?

API—or Application Programming Interface—is the software that allows two separate applications to communicate with one another. Think of it like those string telephones we used to make as kids. Each cup represents an application. In this case, the string is the API, the connector that allows communication to flow back and forth.

4A REVOLUTIONARY APPROACH TO API-BASED INLINE EMAIL SECURITY

So by connecting an email security program to the email provider using API, you’re setting up a line of communication between the two. Utilizing the API, the email security solution can deploy like an app within Microsoft or Google. It’s like any other app you might have installed in your email. Simple and easy.

There are numerous benefits to deploying this way. For one, it takes just minutes to install. It’s a cloud- based way of protecting a cloud-based solution. It can fairly easily build out communication patterns, see the internal workings of a company to establish baselines and notice when something is amiss. The security is invisible to hackers, as you don’t have to change MX records.

There are two ways, however, of doing this, and that is the crux of this whitepaper.

Most companies do what we call Detect and Remediate. All emails first come to the user. Then, after it has been delivered to the user, the service will look at the email and scan it, determining if it’s malicious or not. If it’s not, it stays. If it’s malicious, it’s moved to a hidden folder.

This approach has benefits and downfalls. The main benefit? It will eventually remove a malicious email from the inbox. The main downfall? It doesn’t do so automatically or instantaneously, and the user can interact with it before it gets removed. It’s a race between who acts quicker: the service or the user.

Think of it this way. Imagine you’re about to make a three-egg omelet. You’re looking at the eggs as you go to crack them. The first one—into the bowl and looks and smells normal. Second one—into the bowl and looks and smells normal. Third one—into the bowl and smells rancid. You can remove the egg from the bowl as soon as you notice. But it’s already been whisked in with the other eggs. The bacteria has spread–the damage has already been done.

There’s another way to do email security via API-the way that we operate. It’s called inline API security and it’s our patent. It works like this. When an email is sent, we take a look at it before it reaches the inbox.

Let’s go back to the egg analogy. What if instead of cracking it into the bowl and hoping it’s still good, you could know before that happens that you’re safe to eat it? What if there was a scanner that could look at the egg, look inside at the egg, look at all the properties of the egg and tell you if there’s something amiss? You would know if an egg was bad and could toss it. Or you could know it’s good and crack it with confidence.

5A REVOLUTIONARY APPROACH TO API-BASED INLINE EMAIL SECURITY

That’s how our solution works. We inspect the email before it reaches the inbox instead of after. If it’s good, it goes to the inbox. If it’s bad, it doesn’t. Simple as that. There’s no chance of interacting with a bad email. If you get an email, you know it’s good.

Okay, you’re wondering—why wouldn’t everybody do this?

It’s simple—they can’t. We have a patent.

Our email security connects via API just like every other company. But we’re the only one that connects automatically via API before the inbox. The rest can’t interfere with our patent, and so they must scan the email after it reaches the inbox.

It sounds like a simple distinction and in reality, it is. But let’s break it down further.

Inline means that we are “in line” with the mail flow. It works like this:

• Email is sent.

• Email is read by default security services, like Microsoft or Google. If they block it, it’s blocked.

• If they don’t, it goes to us. We take a look. If we deem it good, it goes on to the inbox. If not, we block it.

• This makes us “in the line” of the mail flow. We do this analysis in seconds, so you don’t even really notice we’re there.

Others operate after the fact. It works like this:

• Email is sent

• Email is read by default security services, like Microsoft or Google. If they block it, it’s blocked

• If not, it goes straight to email, good or bad. The solution does an API call to the inbox to read it. While analyzing, the user is free to open it, respond and interact with it. After they’ve done their analysis, which takes on average three minutes and three seconds, but can take longer, a bad email gets removed.

6A REVOLUTIONARY APPROACH TO API-BASED INLINE EMAIL SECURITY

At the risk of over-analogizing, take the example of an art museum. Most museums have prized art pieces protected to the max. Go to the Louvre in Paris, and the Mona Lisa is encased in glass and behind a rope.

We serve as that encased glass. The other APIs only try to stop the art thief after it’s stolen. You wouldn’t want to do that to Mona Lisa. You wouldn’t want to do that to your company.

Summary To be inline or not to be, that is the question.

From our perspective, being inline is critical because it virtually eliminates the risk of an end-user clicking on something they shouldn’t. Otherwise, the threats enter your environment and you are racing to remove them before something bad happens.

It comes down to this: Would you rather prevent or respond?

© 2023 Check Point Software Technologies Ltd. All rights reserved.

Worldwide Headquarters 5 Shlomo Kaplan Street, Tel Aviv 6789159, Israel | Tel: +972-3-753-4599

U.S. Headquarters 959 Skyway Road, Suite 300, San Carlos, CA 94070 | Tel: 1-800-429-4391

www.checkpoint.com © 2023 Check Point Software Technologies Ltd. All rights reserved.