Okay, fine, right.
We know that failures here are a massive cause of compromise.
Let's talk more about 6.5 so that's the anything that faces the web.
Right.
Yes, it says the OWASP Top 10.
Should you just look at the OWASP Top 10 or should you look at more?
Well, I mean I think the OWASP Top 10 is sort of the entry point.
Underneath each of those top-10 vulnerabilities,
if you actually go to the OWASP site, there's a whole wealth of knowledge,
how these vulnerabilities sort of get exploited in the wild,
how do you test for this,
how do you develop to avoid these things in the first place?
And so if you can go, you know,
plumb some of that and then incorporate that into your practices
to say here's how we check for this; here's how we make sure we
don't do it in the first place.
You know, that's useful, right?
But again, if you've just got the OWASP Top 10 checklist,
right, I checked for cross-site scripting,
check!
Right?
I didn't find any.
Fine.
So obviously this is a Pluralsight course.
Right.
Pluralsight has loads of great training for developers,
but in terms of the DSS, there's a requirement that developers are trained,
as their annual requirement.
Yes.
What are you looking for?
How are you evidencing that and what are you looking for?
So I want to see, I want to see two things.
I want to see the materials, right, or you know,
if the materials are sort of not public,
right?
If they have to pay for it and they don't want to give me access,
then I at least want some notion of what it contains,
right?
Maybe it's just I observe some of it on site while
somebody who has access to it can show me,
right, rather than, you know, whatever, right?
Or if they're developing their own materials
in-house then I want to see what is it, what does it contain?
And then is that relevant to their application, right?
And if they've got a lot of, if they're talking about OWASP,
you know, web vulnerabilities and then everything is developed on,
you know, IBM mid-range systems, right,
then maybe we've sort of missed the boat here.
Are you looking for just evidence that they like spent three hours
being trained or would you like to do a skill assessment of like some
proof that they've actually learned something?
Some sort of skill assessment would be good,
and then obviously like which developers attended this training,
right?
So some sort of attendance record, and yeah,
I mean ideally some sort of skill assessment or some
sort of demonstration of knowledge.
Sometimes that,
or you know at least the converse shakes out in
sort of other pieces of evidence, right?
If the code reviews, if the vulnerability scans,
if the pen test results, you know, show a lot of application vulnerability,
that tells me that the training isn't really doing anything.
Can you compensate and control any of this?
Conceivably, sure, right?
I guess I don't know how you compensate for a lack of developer training.
I could imagine, well,
I could imagine a situation where if you've maybe
outsourced the development effort to a third party over
which you don't have a lot of control,
but then you're doing some sort of security assessment on the
deliverable that they produced for you, maybe that's a compensating control.
As far as actually testing at some level in some capacity for
vulnerabilities in your software development effort,
right,
or in the work product that you create and having some
meaningful software security methodology,
I mean, you know,
maybe the shape it takes for your organization doesn't
fit the kind of conventional mold, maybe you don't have a lot of people,
but you need to do something here.