Immutable Security

Encrypted is good. Clear-text is bad. AV is good. Not having AV is bad. Those are the messages we have been receiving and teaching for some time now. And while they do contain sound security advice, it is important to also consider the context of the situation at hand.

A colleague of mine recently requested a firewall exception for FTP traffic. The security policy did not normally allow clear-text traffic, which is generally a good policy to have, but in this case it was justified.

He was trying to get DAT updates for AV on a Linux box (we’ll get to that in a minute), and anonymous FTP was the best way to do it.

Consider this:

1. There was already an FTP service running, so adding an additional service would mean one more to patch, secure, etc.
2. The access allowed was only anonymous, making the issue of clear-text password transition moot.
3. Only read access was allowed, thereby mitigating file integrity issues.
4. Since these were ultimately publicly available DAT files, file confidentiality was not an issue.

After careful examination, it was clear that clear-text FTP was the best option.

Antivirus on Linux is another area where the cure may be worse than the disease. Although you’re not likely to win over your auditor friends, sometimes it can be demonstrated that running AV on Linux is a bigger threat than not running it.

Antivirus software is software, just like every other kind of software. It is prone to security failures and attacks. Is an AV agent with a history of vulnerabilities more of a liability on a system which is not likely to be a target of viruses? Perhaps, perhaps not. Again, it depends a lot on context.

Context helps us to make good security decisions–decisions that are based on risk, reason and facts, not necessarily best-practices or requirements. Keep an open mind.

A conversation with a McAfee engineer last week reminded me of something I have occasionally encountered over the years: Windows mail server admins who insist that file system AV isn’t necessary on their server. The logic for this has always escaped me and no mail server admin I have discussed this with can provide me with a reasonably sound argument of why AV shouldn’t be installed.

The arguments usually are something along the lines of “performance,” “it conflicts with x MTA” or “the vendor won’t support it.” Let’s look at each of these:

1. Performance: There’s no question that having AV running on your system can affect performance. It can affect performance on any system if the proper exclusions aren’t made. To use the argument that it shouldn’t be installed at all because of performance reasons is to argue that it shouldn”t be installed on any system. After all, everybody is concerned about performance.
2. It conflicts with my MTA: That’s what vendor-recommended exclusions are for. Of course, you don’t want your AV scanning your 500GB mail data file. Exclude it. But don’t go crazy and exclude entire partitions. Have justifications for your exclusions and use a scalpel, not a sledgehammer.
3. The vendor won’t support it: If the MTA vendor says that file system AV cannot be installed, find a different vendor. Seriously. They are taking the easy way out and putting your users at risk. Kick them to the curb and let them know why. Bad security choices by vendors need to have consequences for them to realize that they need to do better.

A worm spreading through administrative shares will be just as happy to devour your mail server as it will any other vulnerable Windows system. Mail servers generally need both file system and MTA-level AV for full protection. Anything less on a Windows system is risky behavior and may lead to very unhappy users.