One of the most common requests I get regarding anti-spam protection (from customers) is surrounding phishing. What do you guys do to protect my organization from phishing?
I never go into this too deeply with customers but the issue is deeper than they realize. When people are asking about phishing, they usually are worried about two things:
- Financial phishing – users do not want to surrender their credentials to phishers who will clean out their bank accounts. The requests to block phishing is really a concern about protecting their financial resources.
- Protecting their company’s “integrity” – this is the one that has come up more over the past year. Because I deal mostly with enterprise mail protection (unlike Hotmail that protects consumers), when people want to protect against phishing, it’s a reaction to the news. It goes like this: some user got a spam message with a phishing link or a piece of malware attached. They opened it, got infected and surrendered control of their machine to the hacker, and lost corporate intelligence. Examples include Google, RSA and Lockheed Martin. Our customers don’t want to be the next Sony, therefore, how does our filtering stop these malicious mails from coming in?
It’s not a simple matter of a good mail filtering solution. Protection against compromised machines requires more than a good spam filter. In the case of RSA, the phishing message was deposited into the user’s spam folder and they went in, fished it out, opened it and got infected. This demonstrates that even if your filter is good enough to catch phishing, your user base can defeat your technology.
A company has to do multiple things to stay protected:
- A good filtering solution is important. I sometimes get asked why a certain phishing message “got through” the filter. It didn’t get through, it was marked as spam and deposited into the junk mail folder. The user wants to know why it got to the junk mail folder and wasn’t rejected upstream such as in an IP filter and not even scanned in the first place.
Spam filters take a while to generate reputation on a sending IP address before they can be confident an IP is malicious. And even after generating a reputation, it’s no guarantee that a message can be rejected using an IP block. Many more accounts are being compromised and used to spam from a legitimate service such as Yahoo, Hotmail or Gmail. A spam filter cannot reject mail from these IP addresses because it would mean too many false positives. Thus, the filter must accept the mail, scan it and deposit it in the user’s junk mail folder.
Furthermore, a message should not be rejected based upon content, only upon the sender. If you can verify that the sending IP is bad, or the sending mail host, or something about the sender, the mail is safe to reject However, rejecting based upon content generates false positives. If I send you a message with spammy content, I may have a legitimate reason to do that. I could be a lawyer talking to my client about a spammy website infringing on my patent (e.g., a Rustock spammer sending Viagra spam). I could be a security professional sending mail about some spammy URLs. In either case, if the content filter marks the message as spam, the recipient can always go and retrieve the message out of the junk mail folder. But if the message is rejected in SMTP, then sender and recipient have to way to exchange legitimate mail even though it has suspect content. The content is bad, but the senders are not. Ergo, do not reject mail based upon content.
The implication of this is that some spam will end up in a user’s junk mail folder. That’s reality. If you have users like the one at RSA who went and retrieved the message, they will defeat that defense mechanism.
- The organization must put reasonable protections in place. One question I get is how many virus filters do you have? (Aside: I also get asked how to disable them) Another is how frequently do they update? The rationale behind this is that people know spammers send spam with malware attachments; a good filter should block this malware, presumably zero-day malware.
It is important to block zero-day malware, but at the same time, an organization must understand that they play in role on their side. First of all, the bulk of malware infections are not zero-day malware, but known malware that has existing signatures for it by anti-virus companies. If you read Microsoft’s Security and Intelligence reports, particularly version 9 and earlier, they talk about how much malware they have cleaned using the Malicious Software Removal Tool (MSRT). It’s great that the MSRT removes the malware, but it’s also latent and updates once per month. It doesn’t contain anything that Microsoft’s Security Essentials doesn’t also have. This means that users are infected for up to a month when they could have had a free anti-virus solution that does the same thing in real time.
The fact is that most people are infected with malware that already has A/V signatures out there, but they haven’t taken the precautions to avoid or remove it earlier. Yes, zero-days are a problem, but a bigger problem are the one-days.
Organizations need to be responsible and ensure that their users are running up-to-date antimalware software. Email is one way to get infected, but so is downloading screen savers or music, or viewing infected web pages, or installing infected USB drives. We can block malicious attachments but it doesn’t mean your users are protected. There are plenty of other ways to compromise a computer.
- Hand-in-hand with the above is the reality that older software is more prone to exploits. Again, from the Microsoft SIR (any version), the older the version of Windows, the more malware infections there are. Windows isn’t perfect, but over time the security model has changed, beginning with Vista. The internal procedures for doing software design have improved greatly since 2002 and every new, customer-facing software has to go through Threat Modeling. This doesn’t make it bullet proof but it does make it less prone to vulnerabilities than the previous version of the software.
Yet users, and even organizations, are not running the most up-to-date software on their corporate networks. They still run Windows XP, or Internet Explorer 6, or Office 2000, or Adobe 7, or you-name-it and they-run-it. I get why they run older software – they have applications that they wrote that run on those platforms and they are worried that if they upgrade the OS or web browser, stuff will break. I understand that rationale.
But the reality is that if you make that trade off, your organization is more exposed to malware than if you were running the latest version. Eventually, Microsoft, Apple, Mozilla, Adobe, etc, will stop issuing patches for the old software. Then you’ll really be out of luck if hackers continue to find more exploits. Thus, you can ask how good the spam filtering solution is, or how good its malware filtering is, but that’s not the only way you be exploited. Users can circumvent your security in any number of ways and running old versions of software will make the consequences that much worse.
It’d be like if you hired a security guard to patrol the front of your house, walking back and forth across the driveway to ensure that no jerks (like Youtube commenters) got onto the premises. But, if you leave the back door unlocked and the windows open, you’re defeating the purpose of having the security guard. Sure, he’ll keep the jerks from coming down the driveway, but what if a burglar leaps over the neighbor’s fence? Your security guard isn’t patrolling the fences. That’s not what he does.
That’s what I want to tell users when they ask me about our filtering strategy. We work hard to keep our filters up-to-date, but you are doing your part too, right? Email is not the only entry point into and out of the organization. Modern security requires multiple lines of defenses, and securing the email story is one of them. Granted, it’s an important one because tons of traffic enters and exits a user’s company… but don’t forget about the rest of the story.
Because that story is an important one, too.