Great.
Requirement 2 is all about hardening devices,
hardening operating systems, hardening anything you can harden.
Right.
My observation is that I don't see this done very well.
I think it's very often given kind of a sort of fig leaf of effort.
Yeah.
Or is sort of badly misunderstood, right?
I have a lot of clients come to me and say,
we use CIS, right, the CIS hardening standards,
which are perfectly fine.
There's nothing wrong with them.
But I look at them and then say, oh really,
you use the CIS standard for whatever operating system type.
You use the whole thing, really?
Have you looked at it?
Because there's a lot of stuff in any of those hardening guidelines,
and maybe some of it is impractical or is just a lot of
effort for relatively little return.
And the point of the requirement is not that you have to sort of
slavishly adhere to some third-party industry standard.
You can pick and choose from that, right,
and say we do these 10 steps, and then we skip steps 11 through 15,
and then we do 16 through 25 or whatever it is based on some kind of
justifiable rationale to say here's what we think is relevant.
Here's what we think is beneficial for us.
And so if you have a policy or if you have a hardening procedure
that says we base it off of this standard,
but we use this subset of what's in there,
then I can look at that and say, yeah, that's justifiable,
or no, you're missing some fairly important pieces,
and then we can evaluate how the devices are actually configured.
Did you configure it according to this?
If you say we did the whole thing of the CIS or whatever standard,
then what you're asking me to do is hold you to that.
Okay.
And so I'm going to go grab a sample of devices,
and I'm going to say did you apply the whole kitchen sink to all of these?
So don't say one thing and do something else.
Right.
Key message there, yeah?
Right.
What are the barriers then to an organization doing system hardening well?
Scale.
Well, scale can be a trouble,
particularly if you've got a long history of sort of not doing it and you've got
an enormous set of devices to then go retroactively apply.
This is actually where maybe cloud or software-defined
infrastructure is helpful because you can take a template,
hammer that into shape, and then deploy that across your environment.
So for legacy environments, are there good compensating controls you could use?
I'd say in many cases, I mean,
unless there's a specific sort of hardening step breaks functionality situation,
in many cases,
the cure of the compensating control is maybe worse than
the disease of just going to fix it.
So this is one where it's just like roll up your sleeves,
there's 300 devices you've not hardened out there,
and you just have to go harden them.
Right, just go do that.
Just go do that.
Right.
The other sort of interesting bit in legacy systems,
depending on what those legacy systems are,
if you're talking about a mid-range device,
an IBM whatever series I or whatever they're calling them now,
the hardening standards are maybe less developed in part because
the devices are sort of more hardened naturally,
right?
And there,
it's up to kind of the assessor and the assessed entity having enough
knowledge about that to understand that for what it is.
I mean, I usually look at this as like hardening Windows,
hardening servers particularly, hardening point of sale devices.
If you've got a whole fleet of point of sale devices, you want those to be hard.
Correct.
And then any workstations that still process or transmit.
Right, typically.
So, is there any way, is there any architectural way of doing it?
Are there any tools that allow you to do this hardening well?
Sure.
I mean, there are definitely tools, like for,
again,
if you've got a bunch of Windows servers and you can deploy
group policies to disable extraneous services and set
configuration settings in a certain way,
particularly if you've got a bunch of web servers or something like that,
you can deploy a bunch of web server parameters across a
whole environment and do that that way.
So that, again,
automation and centralized management is how you make this happen.
So this is an architectural control really.
This isn't about somebody going over to every single workstation.
It's about having an architecture that said this is how we build them,
this is how we test we build them, and this is how we deploy them,
yeah?
Right, at scale.
I mean, if you're going individually to every single box,
hopefully you only have three or four of them.
Yeah, I mean, where I'm working at the moment,
we actually use our file integrity monitoring agent.
We'll baseline the operating system and compare it to CIS.
And so that tells us really quickly if we're out of alignment with CIS,
and it pulls the latest CIS hardened builds through,
and then it re-baselines to it, so it tells us when we need to do something.
But that took a lot of work to get everyone to buy
into that as a way of doing it.
Right.
And that's a really interesting point because what that means is that you're
starting to see an interesting convergence in sort of the practice of
requirement 2 and parts of requirement 6 and parts of requirement 11 where
there's sort of one thing that covers all of that,
right?
Because there's one thing,
which is I don't want the bad guy to break into my servers that are doing
stuff that controls my cardholder data environment.
And all those things need to sort of run orchestratedly together.
And I think one of the problems with DSS is 10 years
ago that wasn't a way of thinking, yeah?
So there are all these separate requirements that have the same objective,
which is don't let a bad guy break into your server.
Right.