So requirement 5, anti-malware/anti-virus,
and I know this as an assessor, and actually someone who runs networks now,
I know this is a hard requirement because,
you know, we have basically people having service,
and I don't, I nearly sad a bad word there.
I do not want this stuff running on my servers,
and then we have people managing fleets of point-of-sale devices saying,
I definitely don't want this stuff running on my point-of-sale device,
it slows it down, it might not make it not work,
you know?
So this is a tiny requirement with two big problems.
The first big problem is I just don't want to do this requirement.
What's your answer?
Well, if it is a system that is commonly affected by malicious software,
which for a long time, you know,
was a particular sort of set of operating systems.
Okay, but that was always a euphemism.
It was a euphemism.
Because the Council would not say if you're running Windows you must run AV.
Right, right.
And so it was a euphemism, and for those systems the answer is kind of tough,
right?
Like, do this.
Even things like that point-of-sale,
the embedded Windows that people want to sell run.
Are they still susceptible to viruses?
Yes, they are; they are.
One of the sort of unfortunate things,
if somebody talks about running a stripped-down version of a
particular off-the-shelf operating system,
what they have stripped down is not the attack
surface or the potential vulnerability,
but usually the means to do something about it.
So saying it's stripped-down Windows or it's stripped-down Linux
doesn't usually mean it is less susceptible to attack.
I mean,
unless it's very specifically sort of stripped down to
minimize those kinds of attack surfaces,
that that is relatively rare.
Right, and do I need to go and buy AV or anti-malware software,
or can I use the stuff in the operating system?
Well, it's tough.
You know, the folks that do the most sort of talking,
thinking,
and writing about anti-malware have for a long time
espoused use a free utility and a commercial utility and
when you look at malware trends,
when you look at particular attacks using motion software,
there's always that question, you know, these vendors and these products got it,
these products didn't, you know,
or at least a certain point in time before they all got caught up.
So having more than one gets you a better cross-section of coverage.
The standard still says anti-virus.
It does.
And I know from friends that there was discussion about
changing that at one stage to say anti-malware.
Right.
But if I use an anti-malware tool, say some of the more modern,
I hate to use the word machine learning,
artificial intelligence, endpoint protection agents.
Things that are not merely signature based.
Things that are not signature based like the traditional AV.
That meets the quality of the requirements, doesn't it?
It can, yeah, I mean you evaluate it on its merits,
right, but does it stop malware?
Now if you look at any of the major cyber-security advisories,
if you look at NIST, if you look at the U.K.
Cyber Essentials,
if you look at the Australian National Cyber-Security
Center Essential Eight or Top Four,
they all talk about application white-listing as being
one of the most important controls.
Is application white-listing good enough rather than anti-virus?
It can be useful, right?
I would say again, it comes down to what are you white-listing,
right, and what kind of happens at the detail level?
I've seen organizations do application kind of white-listing
things where one of the things that they white-list is like
the Java runtime on a workstation, right?
Well, are you limiting what Java files can be executed?
Well, no,
it doesn't really support that; it just prevents the or
allows the execution of this thing.
Well, so now I can run any hostile Java code on there, right?
That doesn't do you any good.
So application white-listing on its own wouldn't be sufficient?
Application white-listing on its own,
I would say you need to evaluate what is being white-listed,
right?
In certain cases, right,
if there are really only a limited set of things
that can execute on that system,
and they don't offer the opportunity for the attacker to
specify some parameter that's hostile, maybe so.
You mean, like PowerShell.
Yeah, if you white-list that, right, then yeah,
you've basically permitted, you know, hostile execution,
right?
And that's one thing; the other thing I think is
standards has got this thing about anti-malware removing
the malware after it's disabled it,
and typically application white-listing doesn’t have that capability.
So you sort of need the two things running.
Often, often, or at least the ability to sort of quarantine something harmful.
Yeah.
So can we talk about, there's probably two elephants,
there's two elephants in requirement 5.
Yes.
I'm going to talk about one because it's really funny.
As you might've noticed, requirement 5 at one stage changed to say and operating.
So I think in version 3 or version 2 of PCI DSS it said put anti-virus on there,
and then in version 3 it said put anti-virus on there and make it work.
And make it actually do something.
Because there was a very famous compromise where
someone had installed the anti-virus, they'd done everything,
but they disabled it,
and their argument was the standard didn't say it had to run,
which is one of the reasons why DSS is so prescriptive.
Right, it has to contend with this essentially bottomless well of bad faith.
Yeah, absolutely, and it's really hard to write bad faith interpretive standards.
It is tough.
But the real elephant we should talk about on requirement 5 is
this used to be a euphemism for Windows,
commonly affected, so as I still have clients saying,
well, I'm running Linux, I don't need to run anti-virus.
Right.
That's the most common one.
I'm running the macOS, I don't need to run anti-virus.
What's your take on that as an assessor?
Well,
so the requirement that showed up around version 3 in 5.1 .2 says for
systems not commonly affected by malicious software,
essentially do some threat evaluation to say,
are we actually affected by malicious software,
and if so,
should we employ some sort of anti-malware utility to protect these systems?
Now I read that as show me as your assessor some sort,
and it is an interview requirement, right?
But show me some capacity that makes a meaningful
kind of threat analysis decision, right,
to say what are the threats to these systems that are,
you know, Linux or macOS or mobile devices or what have you,
right?
And then are you susceptible to malicious software, right?
If you've got a Linux system, you know,
that's like a SAMBA file server that has a bunch of Windows clients attached,
yeah, I think there's a really good case for running anti-virus software there.
Me just making a statement to you saying, well, when it's Linux, bone head.
That doesn't count.
That doesn't cut it, right?
Saying, we have evaluated our threats, we can substantiate our reasoning,
we don't think this particular case merits it,
well, you know, then we can evaluate that,
right, and realistically, I don't think you can necessarily just say,
Linux systems, no, right?
Maybe our Linux web servers get one sort of treatment and
our application servers get another treatment and our
file servers get yet another, right?
And that seems reasonable.
Okay, anything else we should think about requirement 5,
because it's quite a short requirement, it's pretty self-explanatory.
It is, it is.
Just a slight sort of thing about conventional anti-virus,
it does talk about running periodic scans,
and so that actually means periodic scans and not
merely just on-access scanning.
So do actually configure it to run weekly or something
like that and not just on file access,
because that will catch things that the on-access won't.
I always try and ask in each requirement,
has a failure of this ever led to a compromise you're aware of?
Sure, or at least again has exacerbated an existing failure.
I don't do PCI forensic investigation anymore,
but I have,
and we get forensic images of systems that we've
acquired that have been attacked, right,
where there have been payment card compromises and we find
some piece of malware and we extract it out,
and then the anti-virus software running on our lab machines
then immediately lights up and it's like,
oh, this thing is bad, I'm going to quarantine it!
So despite maybe the arguments that conventional
signature-based anti-virus software is a relic,
which you know is not entirely without merit,
it does still catch plenty of bad stuff that you know,
captures payment cards.
But does more modern things that look for malware-type behavior,
i.e., oh look, it's trying to scrape memory.
That's going to give you an indication that there's a bad guy that's got in,
and it's part of your defense in depth.
This is a pretty important control.
It is.
I want to finish requirement 5 by telling a story.
Great!
Because you know about Struts and that Struts has vulnerabilities,
and I had a client who was running Struts on their web server,
and the Struts vulnerability,
this isn't the one that hit the big company last
year; this is about three years ago.
And it was a 0 date that was renounced, there's Struts,
there's a vulnerability, here's the patch,
and you know DSS says patch within 30 days.
They were hit within a day and a half of that
vulnerability being publicly published, and they're running Linux servers,
but they had decided to put anti-virus software on there.
And the anti-virus software spotted the root kit that the attacker
installed once they got access to the server.
And so the fact that he was looking for root kits
saved them a major data breach, because they got an alert when,
like within about a couple of hours, and they fixed it straightaway,
and without that running on their Linux server,
they'd have been had.
And that's actually why I would always put AV on Linux servers,
because at least it will give me root detection of those types of things,
known bad software.
Yes.