In the previous video, we identified
that the ESA, the email security appliance,
is a lot like a bouncer at the edge of our network,
so that the outside email world all has to interface with it,
and then it can interface with our internal server,
and it can do all the heavy lifting
and protection regarding email.
So I'd like to share with you in this video
a pretty high level overview of some of the riggers
and some of the tests and some of the filtering
that this guy is going to do, the email security appliance,
to help keep us safe.
So let's use this topology once again,
and let's put a server out here on the internet, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and let's put a server out here on the internet,
we'll call it server 2, and it has
email that it wants to send over to our domain,
and we'll imagine that we are ogit.com.
So this server does an MX record lookup,
looking for email servers, MX records, at ogti.com.
it responds back with esa.ogti.com,
and then the server who wants to send us email
then does an A record lookup based on that name,
and then, boom, starts sending the traffic over to us.
And that's going to be SMTP.
So from the internet, it looks like MTA, mail transfer agent, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So from the internet, it looks like MTA, mail transfer agent,
talking to mail transfer agent, or email server to email
server.
Now when that connection is received
by our ESA, our email security appliance,
it's going to be receiving that logically on a public listener.
Think of a public listener as the logical component
that receives all the inbound requests from the outside world
where we don't trust everybody.
And at the same time, if we deployed our ESA
with two interfaces, we could have one interface associated
with a public listener for the outside world
and the other interface set up as a private listener. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and the other interface set up as a private listener.
And the beauty is there the private listener
can interface with our private email server,
and the public listener can interface
with all the other MTAs out there on the internet.
So server 2 builds an SMTP connection,
it runs over TCP over to the ESA with the intent
to send some email.
Now the ESA doesn't just say, great, send me the email.
I'll take it.
What it's going to do, it's going
to go ahead and check the reputation of the sender.
In this case, our sender is server 2,
and it's also going to check the host access
table, which is also sometimes referred to as HAT. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
table, which is also sometimes referred to as HAT.
And if the reputation of the sender is bad enough
or if the sender has been blocked completely,
we're not going to process that email
and let it get to the real email server.
We can drop it right there.
And so there's a lot of things that affect
the reputation of a server.
Is that server known to send lots of spam?
Or is it known to send lots of malicious code
as part of phishing attacks?
And because TALOS is looking at millions
of emails every single hour, it can
identify where those malicious players are,
and then educate our ESA so that when traffic comes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then educate our ESA so that when traffic comes
in we may have a bad reputation or a good reputation,
and based on that, the email security
appliance can drop like most of the traffic right there.
And say, you know what, I'm not going
to forward those emails because the sender has
a bad reputation.
So I will show you-- as we continue through these videos,
I will show you how the reputation of the sender
and the host access table or HAT are kind of linked or tied
together, and how the ESA makes those decisions.
But the key here is that it's going
to drop like most of the traffic or most of the email messages WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to drop like most of the traffic or most of the email messages
at this point that are from bad sites or malicious
or spam so they never get to your email server.
So we can think of these as like the first line of defense
against malicious or just bogus emails that we don't want.
But there is actually one additional initial check
and that is called the RAT, which stands
for Recipient Access Table.
So if ogit.com is in our Recipient Access
Table, that exact domain, we'll be willing to receive emails.
Assuming the reputation is good enough by the sender,
we'll be willing to receive it because the RAT says, OK, we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we'll be willing to receive it because the RAT says, OK, we're
accepting emails to ogit.com.
But if the email is destined for some other domain,
right there at the email security alliance,
if that other domain is not in the RAT, the Recipient Access
Table, it can just drop it right there.
So that's going to cut just like a boatload of email
messages right out of the gate from ever making it
into our network.
But besides that, if we have email messages that
pass those tests, it's coming from somebody with a reputation
that's good enough for us to allow it,
it's coming to something in our domain
or that centers on the host access table as being specified WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or that centers on the host access table as being specified
as allowed, go ahead and let this sender send this message
in to us, there's yet a whole another list of checks
that we can do on those email messages
before they are forwarded onto our real email server.
Let me give you a sneak peek at what some of those are.
So this is an example of the Virtual Appliance from Cisco.
You can get a hardware appliance or a virtual appliance,
either way would be great on-prem
as long as it can handle the expected amount of traffic,
and this is an example of the incoming mail policies.
So these checks are about to show
you are done after the host address table or the reputation WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you are done after the host address table or the reputation
has been checked and the recipient has been checked
and it makes it through that.
These are the additional checks that
can be done based on the license features
that you're using on the email appliance,
and they include antispam, antivirus, advanced malware
protection, graymail, content filters, outbreak filters,
advanced phishing protection.
And then based on all the policies
we have set up, if the email passes all those,
then it can be delivered on the internal network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
then it can be delivered on the internal network
to the real email server, at which point
Bob could go ahead and use POP3 or IMAP,
check his email server, or get a notification that
has new email, and pull down his messages from the email server
and see it.
You see, the intention is we want
to block as much bogus, malicious, malware-laden email
messages as we can before our users ever get them.
Now, at the user machine, we still
want to have software involved, so if an email message did
get through, and it had a link, and they clicked on it,
we want to have some software at that client WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we want to have some software at that client
that when they click on a link, it could warn them, oh,
is a tough website or a dangerous website.
So that's important to do in combination with the filtering
of email in combination with probably the most important
aspect of all this, which is end user education that
should train them never, never click on a link for anything
that you got in your email even with all these protections
in place.
So these are multiple layers of defense.
So in the next video, I'd like to share
with you about incoming mail.
There's a lot of work that the ESA can do,
but I want to also share with you how you can manually set up WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but I want to also share with you how you can manually set up
block lists regarding domains or IP addresses of email servers
that you never want to receive email messages from.
So even though a lot of it can be automated,
I also want to show you how to set up a block list manually
if you need to do it, and we'll do that in the next video.
So I'll see you there in just a moment.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.