Continuing on in my 9 part series, the process of mitigating an outbound spam problem occurs in a two-fold manner. Usually they are mutually exclusive, but one can lead to the other.
This is the default position. If only one email address is responsible for sending out outbound spam, then we create a Policy rule to reject mail for that domain from that particular alias for that particular organization. For example, suppose that it is tax season and we get the following report:
Your College, Inc.
Because there is only one email address, we create a Reject rule for that email address. Everyone else’s mail would go through, but that particular mail would bounce back to the sender. The odds of an actual email address vs a spoofed one (such as firstname.lastname@example.org vs email@example.com) are about the same. They happen with about the same amount of frequency. Educational institutions are, by far, the most frequently compromised customers of legitimate email accounts. Not every email alias in the report is necessarily abusive. Another threshold, such as 10 complaints per hour, can be chosen as the delimiter between noise vs abusive.
In order to cut off mail flow for an entire organization, evidence of a problem with outbound spam would need to be widespread. To determine this, we keep track of how many different email aliases the organization is using to send out mail. For example, if we saw the following table:
… this would be indicative of an outbound spam problem. The key is the amount distinct email addresses for which we have received complaints. If an organization in general has a lot of spam complaints, and there are a lot of different email addresses that are responsible for the complaints, then the problem is probably widespread and we have no little option but to disable outbound mail for the offending organization. One rule of thumb is that if the number of different email addresses (can be the same sending domain) is ≥ 5, the organization is disabled.
As effective as it is to cut off an entire organization, it is fraught with a huge problem – customers don’t like it. Cutting off an entire domain generated a lot of complaints even though we had ample evidence that they were spamming. We even showed them examples of outbound phishing spam from their organization. At first we wanted to ignore their protests, but again, we quickly learned that this was completely unrealistic.
The customers countered with the request that they wanted 30-60 minutes lead time before being shut off. This is a reasonable request, of course, but from our point of view, it represents a security breach. The longer we allow outbound spam to flow through our outbound pool, the greater the likelihood we have of being blacklisted. From my perspective, this represents a greater risk than angering customers who are spamming.
We still don’t have the perfect compromise. The first solution, creating a policy rule, has alleviated most of the problem. The second solution, cutting off an organization, works but we make sure that as soon as we cut off the customer, we contact them via phone quickly. This introduces additional human overhead into the process but it has proven effective at reducing the number of complaints from end users.
Alerts are generated based upon pattern analysis, and the offenders are determined by looking through the database and determining which ones are the highly abusive email aliases. However, alerts can be downgraded to Warnings, or even Mitigations. If a pattern is ambiguous, such as an Island, then if Policy Reject rules exist for all known offending aliases, then a Warning can be become a Mitigation, or an Alert can be a Warning.
In other words, pattern analysis combined with examining what action has already been taken can be very effective at noise reduction.