So requirement 6.1 and 6.2.
Basically this is where in my experience, people lose cardholder data.
Vulnerability management, patch management,
so this is probably the most important part,
and we've got actually a whole module,
a whole separate module to talk about this.
So yeah,
not doing vulnerability management for me is the
number one cause of data breaches.
Every time I've seen forensics reports, it's like yeah,
it was a known vulnerability of the operating system or the application.
Same experience for you?
Very much so, very much so,
and it's very much where I see a lot of organizations
struggling with their compliance requirements.
Okay, as I talked about in the training module before this,
this is not about running a vulnerability scanner against the system.
That’s a whole different requirement.
So you can't do this by scanning things remotely saying,
oh look, that's got a vulnerability.
This is about managed,
proactively managing the software that you're running on your systems,
isn't it?
Yes.
How do you do that then?
Well, so I think you've got a couple of things, right?
One,
you want to know about vulnerability information for
the software that you're using, right?
So you need to subscribe to the relevant alerts from the
software vendors or the software providers,
or you know, an aggregator service like the U.S.
Cert or the like.
How are you assessing that?
As an assessor, when you go into assess 6.1 and 6.2,
what are you looking for from a organization?
Show me bulletins that you're getting, right?
Show me who you're getting it from,
does that match up with your technology stack,
and then show me what you do about it, right?
So take those vulnerability details that you get and then tell me about
how you organize that and then deploy those fix-its.
So you're looking for prioritization based on CVSS base scores?
You could.
So the requirement that talks about assigning a risk ranking vulnerability,
but the goal is that it needs to be objective and repeatable,
right?
So it's not just an opportunity for everybody to just sit
around and backslap each other and say, yeah,
we don't think that's that big of a deal,
right?
There's got to be some useful methodology.
Right?
A lot of organizations do use CVSS, right,
and maybe apply the temporal and the environmental scores,
which are not sort of typically applied.
You see,
I have seen organizations just take the base scores and they just completely
ignore their own environment and they just run it off base,
and that's insane.
It's kind of nuts, right?
And very often the temporal and the environmental scores help bring
some of those risks down from them and would conceivably make their
lives easier than fewer sort of urgent,
burning crises to deal with in terms of their patch management.
So from an architectural perspective, I mean,
should people be using tools for this?
Yes, to the greatest extent possible, and where they cannot,
they want a really, really detailed a list of the kind of one-off cases,
right, those funky security appliances or the legacy systems,
or the things that they cannot automate or tool effectively,
right?
Know where those are,
make sure you've got a really sort of firm grip on what
that is and what you need to do about it so that those
don't become the kind of forgotten, unpatched corners.
Right, and as an assessor, do you like it when you walk in and they say,
well, here's my vulnerability management tool?
Does that give you a warm feeling?
I like to see if it they can then say not just here is our tool,
but here's how we use it, and here's what we do,
right?
And then here is, you know, here is the outcome from that.
You know, if there's just an oh yeah,
here's the vulnerability management tool that we gave you know,
the dumbest person in our department to operate so that we
don't have to deal with either him or it,
right, I mean that's not great, but if it's an integral part of their operations.
I think the other sort of really important thing that I encountered time
and time again is that from a sort of strategy basis,
a lot of organizations aren't dealing with their
software end of life in a useful fashion,
and honestly, if you're not thinking about end of life for software components,
particularly the really underlying stuff,
the programming languages, the operating systems,
you know, the major application software stuff.
If you're not dealing with that at like a risk assessment level,
then there's probably something broken in your risk assessment.
Should that be in your PCI DSS risk assessment in requirement 12?
Well,
the requirement doesn’t stipulate as much so I cannot as
an assessor compel you to do that, but I think it's a really good idea.
Maybe an easy example.
I encountered a client, I don't know, five or six years ago at this point,
where all of their applications were written in Java 6,
right?
And Java 6 had been dead for a good solid while,
even Java 7 was either end of life or very nearly so,
and you know,
moving things to Java 8 to a supported version of Java
would've required an enormous engineering effort,
right?
Total re-write of not just a single sort of application, but several, right?
Maybe even as many as a dozen applications.
Right?
I mean, that's a huge undertaking.
Right?
And Java 6 and Java 7 frankly are riddled with you know,
nasty security bugs right, many of which don't even have any specification,
right, since they were you know,
acquired where a lot of the really severe vulnerabilities are,
we're not going to tell you, we're just going to say it's really bad,
right?
Yeah,
so I don't even know how you deal with a compensating
control for unknown vulnerability, like ehhhh,
it's bad, right?
Sandbox.
Yeah, put the application, you know, in a literal sand pit,
right, and then pour concrete over it, like there's your control.
So that not dealing with your end of life causes a severe set of problems.
So year two, you go back to an organization,
and I'm asking this question because I sort of guess I know the answer to this,
having been an assessor, having worked in cards.
Is this is something that people commonly fail on in year two?
Yes.
Yeah.
Yeah, well, it's very easy.
You know, I think we mistake an idea.
We talk about patching as a fundamental,
right, a security fundamental and we've been talking about it since whatever,
at least the 90s, and I think we conflate that with it's easy.
Right.
And it's not.
No.
It's a lot of labor, it's a lot of difficulty,
it's a lot of complexity,
it's a lot of aggravating the rest of your organization,
and you know, it doesn't bring in new revenues,
right?
So no, it's hard work.
Now the move to DevOps, is this our savior from vulnerability management?
Oh, no.
But we don't patch, we just redeploy a new hardened,
secure, up-to-date version of the OS?
Well, if what you're doing is taking your sort of template,
right,
and fixing the template and then pushing that deployed
template out across your environment,
because you've got some sort of cloud infrastructure or the like,
okay.
Right?
Sure, that can be of use, but yeah,
and that could conceivably remedy vulnerabilities,
right?
Yeah, I met someone who said that we never patch,
and it's like, you never patch?
He's like okay, I'm going to write 6.1 and 6.2, so no, here's what we do.
We take the operating system,
we take a new copy of the operating system fully up to date,
fully patched, and then we just redeploy that from here,
and it's like, yep, that would work.
Yeah, that would work.
If you capture all of the relevant software components, sure.
And the libraries and components?
This is hard to do, isn't it, because of everything that goes into it.
Right,
and I think it gets really tricky in situations where you have
different teams responsible for different components,
right,
or if you're using like a hosted provider that's
providing some managed services and they say,
we'll patch the operating system, but you patch the application.
Well, you know, when you're talking about a Linux or a Unix system,
where does the operating system end and the application layer begin?
I don't know.
And I know, you know, from looking,
and I speak to a lot of people in the industry still,
but you know,
not patching applications like if you're using content
management systems or a shopping cart, a very popular shopping cart application,
you know, the fact that that's not patched,
you know?
The bad guys can tell when you've not patched.
It's not, you can't hide this from them.
And so the second you're at the we have not patched and
the bad guys can use Google or Showdown and they see
you're running version Unpatched, you're just advertising your vulnerability.
You are, right, and if you've sandbagged yourself by,
you know,
not fixing Struts or running an old version of Tomcat or
something like that where the fix is not easy,
right?
The fix takes a lot of coordination and development effort, right?
Then you're advertising, I'm going to be vulnerable for a good, long while.
So now your web application file wasn't optimism.
And probably drinking heavily.
I'm not going to ask you about compromises because we know this is like
the number one cause of compromise in the industry.
A big Vegas arrow.
Yeah, I've no other way of saying, you know,
patch all the things other than patch all the things.
Patch all the things now and manage the vulnerabilities.
Right.
What I would say just in terms of schedule,
and this isn't even me, you know,
crazy ranting; this was in the Verizon DBIR from a handful of years ago.
Right?
The mediums and the lows are the things that should
get caught in your monthly cycle, right?
The criticals and the highs are the drop everything and patch now.
Because although the standard says 30 days for a critical,
the bad guys are not going to wait 30 days for you,
you know?
They have a database, they know what version of Struts you're running, you know?
My client got hit, you know,
within a day and a half of that vulnerability coming out.
People know about that; they're looking for you not to patch and then they're
going to come and attack you; there's no way around it.
The standard can't say two days because the whole world would be noncompliant,
but it means two days or two hours.
Yeah, hustle up!
Absolutely!
Compensating controls around this area?
These are very, very context specific, right?
So if there's a particular vulnerability that you cannot
patch because you have some constraint, it breaks some functionality or whatever,
then my question is, okay, what is that vulnerability,
right?
What is the leverage the attacker has, right?
And then how do you mitigate against that?
Okay,
and so that's going to be very case specific and
trying to do a one-size-fits-all, I think fails sort of categorically.
But it's an option, if you really have something that will break,
you can use compensating controls.
Yes, yes, you can.
So talk to your QSA early?
Right.
Okay, great.
I think we've wrapped up what I actually think are probably
the two most important requirements in DSS.
In fact, in any cyber security exercise, this is it.
This is it.
This is the good stuff.