In this module, we're going to look at the remaining parts of requirement 6,
and these are all about secure software development.
So first of all, requirement 6.3,
which is really about making sure that security is embedded
in the software development lifecycle.
The requirement is split into three parts.
The software should be in accordance with PCI DSS,
based on industry standards and best practice,
and making sure that security is embedded in the software development lifecycle,
and at each of those parts it's actually pretty large ask so
let's quickly take a look at each one.
Firstly, the requirement to develop software in accordance with PCI DSS,
which you might think strange, because other than requirement 6,
PCI DSS doesn’t have explicit software development standards,
but if you think about it,
there are lots of things that PCI DSS requires that
will be implemented in software.
Such as how requirement 3 wants stored PANs to be encrypted,
hashed, or truncated,
and that cardholder data needs to be encrypted in
transit across open public networks, and that vulnerabilities have to be patched.
So that implies any software that's developed would need to
have a secure way of being patched or updated.
And also that any developed software could comply with requirement
7's need for least privilege access and requirement 8's barely
prescriptive ways in handling user ids, passwords,
and authorization,
and that applications are written to support the
logging specified in requirement 10,
and so that's what this requirement is really about.
That any developed software allows you to comply with
all the requirements of PCI DSS.
Let me give you an example.
Look.
If you build an application to process payment card data that had
its own user and password management system,
but you set the maximum length of the password field in
this application to be six characters,
the application would never be able to PCI DSS compliant.
Look, I know it's a bit of a daft example,
but no one would ever would create the password field of six characters,
but you get the idea.
Requirement 6.3 also wants software development to be based on best practice,
and there are countless standards an organization can follow.
The PCI Security Standards Council has published a relatively new standard,
the Software Security Framework,
which is a guide to writing secure software that processes cardholder data.
It's not a requirement of PCI DSS that uses this,
but it's actually a great baseline to use,
and if you don't use this standard, pick another one to follow.
The third part of 6.3 is that security has to be embedded in the
software development lifecycle so this means that security needs to
be embedded in requirements definition, software design,
business analysis, the actual development itself,
and the testing of the code, and finally how software is released.
In testing requirement 6.3 and its sub requirements,
the QSA is going to look at all the documentation relating to software
development processes and the software development lifecycle.
The QSA will also talk to your developers to make sure
they know about it and that it's used,
and although it's not listed as a testing requirement,
the QSA will undoubtedly look for historic evidence
that the processes have been in use.
There are a couple of sub requirements in 6.3 ; the first,
requirement 6.3 .1 wants to make sure that any credentials used in the
development environment don't get released into production.
And by credentials I mean application accounts, user ids, or passwords.
The reason for this is once the application is released to live,
an attacker can use this information to discover the
inside workings of an application,
which they could then use to compromise the running application,
and this is particularly true for point-of-sale applications,
and that's really where this requirement came for.
The QSA is going to check this is a requirement of that development process,
they'll also speak with the developers or the people responsible for
the promotion of systems from development to test to live or production
to make sure the credentials are removed.
Requirement 6.32 wants code reviews for all custom development activity.
The requirement itself is pretty simple.
The custom code must be reviewed by either automated or
manual processes before it is released,
but it's actually quite a complex requirement,
and I'm not showing the full text on the slide,
but it's got four parts to it.
The review's got to be done by an independent,
knowledgeable person,
it's got to be based on written standards that the organization has.
The errors round have got to be fixed,
and there's got to be management oversight of it.
So let's take a quick look at these in a bit more detail.
Firstly then,
the review needs to be conducted by someone who knows what they're doing,
and that cannot be the developer who wrote the code.
The review doesn't have to be undertaken by an external company.
An experienced developer would be fine, probably not from the same team,
though, so I've always said not from the same,
like direct line manager.
It's also going to be fine to use an automated tool,
but again,
the responsibility for running an automated tool and interpreting the
output shouldn't rest with the original developer.
So this might be a separate to something that you've actually got
running on an automated build and a check-in process,
but you'll actually have a separate manual code review by
somebody else who is independent of the developer.
The second thing is that the code review needs to be based on the
organization's secure coding standards or guidelines.
Thirdly,
that any errors picked up by the code review are
fixed before the code is released, which sort of sounds like common sense to me.
But finally,
there's a management oversight of this process while
where we're checking of the code review,
sign off that the code was reviewed,
and that all issues found in the code review were fixed before release.
To test this requirement,
the QSA is going to start off by looking at the documented development process
to check how and what sort of code reviews are required.
They'll then talk to the developers and code reviewers to see
the process is being followed and finally,
they'll check the release or development records to see if
there's been required management approval.