Run antivirus software on linux DNS servers. Does it make sense?

Solution 1:

One aspect of this is that recommending "anti-virus" to be on everything is a safe bet, for the auditor.

Security audits aren't entirely about actual technical safety. Often they are also about limiting liability in case of a lawsuit.

Let's say your company was hacked and a class action lawsuit was filed against you. Your specific liability can be mitigated based on how well you followed industry standards. Let's say the auditors did not recommend AV on this server, so you don't install it.

Your defense in this is that you followed the recommendations of a respected auditor and pass the buck so to speak. Incidentally, that's the PRIMARY reason we use third party auditors. Note that shifting of liability is often written into the contract you sign with auditors: if you don't follow their recommendations, it's all on you.

Well, attorneys will then investigate the auditor as a possible co-defendant. In our hypothetical situation the fact that they did not recommend AV on a particular server will be seen as not being thorough. That alone would hurt them in the negotiations even if it had absolutely no bearing on the actual attack.

The only fiscally responsible thing for an auditing company to do is to have a standard recommendation for all servers regardless of actual attack surface. In this case, AV on everything. In other words they recommend a sledge hammer even when a scalpel is technically superior due to legal reasoning.

Does it make technical sense? Generally no as it usually increases risk. Does it makes sense to attorneys, a judge or even a jury? Absolutely, they are not technically competent and incapable of understanding the nuances. Which is why you need to comply.

@ewwhite recommended you speak with the auditor about this. I think that's the wrong path. Instead you should speak with your company's attorney to get their opinion on not following these requests.

Solution 2:

Sometimes auditors are idiots...

This is uncommon request, though. I would counter the auditors recommendation by securing/limiting access to servers, adding an IDS or file-integrity monitoring or bolstering security elsewhere in your environment. Antivirus doesn't have any benefit here.

Edit:

As noted in the comments below, I was involved in the launch of a very high-profile website here in the US, and was responsible for designing the Linux reference architecture for HIPAA compliance.

When the matter of Antivirus came up for discussion, we did recommend ClamAV and an application firewall to process submissions from end-users, but managed to avoid having AV on all systems by implementing compensating controls (3rd-party IDS, session logging, auditd, remote syslog, two-factor auth to the VPN and servers, AIDE file-integrity monitoring, 3rd-party DB encryption, crazy filesystem structures, etc.). These were deemed acceptable by the auditors, and all was approved.

Solution 3:

The first thing you need to understand about auditors is they may not know anything about how the technology in scope is used in the real world.

There are a lot of DNS security vulnerabilities and issues that should be addressed in an audit. They will never get to the real issues if they are distracted by bright shiny objects like "antivirus on a DNS server" checkbox.

Solution 4:

Typical modern anti-virus software does more accurately attempt to find malware and is not only limited to viruses. Depending on the actual implementation of a server (dedicated box for a dedicated service, container on a shared box, additional service on "the only server"), it's probably not a bad idea to have something like ClamAV or LMD (Linux Malware Detect) installed and perform some extra scan every night or so.

When asked in an audit, please do pick the exact requirement and take a look into the accompanying information. Why: too many auditors don't read the full requirement, are not aware of the context and guidance information.

As an example, PCIDSS does state "deploy anti-virus software on all systems commonly affected by malicous software" as a requirement.

The insightful PCIDSS guidance column specifically states mainframes, mid-range computers and similar systems may currently not be commonly targeted or affected by malware, but one should monitor the current actual threat level, be aware of vendor security updates and implement measures to address new security vulnerabilities (not limited to malware).

So after pointing at the list of around 50 Linux viruses from http://en.wikipedia.org/wiki/Linux_malware in comparison to the millions of known viruses for other operating systems, it's easy to argument a Linux server not to be commonly affected. The "most basic set of rules" from https://wiki.ubuntu.com/BasicSecurity are also an interesting pointer for most Windows-focussed auditors.

And your apticron-alerts on pending security updates and running integrity checkers like AIDE or Samhain may more accurately address the actual risks than a standard virus scanner. This may also convince your auditor of not introducing the risk of installing an otherwise unneeded software (which provides a limited benefit, may impose a security risk or simply break).

If that doesn't help: installing clamav as a daily cronjob doesn't hurt that much like other softwares.

Solution 5:

DNS servers have become popular with PCI auditors this year.

The important thing to recognize is that while DNS servers do not handle sensitive data, they support your environments which do. As such, auditors are starting to flag these devices as "PCI supporting", similar to NTP servers. Auditors typically apply a different set of requirements to PCI supporting environments than they do the PCI environments themselves.

I would speak to the auditors and ask them to clarify the difference in their requirements between PCI and PCI supporting, just to make sure that this requirement didn't accidentally sneak in. We did need to make sure that our DNS servers met hardening guidelines similar to the PCI environments, but anti-virus was not one of the requirements we faced.