Sure.
And this might be something that's gone out of the market,
but there used to be a whole class of devices,
so requirement, I think it's 2.3, isn't it?
Yes.
2.3 that you must encrypt any admin traffic over the network.
Correct.
The reason being is that you don't want the bad guy being
able to sniff the username and password.
Right.
Okay.
But there used to be a whole class of devices where you couldn't do that.
Right.
Network switch.
Typically, network switches only had Telnet.
Right.
Is that still a thing?
It is because there are organizations that still have those devices.
But they just switch.
I mean, why would you need to upgrade a switch?
It switches.
Well, if I'm the attacker, if I can log into that switch,
if I can control it, if I can modify it,
now it's very, very easy for me to set up a man-in-the-middle condition,
and so I can immediately attack unprotected network traffic,
and I can potentially attack protected network traffic.
I would say that 2.3 rears its sort of proverbial ugly head in a couple of ways,
right?
One is if you've got really old devices like that.
And if you've got really old devices,
there may be other security issues lurking under the covers there as well.
But 2.3 also gets interesting and complicated when you're dealing
with SSL or TLS protected connections because there are lots of
complexities and problem areas for SSL and TLS.
I find a lot of organizations have struggled to catch up with
the deadlines to get rid of SSL and early TLS.
Which we'll talk about when we talk about requirement 4.
Right, requirement 4.
Yes, we will.
But there are a couple of other interactive sort of elements to that, right?
There are organizations that maybe figured that part out,
but still allow weak cipher groups or who,
particularly for internal endpoints that support SSL or TLS,
don't have a valid certificate, right?
Oh, it's internal.
It's just the default certificate for this web server, right?
Who cares?
But that completely undermines the authenticity of the connection.
You really don't want to be sure that when you connect to this
virtualization hypervisor or this network device or this security
appliance that you're actually connecting to that device and not
something masquerading?
You really don't want to?
Really?
So it's not just a case of not using non-encrypting protocols like Telnet.
It's a case of where you're using encrypting protocols to
make sure you're actually doing it properly,
to make sure that you're using not self-signed certs or not unsigned certs,
but proper certs to do all that certificate management,
to make sure that the application is not just ignoring
certificate errors if you wrote it yourself,
or you're not just going oh, click, and ignoring the certificate error.
Exactly.
And you're looking at that as an assessor, yeah?
I am.
Right, okay.
I am.
That's quite important because that's quite a step up because I think just
about everything you administer now is through a web interface.
Generally, right, or has some sort of TLS connection maybe less obviously,
right?
So if you've got LDAP over TLS or RDP using TLS,
actually, untangling RDP from TLS 1.0 is not straightforward,
and a lot of organizations attempt to do that and
have a ton of problems with it.
And from an attack perspective, this is,
most attacks are actually really simple.
So when I worked for a card brand, you'd look at forensics.
Ninety percent of attacks are really simple attacks.
They're against badly written software.
They're against people not patching.
And then you get the occasional advanced and moderately sophisticated attacks,
the ones that you see in the press eventually that
have lots of cardholder data in them, service providers,
very large merchants,
and it's things like this where the bad guy spent the time
getting in because the reward was worth it.
Yes.
Yes, very much so.
So although you might go yeah, I use TLS everywhere,
I use, hopefully not SSL, but yes,
I have encrypted connections for my administrators,
you actually have to spend more time on this than we used to.
Yes.
Okay.
Precisely.
Great.
Thank you.