• Observation of system settings, configurations
• Documentation review
• Interview with personnel
• Observation of process, action, state
• Identify sample

Well, good news everyone!  The document is now available to the general public. Hopefully, this will eliminate some of those awkward moments that seem to always come up during an audit:

QSA: “You need a documented policy that says you use network address translation. That’s not written down anywhere.”

Customer: “Can you show me where it says I need to do that in the DSS?”

QSA: “You won’t find it there, but I promise it says it somewhere.  I’m not allowed to show you, just trust me, you need it”.

Customer: “Can you just let me peek over your shoulder?”

QSA: “If you saw it, I would have to have your memory wiped.  Have you ever seen “Men in Black“”?

Customer: “I’m calling Security”.

It’s pretty hard to follow the rules when you’re not allowed to know what they are.  With this document’s public release a company can actually evaluate their controls and compliance program against the same standards that a QSA will use; no more guessing how to meet a requirement,  no more conversations where the auditor gives a seemingly arbitrary failing finding, with a “because I said so” for the explanation.  This should also allow for organizations to get a much better picture of the intent and expected implementation of a requirement by understanding how the controls will be assessed.  Well done, SSC.

Wireless keyboards are ubiquitous; there is a reasonable chance your organization is using them as the interface to a POS application or virtual terminal. The input could include customer name, expiration, PAN, and CVV. As we typically wouldn’t pay much attention to the peripherals that we type this data on, the question got me thinking about how much we take technology (and its security through obscurity) for granted. I did some exhaustive research on the subject (at least 5 minutes searching Google) and easily found some real world examples of wireless keyboard sniffing techniques; though not currently a prevalent attack, it is quite feasible to intercept the output from a wireless keyboard without leaving fingerprints behind. Unlike traditional keystroke loggers and screen scrapers, which can often be detected by antimalware applications, wireless attacks are transparent and do not require physical or logical access to target machines.

One of the more advanced tools out there is on Remote Exploit’s site, called KeyKeriki. This is a combination of hardware/software that targets the wireless signals from 27MHz keyboards (there’s a 2.7 GHz version on the way, too) and can capture or output the keystrokes. The hardware looks simple to build and includes an SDCard for logging; additionally, the software can do decryption of some weak XOR-based encryption on the fly (it takes about 40 keystrokes to get enough data to decipher the stream in real-time). I don’t want to go too far down the rabbit hole here as you can’t defend against every attack vector (PCI doesn’t address TEMPEST or Van Eck phreaking either), but there are some simple steps that can be taken to reduce the risk of compromise:

• Include standards for input devices in your list of approved hardware; pick keyboards that use strong cryptography to transmit data.
• It looks like many of the exploits are written to take advantage of certain vendor’s keyboards (I’m looking at you, Logitech and Microsoft…). Do some research when purchasing wireless keyboards to see if their communications security has already been compromised.
• If you do have a need for wireless input devices, consider using Bluetooth, which offers some protection through the use of a PIN and a custom SAFER+ block cipher implementation. Check the footnote for a good publication on Bluetooth and security from NIST.
• Drink plenty of coffee and/or adult beverages of your choice before typing credit card numbers. The resultant twitching/lack of coordination will make it more difficult for a malicious user to extract useful information from your typing. Bonus: it’s fun.
• Consider using wired keyboards for virtual terminals and POS workstations. Remember those things?

References:
https://www.pcisecuritystandards.org/documents/PCI_DSS_Wireless_Guidelines.pdf
http://www.remote-exploit.org/?page_id=598
http://en.wikipedia.org/wiki/TEMPEST
http://en.wikipedia.org/wiki/Van_Eck_phreaking
http://csrc.nist.gov/publications/nistpubs/800-121/SP800-121.pdf

If you are a payment application vendor, are you worried about the changes that have happened with the new release of the Payment Application Data Security Standard (PA-DSS)? For the most part, the requirements have not changed but there are a couple of items that may require some changes in the application, the documentation, or even the processes around the application.

Storing sensitive authentication data

In PA-DSS version 1.2, it was not acceptable to store authentication data (i.e. track 1 data, CVV, etc.). The revision for PA-DSS version 2.0 now allows for sensitive authentication data (track1, track 2, CVV) to be stored but only if there is sufficient business justification and the data is stored securely. This is only for card issuers and companies that support issuing processing. It has never been permissible for merchants to store this information even if encrypted.

During the testing portion of the audit, the auditor will be testing for sensitive authentication data using forensic methods. The auditor will also verify that the application is intended for card issuers and/or companies that support issuing services.

Auditing

One of the changes to PA-DSS is that the application needs to support centralized auditing. This means the audit data must be able to be moved to a centralized log server (i.e. syslog-ng, Windows Event Logs).

During the testing portion of the audit, the auditor is going to have to see that the lab has a centralized log sever configured and that the application logs are moving to this server. The PA-DSS Implementation Guide also has to provide instructions and procedures for incorporating the logs into a centralized logging environment.

One less requirement

As a final note, there is one less requirement. Requires 10 and 11 have been merged, instead of having two separate requirements, one for the merchant and one for the payment application vendor, there is now only one requirement covering remote access to the payment application.

Conclusion

The PA-DSS version 2.0 requirements, in most cases, are clearer. It makes it easier for payment application vendors to understand the requirements and to pass the audit.

PA-DSS

PA-DSS is a set of security practices and requirements developed by the PCI Security Standards Council to “…enhance payment account data security by driving education and awareness of the PCI Security Standards.[1]” The goal of PA-DSS is to help software vendors and others develop secure payment applications that do not store prohibited data, such as full magnetic stripe, CVV2 or PIN data, and ensure their payment applications support compliance with the PCI DSS. Payment applications that are sold, distributed or licensed to third parties are subject to the PA-DSS requirements.[2]

By ensuring the compliance of your application with PA-DSS requirements, your company   helps facilitate its customers’ PCI DSS compliance.

NetSPI’s Answer

NetSPI has developed a program guide to assist your company in getting payment applications validated. This guide prepares a company to get ready for the audit and allows them to better understand the requirements of the different pieces of the audit. These include the documentation requirements for the implementation guide, troubleshooting procedures, SDLC documentation including change control, vulnerability and software patching procedures and the training materials that are required.  It also goes into the topic of the interviews that will occur as well as the testing of the application.

What the program guide does not do is tell the different people in the company what is expected of them before the audit, during audit and after the audit. 

This validation process can be simple and easy or it can be long and tedious. Work with your auditor to get through the process, they have the experience to get you through the process.

Before the Audit

As a manager, there are processes that have to be planned for and started before the auditors come into your office to start the audit process. The application has to meet the PCI requirements, which include:

• Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data
• Protect stored cardholder data
• Provide secure authentication features
• Log payment application activity
• Develop secure payment applications
• Protect wireless transmissions
• Test payment applications to address vulnerabilities
• Facilitate secure network implementation
• Cardholder data must never be stored on a server connected to the Internet
• Facilitate secure remote software updates
• Facilitate secure remote access to payment application
• Encrypt sensitive traffic over public networks
• Encrypt all non-console administrative access
• Maintain instructional documentation and training programs for customers, resellers, and integrators

In addition to the application requirements, the documentation has to also be ready.The list of documentation includes:

• Implementation guide – The most important document without which testing cannot start
• Typical network deployment diagram and data flow diagram
• SDLC documentation (coding standards, code review process, software testing procedures)
• Development and test job descriptions
• Change control procedures
• Test/QA procedures
• List of all custom application accounts (if applicable)
• Web application testing procedures (if web-based application or web-based components)
• Wireless configuration guidelines (if applicable)
• Remote access documentation (if applicable)
• Encryption methodology (key management, generation, storage, distribution)
• Update process documentation
• Documentation of remote transmission of cardholder data, such as IPSec, TLS, SSL
• New security vulnerabilities identification process/policy documentation

In many instances, use of specific language within policies is required.  For example, the implementation guide requirements include required language, such as “Historical data (magnetic stripe data, card validation codes, PINs, or PIN blocks) MUST be removed for PCI compliance.” This wording is required by the PCI Council and if not included, can provide sufficient grounds for the rejection of the Report on Validation (ROV). NetSPI’s PA-DSS Program Guide has been developed expressly with intent of showing such working requirements.

As shown in the list above, documentation requirements are not limited to the implementation guide and need to be completed before a ROV can be filed. It’s not enough to have processes in place, such as the security coding standards; they need to be formally documented. Make sure to review the documentation requirements to make sure they are up to date.

The last but far from the least important part of the pre-audit process is to educate your employees on the PCI Council’s requirements for a payment application. They need to know that these requirements are not an optional part of the application and that they may be interviewed during the course of the audit. All team members should be familiar with established standards such as the SDLC documentation as well as be aware of the troubleshooting requirements as described in the process documentation.

Next Steps

The next blog entry will talk about what to expect during and after the audit.

[2] https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml

1. “The terminal just has a web-browser, and our payment gateway uses SSL. This workstation is out of scope and we don’t have to secure it. Antivirus is too expensive. Hold on while I install this kitten screensaver someone sent me through my AOL account on this terminal”.
2. “We don’t know how to deal with this PC, so we are cutting our company’s Christmas bonuses to pay for locking it down. We hired a team of InfoSec PhDs to harden the workstation and we have moved it into its own datacenter. To access it you have to go through a screening process that was rejected by the TSA for being too intrusive.”

To address the lines of thinking above, the SSC created the SAQ C-VT, which makes it pretty clear that virtual terminal workstations must be segmented and secured; the SAQ C-VT also provides streamlined requirements that are much more aligned with a virtual terminal’s function and typical configuration. For SAQ C-VT eligibility, a merchant must meet the following criteria:

• Merchant’s only payment processing is via a virtual terminal accessed by an Internet-connected web browser;
• Merchant accesses the virtual terminal via a computer that is isolated in a single location, and is not connected to other locations or systems within your environment;
• Merchant’s virtual terminal solution is provided and hosted by a PCI DSS validated third party service provider;
• Merchant’s computer does not have software installed that causes cardholder data to be stored (for example, there is no software for batch processing or store-and-forward);
• Merchant’s computer does not have any attached hardware devices that are used to capture or store cardholder data (for example, there are no card readers attached);
• Merchant does not otherwise receive or transmit cardholder data electronically through any channels (for example, via an internal network or the Internet);
• Merchant does not store cardholder data in electronic format (for example, cardholder data is not stored in sales and marketing tools such as CRM); and
• If merchant does store cardholder data, such data is only in paper reports or copies of paper receipts and is not received electronically.

The full SAQ C (v 2.0) contains 80 requirements; the SAQ C-VT has a trimmed down 51. The changes are summarized below:

• In SAQ C-VT, a personal firewall is required
• The requirements to encrypt non-console access have been removed
• There are no longer 3.x requirements for storing authentication data, as you wouldn’t be doing this in a VT situation
• Encryption strength and security protocol configuration requirements are removed (4.1(c) and (d))
• There are no longer requirements for encryption of wireless transmissions of cardholder data
• Antivirus and patching requirements stay the same (as they should)
• Remote access for vendors and two-factor authentication requirements are gone
• Quarterly wireless scans/NAC for detection of rogue access points are gone, as well as the associated requirement for inclusion of wireless access point detection in the incident response plan
• This is a BIG ONE: Internal and external quarterly scan requirements are gone. This in itself should make a very compelling argument to ditch the card swipe and start typing out those card numbers
• Several requirements for ‘critical technologies’ are gone, including authentication for use of remote access, acceptable network locations for use of the technology, and automatic disconnection and activation of remote access technologies

Also, props to Branden Williams (truly a gentleman and a scholar) for being the first to make me aware of the release of the new 2.0 SAQs on his excellent blog.

It’s an understandable approach given the magnitude of your other concerns, but it is a decision that may come to haunt you, particularly given the emphasis that card brands (VISA, MasterCard, American Express, Discover, and JCB) have put on credit card security and the focus that they have been bringing to the healthcare field. Retailers have been struggling with credit card security for years, but the card brands have started to cast a wider net, and healthcare has become a primary focus for PCI compliance.

I am sure that you are aware of the Payment Card Industry Data Security Standards (PCI DSS), a very broadly applicable security standard that concerns itself with all aspects and environments that deal with credit card information. What you might not be fully aware of (or may not fully understand the implications of) is the Payment Application Data Security Standard (PA-DSS.)  This standard is managed by the same organization that manages the PCI DSS and, with some important due dates having recently passed us by, healthcare software companies are only just starting to “wake up” to the fact that they may have to worry about PA-DSS. In this pair of articles I attempt to do three things:

1. Provide a brief overview of PA-DSS and why it came into existence.
2. Help you understand why you should know and care about the PA-DSS.
3. Provide you some steps that you can take to make sure your vendors are addressing PA-DSS

What is the PA-DSS?

To provide a bit of context, it’s important to understand where the PA-DSS originated. PA-DSS was born from a previous program known as the PABP, or the Payment Application Best Practices program. The PABP program was a voluntary program created and administered by VISA that would allow application vendors to have a third-party assessor validate that their applications were built using security industry best practices. The PABP was a program that didn’t have a lot of teeth, wasn’t overly prescriptive, and wasn’t mandated by VISA, so only a handful of companies (mostly retail-focused) bothered to go through the process – almost entirely for marketing purposes.
In 2008, the PCI Security Standards Council (the organization created by the major credit card brands to administer the PCI DSS) was asked to take over the PABP program and align it fully with the PCI DSS. The outcome of that effort is the PA-DSS, which translates the requirements of the PCI DSS into a standard that application companies follow to ensure that they are providing an application that their clients can utilize in a PCI DSS-compliant manner. The PA-DSS is a very, very detailed standard whose requirements span documentation, technology, architecture, coding practices, process, lab testing, and a full SDLC investigation to provide a complete assessment of the security of the application.

These dual standards did create some confusion for organizations concerned with or subject to the PCI DSS.  Anyone accepting a credit card needs to be PCI DSS-compliant, but they didn’t have to use PA-DSS validated applications (a standard administrated by the same council.)  To make their own position clear, VISA stepped forward and stated that they required the use of PA-DSS validated applications for organizations processing VISA transactions.  As VISA accounts for the largest volume of credit card transactions in the United States, their stance on PA-DSS certainly carries a lot of weight.

Now, you may be thinking, ‘why all of this concern over a standard that is so focused on payment applications’?  The concern within the healthcare community comes from the definition of “payment application” – the PCI SSC has declared that, if an application fits certain criteria, it is considered a payment application, regardless of industry or the primary focus of the application. The criteria can be boiled down to:

1. Does the application transmit, store, or process cardholder data?  (i.e., does it touch relevant credit card information?)
2. Is the application sold, licensed, or distributed to third parties?  (i.e., it’s not an application that you developed internally or had custom developed for your organization)

An FAQ on the PA-DSS program and its requirements is located on the PCI SSC’s website but, if you consider just the two points above, this standard covers a lot of application solutions within the healthcare space. Basically, any software application that deals with credit card data, even if it’s the most ancillary aspect of that software’s functionality, is subject to the PA-DSS.

Why Should I Care?

So, why should you care?  Well, first of all, because VISA has mandated that every merchant (i.e., any organization taking a credit card for payment) must use PA-DSS-validated applications after a particular date. That date was July 1st of 2010 (yes, we’re already past the mandated date.)  VISA has indicated that acquirers (the organizations that process credit card transactions) “must take prompt action to move all merchants and agents to PA-DSS-validated applications” and, although they have not at this point documented consequences for non-compliance, typical consequences could include fines, higher interchange rates, or a straight refusal from VISA to process any of your transactions. Also, as VISA works through the acquirer, not with you directly, your acquirer might simply cut you off from processing any credit card transactions.

A second reason to care is that you may already be contractually obligated to address both PCI DSS and PA-DSS. Many payment processors already include provisions for your PCI DSS compliance in their contracts, but, given the pressure from VISA, PA-DSS requirements are starting to show up as well. That means that utilizing PA-DSS compliant applications for managing and accepting payment may be a requirement for taking any credit card, not just VISA-branded cards. Even if a processor doesn’t restrict card acceptance, it may impose a penalty in the form of a higher interchange rate to cover their own exposure to potential security ramifications or action by VISA.

The third reason (although not the least important) you should care is that this is an issue which may have a material impact on your organization, but is largely out of your direct control. You cannot have someone validate the software that you use in your facility (unless you are utilizing internally developed or fully customized applications) – the process needs to be initiated by the software vendor, the documentation updates need to be done by the vendor, the testing needs to be done on specific revisions of the applications, etc. You can’t fix this problem no matter how good you are at making your environment and facility secure. This is the responsibility of the application vendor, but it has the potential to have a significant impact on your organization’s ability to accept credit card payments.

I’ll elaborate a little further in the next section, but action needs to be taken to get your vendors moving in the right direction on PA-DSS. In the retail community, it took retailers screening vendors for PA-DSS and building PA-DSS into contracts for application companies to finally stop arguing and get moving on their PA-DSS requirements. Healthcare organizations are only starting to recognize that they need to keep their vendors’ feet to the fire on PA-DSS, and it’s only now becoming a big issue as a few of the more forward-thinking application companies targeting the healthcare space are starting to prepare for and go through PA-DSS validation.

Next up – what can I do?…

Requirement 3.1 of the PCI Data Security Standard (DSS) states that cardholder data storage must be minimized and a policy defining the appropriate retention length must be defined.  There may be legal or regulatory requirements relating to data retention that must be adhered to.  However, in most circumstances, documents containing full primary account numbers (PANs) need not be retained past 90 days, which is typically when chargebacks or disputes occur.  If there is no business need to store cardholder data (for instance, so that a third party can supply access to transaction data and provide a mechanism for disputes and chargebacks), merchants should consider purging or redacting PANs stored both electronically and in hardcopy.  Simply put: if you don’t need it, get rid of it.  Also, keep in mind that masked or truncated PANs are not considered cardholder data and, as such, are not subject to the PCI DSS and can be stored indefinitely.  Therefore, redacting all but the first six and last four digits of the PAN is a common method that organizations use to reduce or eliminate cardholder data while still maintaining the ability to reference a particular card or transaction, if necessary.

One common misconception deals with retaining financial records for audits.  Many organizations end up keeping paid invoices that include complete credit card numbers for several years.  However, this is not usually necessary.  Financial auditors are interested in seeing records of revenue and expenses, not individual credit card numbers.  In light of this fact, a simple change in business process can often significantly reduce burden associated with attaining and maintaining compliance.

When it comes to a remediation strategy, the first step in complying with Requirement 3.1 is to define an appropriate data retention policy that is based on business, legal, and regulatory requirements.  This will, of course, vary from organization to organization.  However, keep in mind that most business models do not require the retention of full PANs for very long after a transaction.  Once an appropriate retention period has been determined, an official policy should be documented.  Be sure to include any specific legal or business reasons for the selected retention period, as well as a formal method for disposing of both electronic and hardcopy cardholder data once that period has been reached.  Finally, implement the policy and purge historical data that exceeds the newly defined maximum retention period.  Remember that, in most cases, redacting PANs by blacking them out with a marker, cutting off the credit card section of a form and shredding it, or truncating data in a database is an effective way to reduce the cardholder data that is retained, reduce the risk of a credit card data breach, and meet the intent of PCI requirements.

For example, in the case of annual key rotation requirements in section 3.6, there is little ambiguity in v1.2.1, where an annual key rotation is required. If an entity feels that quarterly or monthly encryption key rotations are appropriate, then they have met and exceeded that standard. If the cryptographic cycle is longer than one year, then that organization has not met the standard.

In most cases, the real risk of compromise to otherwise protected data lies not in the age of the encryption key, but rather in the balance of section 3.6 requirements that are NOT addressed by key rotation – specifically the key generation, storage, distribution, and revocation requirements. Generate weak encryption keys, implement weak cipher strength, get sloppy with storage and distribution and allow anyone to arbitrarily change keys at whim – and the frequency at which you rotate keys matters little, even if you change them daily.

But is a QSA empowered to make risk-based decisions regarding the suitability of a client’s key rotation interval? Version 2.0 suggests this: conceivably a QSA may reject the practice of annual key rotation on the grounds that risk factors suggest a more frequent key rotation schedule, perhaps quarterly. If the organization does not meet the schedule mandated by the QSA, then that organization may fail the audit until such time that it meets the “QSA requirement.” The target organization may in turn argue that it has met the standard of PCI-DSS by implementing (and demonstrating) annual key rotation. They will cite “contempt of QSA” as the reason for their failure to comply with PCI-DSS. Who will referee this dispute? What recourse does either the target organization or the QSA have available to them, and what actions might they take to address the conflict?

Similarly, a QSA may determine that an interval of less than one year is appropriate, and that the cryptographic cycle should be five years. How has this met the standard? By the arbitrary judgment of the same QSA who insisted on quarterly key rotations for that (other) organization? If the QSA can demonstrate the risk-based approach used to determine the cryptographic cycle, would this be acceptable? How can this be demonstrated with a high degree of confidence? That is, how do we know that the QSA did not fudge some “voodoo” numbers to support his or her “risk-based” analysis? How will this be communicated to the Acquirers and/or Card Brands?

The only vehicle currently available to communicate deviations from the standard is the Compensating Control worksheet. In its current form, one can well imagine what such a worksheet would look like. But one would be hard-pressed to imagine that such a Compensating Control would convey a strong and convincing argument supporting a lengthy cryptographic cycle well below the minimums established in the PCI-DSS.

The last few days’ sessions were a great opportunity to review the changes with the SSC and card brand representatives, catch up with others in the industry, and dispel rumors about the new DSS version (there will be no Requirement 13 mandating the use of ninjas to protect cardholder data, and Ouija boards cannot be used for wireless access point discovery).   It should also be noted (if my wife is reading this), there was absolutely no beer consumed at Kook’s Sports Bar and all discussions were reasoned, civil discourses that ended promptly at 9:00 PM to allow for a full night’s sleep.

As far as the changes to the DSS, it should come as no surprise that there were not many surprises to be found.  As was pointed out several times throughout the course of our sessions, the DSS is a mature framework with a rising adoption rate throughout the world; major changes could have serious financial and operational repercussions on merchants and service providers who have already incorporated the DSS into their environments.  Keeping that in mind, the intent of v2.0 is to provide additional guidance and clarification based on the (apparently) thousands of communications that the SSC received in response to their request for feedback, and my first impression is that it succeeds in that respect.  Below are some of the highlights I picked up on from the meeting and SSC-supplied docs, in no particular order: 

• Clarification that PAN is the primary element for applicability of the DSS to a merchant/service provider environment and is the definition of ‘cardholder data’
• Sampling requirements will be more detailed, and will require more justification as to why the sampling methodology used for an assessment is considered sufficient
• There are clarifications for issuers that have a business need to store sensitive authentication data (SAD), which should provide more specific guidelines for retention and protection of SAD
• Additional requirements to secure PAN if hashing and truncation are used in the same environment, to reduce the possibility of malicious users reconstructing full account numbers
• At this point, an automated or DLP-type solution is NOT required for data discovery and scoping of the cardholder data environment, though tools of this nature can/should be used where appropriate
• “System components” now includes virtual systems in the definition
• Requirement 6 has been overhauled to merge internal and web applications, and “industry best practices” no longer means just “OWASP”, and includes SANS, CIRT, CWE, etc.
• News flash- two passwords are not considered “2-factor”. Glad we got that one clarified.
• Requirement 11 allows for physical site inspection for rogue AP discovery if appropriate. I can’t see this working well in a large physical environment, but may work for mom-and-pop retailers who can see every wire on their router. I can’t wait for my first opportunity to write a comment for 11.1 that includes “Bob, the IT guy, climbs through air ducts and drop ceilings on a quarterly basis to identify potential rogue APs”
• IDS/IPS must be included at the perimeter of the cardholder data environment and ‘key points’, as opposed to monitoring all traffic in an environment
• There was some discussion around a new SAQ C that would be applicable to ‘virtual terminal’ environments. This is a work in progress, and I didn’t hear an official release date

There are many other tweaks not included above, but no real game-changers in my opinion. I know not everyone will be happy with all of the revisions, but the DSS is by its nature a compromise between global applicability for all types of environments and nuts-and-bolts implementation.  There will still be requirements that have QSAs and clients scratching their heads, but my impressions are that many of the clarifications are long overdue and should make many of the requirements easier to interpret, test, and enforce.  Ninjas will just have to wait for version 3; be sure to get your feedback in early.

• Is there a checklist that exists that covers all of the PCI requirements?
• Are there requirements such as not storing PAN un-encrypted? 
• What about not storing full track data or other restricted data? 
• Are there considerations outside of OWASP? 
• Can you recommend a simple resource for all PCI-related requirements?

At this point in time, there does not seem to be a single source of reference that answers all of these questions.

Since there is no definitive source, this document covers some of the PCI requirements in relation to code reviews. A code review includes reviewing all of the code for the OWASP Top 10 Web Application Security Risks for 2010. The OWASP Top 10 is inclusive of the PCI requirements and answers most if not all of the above questions.

The OWASP Top 10 Web Application Security Risks for 2010:

1. Injection flaws – such as SQL, OS and LDAP
2. Cross-Site Scripting (XSS)
3. Broken Authentication and Session Management
4. Insecure Direct Object References – exposing a file, directory or database key
5. Cross-Site Request Forgery (CSRF)
6. Security Misconfiguration
7. Insecure Cryptographic Storage
8. Failure to Restrict URL Access
9. Insufficient Transport Layer Protection
10. Unvalidated Redirects and Forwards 

Risk number 7 specifically covers the question about storing PANs unencrypted. As for storing track data, this is partially covered by risk number 7. Track data is sensitive and needs to be encrypted while stored, but it can only be stored pre-authorization. Once the transaction has been authorized, the data must be securely deleted. This requirement is not covered by the OWASP Top 10.

Here is a complete list of the PCI requirements as they relate to the OWASP Top 10 (see the list above):

Requirement 1: Install and maintain a firewall configuration to protect cardholder data – this requirement is not typically covered in a code review

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters – this requirement is covered under risk number 6

Requirement 3: Protect stored cardholder data – this requirement is covered under risk number 7

Requirement 4: Encrypt transmission of cardholder data across open, public networks – this requirement is risk number 9

Requirement 5: Use and regularly update anti-virus software or programs – This requirement is not typically covered in a code review

Requirement 6: Develop and maintain secure systems and applications – this is fully encompassed in the OWASP Top 10 (both 2007 and 2010 versions)

Requirement 7: Restrict access to cardholder data by business need to know – this requirement is partially covered by risk number 4

Requirement 8: Assign a unique ID to each person with computer access – this requirement is not typically covered in a code review

Requirement 9: Restrict physical access to cardholder data access – this requirement is not typically covered in a code review

Requirement 10: Track and monitor all access to network resources and cardholder data – this requirement is not covered in the OWASP Top 10

Requirement 11: Regularly test security systems and processes access – this requirement is not typically covered in a code review

Requirement 12: Maintain a policy that addresses information security for employee’s and contractor’s access – this requirement is not typically covered in a code review

Start your code review checklist with the OWASP Code Review Guide and add to it for those requirements that are not covered by this guide. This includes securely deleting sensitive data (PANs, track data, keys, etc.) and application logging.

Another place to start or append to your checklist, if you develop .Net applications, would be Microsoft’s Index of Checklists .