Building a defense system that will protect us from spoof mail attacks part 7#9

Page 1 of 17 | The questions that we will need to answer before we start the project of -

building a defense system that will protect us from Spoof mail attacks | Part 7#9

Written by Eyal Doron | o365info.com | Copyright © 2012-2016

The questions that we will need to answer before

we start the project of – building a defense

system that will protect us from Spoof mail

attacks | Part 7#9

The planning stage of the “defense system” that protects our mail infrastructure, and our users

from Spoof mail attack, need to begin with a definition of some framework.

This framework will serve as a “logical container,” that defines the specific structure and the

characters of our defense system, that will need to deal with the Spoof mail attack.

Creating The Required Framework For The Spoof Mail Attack Defense

System

The main question is – how do we build this “framework”?

My recommendation is – by using a process of “Questions and Answers,” that relates to a

different aspect of the defense system such as: what type of protection mechanism we want to

use, what is the policy that we want to enforce regarding an event of Spoof mail and so on.

http://o365info.com/questions-will-need-answer-start-project-building-defense-system-will-protect-us-spoof-mail-attacks-part-7-of-9/


https://il.linkedin.com/in/eyaldoron1

http://o365info.com/




My goal of the current article is – to offer you some of the questions that need to be asked,

regarding the required results and the structure of the defense system that we want to build for

dealing with the problem of -Spoof mail attack.

The good news and the less good news regarding the Spoof mail attack defense

solutions

The infrastructure for Spoof mail attack is rooted in the character of the SMTP protocol, which

doesn’t include a built-in mechanism that verifies the identity of the sender.

The good news is – that there are solutions, which complete the “missing part” of the SMTP

protocol by providing us the ability to verify the identity of the sender, and by doing so, prevent

a scenario of Spoof mail attack.

The less good news is – that we will need to deal with a couple of “major obstacles” in the path

for providing our organization a “good protection” from the threat of Spoof E-mail attacks.

The “major obstacle” is composed of the

1. The need to decide about the “right solution” for our specific organization needs.

2. The “technical side,” which deal with the characters of the specific sender verification solution

that we will choose, the structure of combining two or more sender verification solutions, the

management of the sender verification solutions and so on.








The Major Areas For Which We Will Have To Take Decisions.

The difference between a good and whole solution, versus half-baked or partial solution, that

needs as an answer to the threat of Spoof mail attack and Phishing mail attacks, depends on our

ability predict the obstacles that standing in front of us, and the different decisions that we will

need to make regarding the “optimal solution,” that will operate in an optimal way and will best

fit our specific organization needs and structure.








The Definition Of Spoof Mail

Let’s start with very basic but, a very important question that we need to ask ourselves.

Q1: How do we define a scenario of Spoof mail?

A1: The simple answer is – an event in which hostile element uses a fake identity, a scenario in

which hostile element says that he is entity X while, in reality, he is an entity Y.

Q2: How can we identify an event in which the sender spoofs his identity?

A2: The simple answer is – by using a sender verification mail standard, that can help us to verify

the sender identity, so we will be able to distinguish between a legitimate sender versus non-

legitimate mail sender (the hostile element that spoofs his identity).

Well, the reality is not so simple!

The famous phrase – “If it looks like a duck, swims like a duck, and quacks like a duck, then it

probably is a duck,” relate to a scenario in which a specific animal, have all the characters and

the signs of a duck, and for this reason, we can assume that it probably is a duck.








The problem is that regarding a scenario, a Spoof mail (spoof sender), in which we need to

provide a “bold statement” regarding the integrity of the E-mail message sender’s meaning,

decides if the sender is legitimate or not, the answer is not so simple!

Before our declaration that we should need to Immediately stop all the Spoof mail attacks, I

would like to ask two additional questions:

Q3: When we say that “a specific E-mail message was identified as Spoof mail,” can we be sure

100% that the E-mail message is indeed Spoof mail?

Q3: When we identify a specific E-mail message that looks like a Spoof mail, can we be sure

100% that we really want to “destroy” this E-mail message?








What is my point?

My point is, that in many scenarios, we will not be able to be sure in 100% percent that a specific

sender is a legitimate sender or instead, a hostile element that spoofs his identity.

To be able to demonstrate the existing challenges that we will need to deal with when we want

to classify a specific E-mail message is “good E-mail message” or, “bad E-mail message,” let’s

use the following example:

Our organization is implementing a specific sender verification mail standard such as – SPF.

Each E-mail that is sent to our organization, will go through an inspection process, which we will

try to verify the sender identity, and based on the result, decide if the sender identity is a

legitimate identity or considered a spoofed identity.

When the E-mail message rich our mail server, two scenarios can realize:

Scenario 1 – the sender organization didn’t publish SPF record (doesn’t support SPF).

Scenario 2 – the sender organization publishes SPF records.

Scenario 1 – the sender organization didn’t publish SPF record (doesn’t support SPF).

This scenario (scenario B in the diagram) can be described as – dead end because, we (our mail

server) have no option to verify the sender identity. The sender can be a legitimate sender, but

at the same time, can be a hostile element the spoof the identity of a legitimate sender.








Q1: So how do we know whether to “approve” or “reject” the E-mail message?

A1: The simple answer is that – we have no way or a “sign”, that can help us to make the right

decision.

Case 1 – in case that we decide to reject the E-mail message because the sender organization

doesn’t support SPF, we take the risk of the false-positive event.

The meaning is – a scenario in which we mistakenly identified a legitimate E-mail message as

Spoof mail and for this reason, blocks or reject the E-mail message.

Case 2 – in case that we decide to accept the E-mail message, although the sender organization

doesn’t support SPF, we take the risk of a false-negative event.

The meaning is – a scenario in which we accept a non-legitimate E-mail message

(spoofed E-mail) that manages to bypass our “defense wall,” and reach the mailbox of one of

our recipients.

Scenario 2 – the sender organization publishes SPF records.

In the scenario in which the sender verification process was successfully implemented (A.2), and

the sender identity appears as a legitimate identity, we are happy!

But, what about a scenario in which the “Sender verification failed” (A.1)?

Can we be sure beyond all doubts, that the specific E-mail message was sent by a “hostile

element” that tries to execute a Spoof mail attack and use spoofed identity?

The obvious answer is – yes; this is the classic scenario, in which our defense system successfully

manages to identify the “bad guy.”

And as usual, the reality is not so simple.

One of the most popular reasons for the result of “sender verification failure” is – a scenario in

which the “sender organization” did not commit fully and properly all the required configuration

settings.

For example – a scenario in which the sender organization didn’t add all the required

information about the mail server that represents his domain to the SPF record.

And again, we face the same dilemma:

Case 1 – in case that we decide to reject the E-mail message because the SPF verification test

failed, we take the risk of a false-positive event.








The meaning is – a scenario in which we mistakenly identified a legitimate E-mail message as

Spoof mail and for this reason, block the E-mail message.

Case 2 – in case that we decide to accept the E-mail message, although the SPF verification test

failed, we take the risk of a false-negative event.

The meaning is – a scenario in which we accept a non-legitimate E-mail message

(spoofed E-mail) that manages to bypass our “defense wall,” and reach the mailbox of one of

our recipients.

Choosing The “Right” Sender Verification Standard For Our Organization

The well-known public standards, that can be used for implementing the process of sender

verification are: SPF and DKIM.

The DMARC is an additional mail standard, that serves as an extinction or enhancement to SPF

and DKIM sender verification standard.

Each of this standard, uses a different method for verifying the sender identity, each of this

standard has his advantages and disadvantages, and each of these standards is implemented

and managed differently.

As part of the process of building our defense infrastructure, we will need to decide about the

specific ingredients which will be included in our defense infrastructure.

An example of a question that we will need to answer could be:

Q1: Should we adopt a specific sender verification mail standard or a combination of more than

one sender verification mail standard?








Q2: What are the weak points and strong points of each sender verification mail standard?

Q3: In case that our mail environment (such as Exchange based environment) provides another

solution for the need of “sender verification,” should we use this solution or use only public mail

standard?

Q4: In case that we decide to use a combination of two or more sender verification standards, is

there a specific standard that it’s recommended to adapt in the begging and down the road,

adapt the “additional sender verification standards”?

What Are The Factors, That Influence Our Decision Regarding The Question

Of – “What To Do With Mail Identified As Spoof Mail?“

Regarding the question of- what to do with an E-mail that was identified as Spoof mail, I would

like to relate to two different aspects:

1. The specific type \ direction of the Spoof mail attack

The Spoof mail attack, can be implemented as:

A scenario in which hostile element attacks our organization by sending Spoof mail to

our users.

A scenario in which hostile element uses our identity, to attack other organizations.

2. The specific action that we would like to “do” regarding Spoof mail








The specific action that can be executed for E-mail message that was identified depending on

three main factors:

The specific scenario of the Spoof mail attacks as mentioned above.

The specific mail infrastructure that we use – the action that we can choose from depend

on the mail infrastructure that we use.

The level of tolerance that we have regarded false-positive events and false-negative.

The level of certainty regarding a Spoofed E-mail message

Although our natural tendency is for “black-and-white and white answers” regarding the

scenario of Spoof mail attack, the reality is a bit more complicated because even when

our defense systems identify a specific email message as a “Spoof mail,” we can never be

sure in the 100 % that the E-mail message is a relay a Spoofed E-mail message.

The reason for this “uncertainty” is because there is always a reasonable chance, that in a

scenario, in which our defense system identifies a specific E-mail message as “Spoof mail”,

the reason is a technical problem or a miss configuration of the “other side” (the source

mail system that represents the sender).








The Spoof mail attack, and the specific system that is attacked

As mentioned, the Spoof mail attack can be realized in two major ways:

Case 1 – a scenario in which the hostile element attacks our organization users.

Case 2 – a scenario in which hostile element uses our organizational identity, and attacks other

organizations.

The need for differentiating these two scenarios is – because we will need to use “different set of

instructions” regarding the question – “what to do with a Spoof mail” in each of these scenarios.

For example:

Case 1 – In the scenario in which the hostile element attacks our organization users, the answer

regarding “what to do with a Spoof mail” is our decision because, the E-mail message is “trying

to enter” to our protected compound, and we as the “gatekeeper,” we can decide what to do

with the “spoofed E-mail message.”

Our decision regarding the required action depends on another question – what is our tolerance

level regarding a scenario of false-positive events.

In other words – are we willing to take the chance, that in some scenarios, a legitimate E-mail

message will mistakenly identify as Spoof mail, and for this reason, will be blocked or deleted?

In case that we are not willing to take the chance of false-positive events, we will need to decide

about “another action” instead of just destroy the “Spoofed mail.”








Case 2 – in a scenario in which hostile element uses our organizational identity, and attacks

other organizations, the main different is that in this scenario, we don’t really have control of the

“action” that will be taken by the “other side.”

We don’t know if the other side uses a protection mechanism of sender identity

verification.

In case that the other side uses a protection mechanism, in which he verifies the sender

identity, we don’t really know what is the specific sender verification standard that he

uses.

Even if the “other side” uses the same sender verification standard that we use, we cannot

“enforce” the other side to do a specific action regarding a spoofed mail that uses our

organizational identity.

It’s important to mention that some of the sender identification standards such as – SPF and

DMARC, enable us to “instruct the other side” regarding the question of – “what to do to

an E-mail message that was recognized as spoofed E-mail message.”

Assuming that we could instruct the “other side” what he should do in such a scenario (a

scenario in which hostile element uses our organizational identity to attack the specific

organization), the answer regarding – “what our instructions will be”, depend on another

question – what is our tolerance level regarding a scenario of false-positive events.








In other words – are we willing to take the chance, that in some scenarios, a legitimate E-mail

message that sent by our users, will mistakenly identify as Spoof mail, and for this reason, will be

blocked or deleted?

For example, in case that we instruct the “other side” to delete E-mail message that uses our

domain name, and was “marked” as Spoof mail, the risk is, that the specific E-mail message is a

legitimate E-mail message, and the reason that the verification check considers as “fail” is,

because some technical issue.

What Do We Want To Do With Spoof Mail?

The obvious answer to this question is – delete each E-mail message that was identified as

Spoof mail because the E-mail message is sent by a hostile element!

The real answer to this question is not so simple because, in reality, there are a couple of factors

that affect our decision.

In this section, I would like to review some of the options for “action” that are available for us, in

case that we use Exchange or Exchange Online mail server, regarding the E-mail message that

was identified as Spoof mail.

The specific action that we will choose depends on our business and organization needs.

Case 1 – a scenario in which the hostile element attacks our organization users.

In this case, we have 100% control over the “actions” that we want to execute in a scenario in

which our defense system identifies a specific E-mail message as Spoof mail.

The specific action that we use depends on the “mail security gateway” that we use.

In Exchange based environment (Exchange on-Premises or Exchange Online), the enforcement

of our desire policy regarding Spoof mail is implemented by using an Exchange rule.

Using the Exchange rule, enable us to choose the required action from a large space option.

For example, we can choose one of the following “actions”

Delete the E-mail message

Send the E-mail message to user quarantine – the term “user quarantine” defines a

restricted space, which Exchange users can access and decide if they want to accept or

reject the E-mail message.

Send the E-mail message to administrative quarantine – the term ”administrative

quarantine” defines a restricted space, which only Exchange users can access and decide if

they want to accept or reject the E-mail message.








Mark the E-mail message as spam – in this scenario, we don’t block the E-mail message,

but instead mark the E-mail message as a suspicious E-mail message.

Forward the E-mail message to approval – a process in which the “suspicious E-mail

message” sent to a designated person that needs to check the E-mail message and

decide if he approves to release the E-mail message or not.

In case that you think that in after you have decided on the required action, your “headaches”

ended, there are additional answers that we will need to provide.

For example:

The Forensics phase

Lest relates to a “non-wanted” scenario, in which a Spoof mail manages to bypass our defense

systems, and the attacker manages to execute Phishing mail attacks.

In this phase, we will need to implement a postmortem procedure, in which we will need to

collect evidence and trials of the attack.

We will need to analyze the Information that was collected, and provide a report that will need

to answer – how our defense systems were breached? Is their option to find the specific hostile

element the perform the attack? And so on.








To be able to provide these results, we will need to use forensics procedure, in which we collect

evidence from the “crime scene.”

This lead us to a very basic question – what do we want to do in the event, in which our system

identifies a specific E-mail message as Spoof mail?

Q1: Should we block the E-mail message, but in parallel, send a copy of the “spoofed E-mail” to

a designated person?

Q2: Should we allocate a dedicated mailbox that will store the copy of the “spoofed E-mails”?

Q3: Who are the “persons” that will have access to the mailbox that will store the “spoofed E-

mails”?

Another part of this equation relates to the question – should we need to notify the involved

parties about an event in which a specific E-mail message was blocked because the E-mail

message was classified as a Spoof mail attack?

Case 2 – a scenario in which hostile element uses our organization identity and

attacks other organizations.








In this scenario, the approach to the question – what to do with an E-mail message which was

identified as Spoof mail, is totally different because, in reality, we cannot enforce the “other side”

to do something but instead, only to “recommend” to do something.

For example

SPF standard, and the guideline to the other side regarding Spoof mail.

In case that we use the SPF standard, part of the information that we add to the SPF record,

include a “recommendation” to the other side, that relates to a scenario in which the SPF

verification check that is implemented by the other side failed.

We can choose between two options:

Soft fail – when choosing this option, we are “telling” to the other side, that in case that E-mail

message that uses our domain name, failed test of the SFP; we recommend to the other

side, not to block \ delete the E-mail message but instead, mark the E-mail message as a

“problematic E-mail message”.

Hard fail – when choosing this option, we are “telling” to the other side, that in case that E-mail

message that uses our domain name failed test of the SFP; we recommend to the other side, to

block \ delete the E-mail message.

DMARC standard, and the guideline to the other side regarding Spoof mail.

The DMARC standard provides a couple of “actions” which we recommend the “other side” to

use in case that E-mail message that uses our organizational identity failed test of the DMARC

(E-mail message that was identified as Spoof mail).

Monitor – a “neutral action” in which we recommend to the other side “to do nothing” in a

scenario in which E-mail message that was sent by our users, was classified as Spoof mail.

Quarantine – in this case, we recommend to the other side to “isolate” the “suspicious E-mail

message,” in a scenario in which E-mail message that was sent by our users, was classified as

Spoof mail.

Reject – in this case, we recommend to the other side to block \ delete the E-mail message, in a

scenario in which E-mail message that was sent by our users was classified as Spoof mail.








The next article in the current article series is

Using sender verification for identifying Spoof mail | SPF, DKIM, DMARC, Exchange and

Exchange Online |Part 8#9





http://o365info.com/using-sender-verification-for-identifying-spoof-mail-spf-dkim-dmarc-exchange-and-exchange-online-part-8-of-9/

http://o365info.com/using-sender-verification-for-identifying-spoof-mail-spf-dkim-dmarc-exchange-and-exchange-online-part-8-of-9/

Documents

Building a defense system that will protect us from spoof mail attacks part 7#9