[Autogenerated] thinking really required altogether then Typical
assessment behavior points Where do people go wrong here?
Starts moving leaving VLANs certain movies levers that generic users
You know too many add mons and Chrome E m f a o k.
Chrome YAML-file.
Alright, like the lousy like p k I certificates.
Um uh, you know,
one of the problems I think that's going to sort of rear its ugly head a
little bit more is the idea of independence of factors,
which shows up in guidance documents published by PC I
but is not currently a requirement.
But the idea that if I can get access to one of the factors,
you know that maybe I could get access to the other factor,
right?
So if it's a username and password and a certificate on a laptop
and I compromise that laptop with some malware,
I've got them both.
Right, So that's a that's a sort of future warning.
If you're building some new M f A today,
think about independence of factors,
so you don't have to end up re engineering this a couple years down.
The really good partner, right?
Yeah.
Um, So second assessments, I guess the B a U failure is just mostly starts,
movies, levers, but you're looking.
And there are people who have got accounts that are
no longer in the organization.
That is, that is the most common failure I find secondary year or thereafter,
and failures of requirement e mean I can say a massive course of compromise
after requirement six about just building insecure systems.
Now it's you've got a secure system,
but you don't ask your access to it s so that's a really common one,
especially the, you know,
in large service providers for any of the large service
provider forensic reports I used to see it was always a
compromise of the corporate network.
Then pour apps is control into the car load OData environment, right?
I think one of the things that you're maybe gonna start to see um,
going forward is attacks against even users that
have multi factor authentication, but have kind of lousy MF a using you know,
OTP over SMS or something like that.
You like that, Reddit Security incidents earlier this summer where they got Cem.
Cem read it at Mons, right?
Who had the one time password over over text message.
Right, which is relatively easy to suborn on.
So if if you've got a lousy M f a infrastructure and you're
you're not sort of moving off of that, that's gonna,
you know, that's that's the slowest moving target.
That's an interesting point,
which I'd like to probably finish on that one but missed.
Have deprecate id OTP over SMS?
Yes, you know, they said, was about a year ago that this really wasn't.
It's a terrible idea.
A za QoS a way.
Follow the mist guidance for strong cryptography If a
client comes to you and they say, Well, you know,
I have my two factor Authentication is SMS OTP.
Are you saying that's OK?
Or you You give in the past where you go in the past with warning or failure.
So I don't know if I've seen too many cases of that,
at least in my clients in the last year or so.
I have certainly talked about it and said,
Hey, these error, these areas of concern,
um,
you know when when I've had a chance to do some
speaking events or the like and I've said,
Look, if you're using a semester over OTP,
now is the time to get moving off of that because it's
going to start causing problems.
I am inclined to tell people that it's not compliant because it
is so easily sort of suborned and misdirected.
And if if you're a high enough value target,
um, you know, then somebody going to Somebody went after.
Read it right?
So think of what happens when there's something actually valuable.
DOM Great e Think that wraps that requirement eight Jacob next week.
So that's logical access to cardholder data.
And I guess the next thing we're gonna talk about is physical.
Physical APIs?
Yeah, bring it.