So software security and security in the software development lifecycle.
The end of requirement 6.
By now, you know, many people and thinking, gosh, there's a lot in DSS.
The PCI SSE has been talking about this for an awful long time.
In fact,
they're developing a whole new set of standards about
software development for payment cards,
which we'll expect to see coming in the future,
but you know,
if vulnerabilities of packaged applications and operating
systems is the number one cause of compromises,
poor software development is the second cause of things.
Easily.
I still can't believe I still read of SQL injection attacks happening to people.
Indeed.
So this is still really important.
We haven't fixed this as an industry yet.
No, we have not at all.
I’m going to take 6.3, which is software development generally,
and then 6.5, which is web-facing software development together,
and let's talk about the stuff that goes wrong in organizations,
the stuff that you're looking for as an assessor.
So firstly, you know,
we know how to do this stuff now; this is not rocket science anymore.
It's not.
There's lots of great courses on Pluralsight about
doing secure software development.
Microsoft really worked at how to do this a while ago.
So what are the barriers to organizations doing this well?
It's hard.
I mean, I'd say it's known; we know how to do this,
we have a lot of training,
there's a lot of sort of principles of good software practice,
but it's hard.
It's still a lot of effort.
You have to train developers.
You have to essentially focus the organization's software
development effort on software security.
It doesn't arise organically.
It doesn't matter if you've got a bunch of really smart programmers,
if you've got a really good software engineering team,
if they are not making software security a major goal,
it will not happen.
Okay, so it's not going to happen organically is what you're saying?
No, not at all.
So how do you make it, but it's organic, inorganic, how do you make it?
Well, structured, intended, right?
It's got to be a major focus for the organization, right?
And that means it has to win against, you know,
other factors like time to market or you know,
ease of development,
or just sort of the natural inclination to do kind of the lazy thing.
So you're going on site,
you're going to an organization that writes their own software,
that stores, processes, or transmits payment card data,
often an e-commerce website nowadays, or point-of-sale software.
How do you start that assessment?
What are you looking for?
So ideally, by the time I've gone on site,
I've gotten a hold of whatever their SDLC is,
the actual policy documents, right?
I like reading the policies, you know, on my tablet,
on my couch, watching Game of Thrones, rather than in their conference room,
right?
So ideally we have that, we've read it,
and we can immediately start asking intelligent
questions of their development team.
Tell us about your software development practice,
tell us about your software security practices,
right?
And you know, this is the one where nobody's a very good liar about it,
and so if they're not very good at it, it tends to show up very quickly,
right?
And frankly, the easiest tell is tell me about your code reviews, right?
The 6.3, 6.3 .2 talks about doing code reviews,
doing security reviews for code that's developed,
right?
Making sure that it gets reviewed for vulnerabilities and corrected
before it moves on in the process for release.
And very often organizations that are new to this or have a
very immature software security practice,
their code review is we gave it to a smart guy and he said it looked okay.
Okay,
but I'm just looking at the standard here to see
what the testing requirement is.
It doesn't say, give it to a smart guy.
No, it doesn't.
No.
It says, you know,
have somebody who understands application security and secure coding techniques
do the review and make sure it's not the originating author,
make sure that management approves,
make sure that appropriate corrections are implemented,
right?
But all of that,
I mean all of that can fall down if whoever's doing the review says,
I didn't find anything.
Does this have to be a human reviewing it or can it be a computer reviewing it?
No, it can absolutely be an automated tool,
right,
and there's lot of value in considering either a static
analysis tool or a dynamic analysis tool.
It can also be a manual tool.
A lot of organizations,
particularly small shops don't always have the capital to buy,
you know, the licenses for code review.
But that's cloud based, now, that's not expensive like it used to be.
It is increasingly inexpensive.
It is absolutely increasingly inexpensive and compared to labor costs,
you know, should be a pretty obvious win for this sort of thing.
Because a small shop, you know,
to find an individual with knowledge in code review
techniques and secure coding practice, if you only have two developers,
that's tough, isn't it?
It is very tough,
but a lot of the small shops are brim-full with confidence
that they know exactly what they're doing.
Oh, is this scenario where we have what I call the Dunning-Kruger effect,
you know, where people think they really know what they're doing,
but lack the knowledge?
But really, really don’t?
Yes, yes, that's very, very common.
It's very common in at least in the U.S., in payment application development,
right?
There are a few big players that generate,
that develop payment applications that are seen everywhere,
and then there are a lot of really small,
very niche developers that have you know,
a particular segment, pizza places or laundromats,
or whatever,
for a particular kind of region or for a particular network of clients,
and they're often very,
very small shops with just a handful of developers and the
kind of owner who wrote the first version way back when and
just don't have the expertise.
So they've got business knowledge, but not great secure coding knowledge?
Right, right, and many of them are very resistant to some of these ideas.
But as an assessor, I mean, you know, you're trying to not,
because you're dealing with two folders,
are they compliant and how can I get into a better state?
Right.
So how do you get people to a better state?
Well, ideally,
ideally you can show them this is what secure software practices are about,
right?
This is how we develop secure code.
These are the kinds of attacks that happen against insecure
applications and why you need to protect against them,
right?
And if you can reason with them, if you can show them,
this is how you do it, right, and yeah,
some of it is maybe a reach if you have very
immature software security practices,
but some of it is very attainable and you sort of ladder your way up,
right, then you can at least point them in the right direction,
right?
And get them on sort of a cycle of increasing maturity over a year.
Right, so your assessment is read the SDLC,
the SSDLC, see if it works,
talk to the developers and see if they do what's in the SSDLC,
and look at their code reviews.
Yeah, look at their output,
and the code review is the most sort of tangible
kind of software security output, and like I said,
it's the biggest tell, right?
If I looked at it and it was okay, right,
or if it's a checklist of the OWASP Top 10,
I checked for SQL injection, check!
Like oh, did you?
Right?
I'll come on to that in a second.
So do you actually look at code is the question?
Sometimes.
Right.
Okay, so you'll look at code and go well, that's not very good.
Well, or if it's, you know,
if there's a relevant section of code in like a code review.
Right?
A lot of organizations, when they do the code review,
they're doing a diff of you know, the current code versus the last version,
and so yeah, show me the diff; let's take a look.