Building a defense system that will protect us from spoof mail attacks part 7#9 | Eyal Doron | o365info.com
•Als PPTX, PDF herunterladen•
0 gefällt mir•579 views
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.
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (15)
Mehr von Eyal Doron
Mehr von Eyal Doron (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Building a defense system that will protect us from spoof mail attacks part 7#9 | Eyal Doron | o365info.com
- 1. Part 7/9 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
- 2. 2 • Creating The Required Framework For The Spoof Mail Attack Defense System • The Major Areas For Which We Will Have To Take Decisions. • The Definition Of Spoof Mail • Choosing The “Right” Sender Verification Standard For Our Organization • What Are The Factors, That Influence Our Decision Regarding The Question Of – “What To Do With Mail Identified As Spoof Mail?“ • What Do We Want To Do With Spoof Mail? AGENDA
- 3. Creating The Required Framework For The Spoof Mail Attack Defense System
- 4. Eyal Doron o365info.com The famous headache syndrome that is caused by the need to get all the necessary decisions. Spoof mail attack and Phishing mail attacks
- 5. The Major Areas For Which We Will Have To Take Decisions.
- 6. Eyal Doron o365info.com The major obstacles on the path for providing our organization a good protection from Spoof E-mail attacks
- 7. The Definition Of Spoof Mail
- 8. Eyal Doron o365info.com It is easy to identify duck!
- 9. Eyal Doron o365info.com What do I want to do to a Spoof mail ? Q1: Q2: When we identify a specific E-mail message that looks like a Spoof mail, can you be sure 100% that we really want to destroy this E-mail message? When we say that a specific E-mail message was identified as Spoof mail," can you be sure 100% that the E-mail message is indeed Spoof mail?
- 10. Eyal Doron o365info.com How do we define a scenario of Spoof mail? A B The source sender support sender verification standard The source sender doesn't support sender verification standard Sender verification failed Sender verification completed successfully A.1 A.2 We can verify the sender identity, only in a specific scenario in which our mail infrastructure is based on Exchange, and the attacker uses our organizational identity
- 11. Choosing The “Right” Sender Verification Standard For Our Organization
- 12. Eyal Doron o365info.com Sender verification standards and mechanism | Decision Making What Sender verification standards mechanism should I choose? Should I choose specific verification standards mechanism or a combination of more than one standard mechanism? What is the difficulty level for implementing each of the verification standards mechanism? In case that we decide to use a combination of two or more sender verification standards, is there a specific standard that its recommended to adapt in the begging and down the road, adapting the additional standards?
- 13. What Are The Factors, That Influence Our Decision Regarding The Question Of – “What To Do With Mail Identified As Spoof Mail?“
- 14. Eyal Doron o365info.com What is our level of certainty regarding a Spoofed E-mail message? Spoofed E-mail message 20%? 60%? 80%? 100%?
- 15. Eyal Doron o365info.com Two major scenarios of Spoof mail attack Hostile element uses Spoof mail to attack our organization users. A B Hostile element uses our organizational identity to attack other organization's recipients.
- 16. Eyal Doron o365info.com Why should we do with Spoof mail?
- 17. What Do We Want To Do With Spoof Mail?
- 18. Eyal Doron o365info.com How should we react to a scenario, in which our defense mechanism identifies a specific E-mail message as Spoof mail? Send the E-mail message to user quarantine? Send the E-mail message to administrative quarantine? Delete the E-mail message? Send the E-mail message to quarantine? Forward the Spoofed E-mail message to additional examination? Forward the E-mail message to the original recipient but, mark the E-mail message as spam?
- 19. Eyal Doron o365info.com How should we react to a scenario, in which our defense mechanism identifies a specific E-mail message as Spoof mail? The need for analyzing the information The need for Forensic Save a copy of the Spoofed E-mail message? Allocate a dedicated storage for storing a copy of the spoofed E-mail messages? The need for information the sender destination recipient Notify the sender that his E-mail message was identified as Spoof mail? Notify the destination recipient that an E-mail message that was sent to him was identified as Spoof mail?
- 20. Eyal Doron o365info.com DMARC SPF Monitor (do nothing) Quarantine (mark the email as spam) Reject (Block delete the email) Soft fail - accept but mark Hard fail -reject What is the required action that we advise the other side to do, when they identify Spoof mail that uses our organizational identity?
Hinweis der Redaktion
- 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.
- 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. 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 The need to decide about the “right solution” for our specific organization needs. 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 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.
- 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.
- 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”?
- 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.
- 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.