Can I just really quickly ask you about requirement 6.6?
Yes.
Six-point-six has always confused me as an assessor
and as the one running websites.
Right.
So for publicly facing web applications either put a
WAF in or use automated code reviews?
Is that fair?
Well, so the application security assessment, the alternative to the WAF, right?
I mean the goal was always,
like the core of vulnerability scan isn't going to find
application layer vulnerabilities or not very well,
right?
And the penetration test, the annual exercise is you know,
cost and labor intensive.
Absolutely.
Right, and so this seems like it was intended to sort of split the difference.
Right?
We're doing this on a per-release basis, right?
Some sort of application security assessment, right?
Now maybe the methodology looks like code review,
and maybe the methodology looks like penetration testing,
right?
Either could work or some combination of the two.
You know, probably using some sort of automation, right?
Again,
because you're trying to do this on a per-release basis so it's got to be
compact and sort of cost effective enough to do that.
So you want some of those integrated tools that fit
in the development lifecycle?
Ideally, ideally, right, or the WAF.
Or would you recommend both?
I mean, obviously I would recommend both.
I think in practice,
I think there maybe a little bit sort of a scanse
in terms of what they check for, what they protect against.
So yeah, I mean obviously you get more protection with both.
And they're quite complimentary.
They really are very complimentary and this is,
like we talked about,
one of the major areas for exploitation for bad guys to do
bad stuff so putting your protection dollars here is not
usually a poor investment.
So this is like, you know, this sort of 6.3, 6.5, 6.6 area is important.
Is there anything else we should cover here?
I mean I think there's a lot of merit to continuing to
refine your software security methodology,
right?
What you do when one of your assessment be okay?
I may say, hey, that's okay, even if it's rudimentary,
even it's basic, particularly if you've come from nothing,
right?
But if five years on you're continuing to do those same things,
that's probably not sufficient for the threats that you're facing,
and I may come along and say yeah, maybe I said that was okay last year,
but you need to do better.
So constant evaluation of that.
I think so.
And if you look at the way we used to write web applications three
years ago or five years ago and the way we do it now,
it's actually completely different.
It's very different.
We're using different frameworks and different libraries.
Right.
There's one thing I want to pick up on before we close this course,
which is you said, you know, about teaching developers,
and I've done a bit of work with Troy Hunt,
as you know,
and Troy does this brilliant course for developers
that's called Hack Yourself First,
and it shows developers how to be hacked so that you're actually
teaching a developer to be a baby pen tester.
Right.
So you teach them how to SQL inject and really grow the application.
And actually showing them how easy it is to do,
I actually find one the best ways of doing security,
because they think, oh, oh, oh, that was my code,
I just SQL injected my own; I'm not going to let that happen ever again,
right?
So I'm going to really emphasize that that is a really
great way of teaching developers.
Excellent.
Jacob,
thank you for partnering with me on this theory and practice of the
whole logical security stack needed in PCI DSS.
It's been a really great experience,
and I hope that that's drawn the strands of the real training together along
with the practical experience of what happens in an assessment,
what an assessor is looking for, and where people just get it wrong.
Thank you.