Remember,
we looked at requirement 6.4 ; that's the one concerned with
change control in the previous module.
So now we're at requirement 6.5,
which demands that developers are trained to write secure code and they
have secure coding guidelines or standards to follow.
The requirement is actually quite specific in that the
training and the standards have to address what PCI DSS
terms common coding vulnerabilities,
and so sub requirement 6.5 .1 through to 6.5 .10 lists these common
coding vulnerabilities that need to be covered.
It's the minimum number that need to be covered according to the standard,
and if you look at the standard, it says that these 10,
which are loosely based on the OWASP top 10 are what were
the most common attacked vulnerabilities that were around
when the standards were released.
And because of that,
PCI DSS wants you to do your own continual review of which
vulnerabilities need to be addressed by your developers,
either by consulting the OWASP Top 10 when a new version is released,
or looking at other coding standards and guidelines such as the SANS CWE Top 25.
To validate that developers have been trained in secure
coding techniques and that training includes information
about all common vulnerabilities,
the QSA is going to look at policies and look at developer training records.
I just want to mention here that there's no requirement for the QSA to
actually observe the training content given to the developers.
They may well ask to see the training,
but if you can't let them because of legal or licensing reasons,
that's okay.
If you're not an expert of secure coding,
but this is an activity your organization does,
Pluralsight's got some great training courses to help you get up to speed.
Personally,
I really like this Play by Play with Troy Hunt and Andrew van
der Stock that goes through the OWASP Top 10.
Of course,
Pluralsight also has lots of developer courses that can help you to
meet this training requirement for your developers.
The sub requirements in 6.5 list the 10 common coding vulnerabilities
that the developers need to be trained to avoid.
The first six of these in requirement 6.5 .1 through to
6.5 .6 apply to all applications.
I'm briefly going to look at each one,
and the testing procedures for each one are basically the same so we'll
talk about the testing procedures at the end of these six.
So the first common coding vulnerability is an injection attack,
and that's typically going to be an SQL or an OS Command Injection attack,
and to defeat such attacks,
developers are going to need to understand how to sanitize
input they receive and not just pass input that they get to
something else to process.
The next vulnerability that developers need to be able
to address are buffer overflows.
When the developer puts too much data into an area of memory that's too small,
developers need to be trained to make sure that all input is
checked for size before they write it anywhere.
Requirement 6.5 .3 echoes really the whole of PCI DSS requirement 3.
The developers make errors in how they use cryptographic
functions and libraries so they need to be trained in the
correct use of secure cryptographic storage.
Following on from this,
the next requirement is the same for PCI DSS requirement 4;
to make sure that developers are able to use cryptography
when they're using data in transit.
And again, this is one area where there's been lots of compromises,
because unlike your favorite web browser,
most developers really struggle with checking certificates
and how TLS connections are created.
The next common coding vulnerability is error handling,
and there are a couple of areas the standard is particularly keen on here.
The first is to make sure that when an error condition happens,
the system doesn't divulge information that an attacker
will find useful such as an error message that gives more
information away than it should,
or an application that enters full debug mode when it encounters an error.
The second error handling vulnerability is to make sure that if
an attacker can make an application crash,
then the attacker doesn't get the ability to start to control the
application or the underlying operating system.
Requirement 6.5 .6 is a bit of a strange one,
and it aims to tie the vulnerability management process described in
requirement 6.1 back to the developer process.
So look,
if the vulnerability management process discovers
vulnerabilities in custom applications, let's think.
Yeah, look, say it found,
say there was a high vulnerability discovered in a software
library that was included in our application,
and the vulnerability management you were doing in 6.1 found this vulnerability.
This requirement 6.5 .6 would require that that software library
vulnerability was addressed in your coding standards to make sure that only
secure versions of the library were used going forward.
The testing procedures for all of these sub requirements are the same.
The QSA will check policies and procedures and also interview
developers to make sure they've been trained and understand how
to avoid these vulnerabilities.
The final four sub requirements of 6.5 are again more common coding
vulnerabilities that developers need to avoid.
However,
these just apply to web applications and that's irrespective of
whether the web application is a public facing application or an
application that's just intended for internal use.
Starting off with 6.5 .7, which is perhaps the most common web vulnerability,
cross-site scripting.
Developers need to be trained how to avoid this by
sanitizing all input into their applications,
whether that comes from a user, another system,
or even the application's own database,
because cross-site scripting can work in reverse where a system renders
information that wasn't sanitized from a database on screen.
The second web type of vulnerability is termed improper access control,
effectively giving unauthorized users the ability to access
resources over the web interface by something like changing the
URL path or changing some parameters.
The most common forms of this you hear are or you see are direct
object reference and directory path reversal.
Now one of the harder web vulnerabilities for
developers to get their heads round, is cross-site request forgery or CSRF,
which allows one web application to interfere with another web
application or website by taking advantage of a user's current
rites within their own website.
It's pretty easy to protect against by using access
tokens and checking for HTTP referrers,
but your standard needs to include the ways to avoid this
vulnerability and developers need to understand how to
protect their web applications.
The final web-only vulnerability is concerned with session management,
making sure that attackers cannot steal or tamper with the
user's session with a web application,
and that's typically all about how sessions are
recognized and how session cookies are used.
You know, for instance, flagging them HTTPS or flagging them secure-only.
Just as with the previous set of sub requirements,
the QSA is going to check there are secure coding guidelines that tell
developers how to avoid these common coding vulnerabilities,
and they're also going to speak with the developers to make sure they
both follow the guidelines and have been trained.
If you are, I don't know if it's quite if you are lucky or if you are unlucky,
but if your QSA comes from a software development background,
they will spend quite a bit of time on this,
and they'll ask your developers questions like how
would stop cross-site request forgery?
Can you explain it to me?
So you need to make sure, it's a good thing to do is check your QSA's background.