[PCI DSS 1.x] 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (par

[PCI-DSS] 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

5.1 For a sample of system components including all operating system types commonly affected by malicious software, verify that anti-virus software is deployed if applicable anti-virus technology exists.

A question for Assessors - Mitigate lack of AV

A question for Assessors - if there are any - or anybody who has experience.
What do you do if it is unacceptable from a business point of view to apply AV to a server. In my case adding AV would create an intolerable processing overhead and would actually harm the business revenu stream.

What would acceptable mitigation be in these situations?

Hello StephenT,

Some of the risk mitigation strategy would be:

  1. Use server platform with lower Malware risk, such as Linux/Unix.
  2. Ensure the server is minimalized with only essential packages installed and the OS is hardened.
  3. Do not use the server as a workstation. i.e. No Internet browsing, No email client. Use the server for only its dedicated function /role. All of the patches/new code to be added to the server should be downloaded to another workstation with full AV/Malware loaded and scanned/tested/ and QA’ed before moving over to the server
  4. Use least privileged account to run the server services and applications. Only a few, absolutely required for the server role accounts should be created on the server. Ensure none of the accounts have software installation privileges (i.e. root, Admin group, etc) and tighten file ACL to prevent any excessive rights.
  5. AV can still be used on many of the systems sensitive to any addtional CPU load via batch mode. The realtime mode can be off but the batch scan could run daily when system utilization is low.

Default-deny rule sets running on IPtables and Windows firewall could further help protect/mitigate servers from Malware risk.

HTH,

Dan

*nix systems

OK, what do you guys think about the requirment for Linux laptops needing AV.

These laptops will be connecting the M$ shares and Exchange.

Also how do you guy prove that the AV is current and running, especially for remote access.

So some form of integrity check when connecting over VPN, before being given access to the corp lan.

[ul]
[li]Do you think the requirment for AV can be challenged on *nix laptops/desktops?[/li][li]Do you think that there is a requirment for integrity checking during remote access authentication/authorisation?[/li][/ul]Thanks

Chris

malware controls

The key wording in PCI is “…systems commonly affected by malicious software…” - properly hardened Linux laptops with some file integrity controls would likely be adequate compensating controls given the current lower malware risk in Linux.

Windows desktops and servers have a relatively higher malware risk and so it would be difficult to justify compensating controls for not running anti-malware at all. If performance is really an issue then you need to consider new hardware or some sort of load-sharing.

In the meantime there are Virus-scanner available for Linux too and especially for desktops it is ok in my eyes to use these there. For linux-servers there it is a different situation and there we only use a rootkit-scanner …

Hi.I see you can give good advices.I am using on my laptop Kasperky antivirus of which I have found from to ten best antiviruses [FONT=&quot] http://www.best-antivirus.co/
is a good one?
i am waiting your answers
[/FONT]

Windows machines or linux? For Windows machines a single anti-malware control is no longer considered adequate. Kaspersky is okay but I would add a second anti-malware - perhaps at the Internet gateway.

Windows desktops and servers have a relatively higher malware risk and so it would be difficult to justify compensating controls for not running anti-malware at all. If performance is really an issue then you need to consider new hardware or some sort of load-sharing.