03
Mar
09

Requirement 6.6 – Part 3

Because an application firewall is not an option for every application or every organization, the PCI DSS allows for code reviews conducted either manually or using automated tools.  Where I see most trouble with this is that people treat their applications like their networks and use their application vulnerability assessment tool after the application is put into production.  But that is not what the PCI SSC stated in their April 15, 2008 Information Supplement.

“The reviews or assessments should be incorporated into the SDLC and performed prior to the application’s being deployed into the production environment. The SDLC must incorporate information security throughout, per Requirement 6.3. Change control processes must ensure that software developers are not able to bypass the code review/application assessment step and deploy new software directly into the production environment. Change control processes must also enforce the correction and retesting of vulnerabilities before implementation.”

The reason the PCI DSS wants code reviews or application vulnerability testing done before an application is put into production is that, unlike the network, application changes can take significant time to implement.  If you do your code reviews or vulnerability testing after the fact, it could be quite a while before a fix is implemented to close a security hole.
So, to ensure that code reviews and vulnerability testing gets done at the appropriate time, these activities need to be an integrated part of your organization’s system development lifecycle (SDLC).  Most organizations conduct code reviews or application vulnerability testing as part of the quality assurance (QA) process before the application goes into production.  If any issues are discovered during the QA process, they can be sent back to the developers for remediation before the application goes into production.
Some application vulnerability tools provide integration with developer platforms such as Microsoft’s Visual Studio.  And, while these tools will notify the developer of potential security issues, it’s just good practice to fully assess the completed application during the QA process to be safe.
And speaking of application vulnerability assessment tools, remember, they are typically only useful against browser-based applications.  These tools typically have nothing to do with middleware or applications that do not interact through a browser.  This is where vulnerability tools that integrate with the developer’s platform can have a role as well as the use of code reviews.  And don’t forget the use of network vulnerability scanners and penetration testing tools for testing non-browser-based applications.  Even these non-browser-based applications still communicate over the network, so the use of vulnerability scanners and penetration testing tools can assist in identifying any security issues with these applications.
Hopefully this three part series has described the importance of requirement 6.6 and what you need to do to comply.

Advertisements

0 Responses to “Requirement 6.6 – Part 3”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

March 2009
M T W T F S S
« Feb   Apr »
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,903 other followers


%d bloggers like this: