For some reason, I’ve run into an inordinate number of questions this week regarding vulnerabilities that weren’t addressed directly in the PCI-DSS — or at least only addressed in a cursory fashion. The document that contains many of these gems is one that most may gloss over; the Technical and Operational Requirements for Approved Scanning Vendors.

Some specific entries of note:

On IDS/IPSs:

Under no circumstance should an intrusion detection system/intrusion prevention system (IDS/IPS) be permitted to interfere with the results of a vulnerability assessment.

On unsupported software:

The ASV must report and determine as non-compliant any identified obsolete software (for example, application software or operating systems (OSs) no longer supported by the respective manufacturers.

On CVSS:

Generally, to be considered compliant, a component must not contain any vulnerability that has been assigned a CVSS base score equal to or higher than 4.0.

On web-application vulnerabilities:

The presence of application vulnerabilities on a component that
may lead to SQL injection attacks and cross-site scripting flaws
must result in a non-compliant status for that component

On denial-of-service:

Vulnerabilities or mis-configurations that may lead to DoS should not be taken into consideration by the ASV when determining component compliance

The quarterly perimeter scan is only a small part of PCI compliance, but it’s rife with idiosyncrasies and requirements for all parties involved.

Popularity: 48% [?]

Integrity has a very comprehensive whitepaper on “Oracle Applications 11i: Credit Cards and PCI Compliance Issues” [PDF] (added to Resources page)

It covers each of the 12 PCI DSS requirements as they relate to the Oracle database software. It’s really nice! Of course the true test is how the address encryption and audit logging - both very difficult items for databases. Does this paper address these items properly?

They have some great recommendations for audit logging (requirement 10) third-party tools, but their coverage of encryption (requirement 3) is a little lacking. (Granted this whitepaper is sometimes specific to their application, so oh well.)

Popularity: 21% [?]

Requirement 8 focuses on user access and authentication, but 8.5.16 focuses specifically on the authentication to databases within the cardholder environment. The need for this specific requirement stems from the fact that databases containing credit card data are prime targets for attackers and should be specifically addressed for proper authorization and authentication.

This requirement does not change much from v1.0 to v1.1 and it states:

Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users.

• Review database configuration settings for a sample of databases to verify that access is authenticated, including for individual users, applications, and administrators
• Review database configuration settings and database accounts to verify that direct SQL queries to the database are prohibited (there should be very few individual database login accounts. Direct SQL queries should be limited to database administrators)

This requirement focuses on two things:

1. Verify that databases require users to authenticate.  This means no Microsoft SQL with a blank ’sa’ password or Oracle with default passwords.
2. Verify those who have access to the database are properly authorized and authentication users or applications.

This means that developers or Q/A personnel should not have access to the production database.  If they need access it can be provided to them on an as needed basis and that access should be logged.

The last line says, “Direct SQL queries should be limited to database administrators.”
This does not mean an application cannot access the application.  What it means is that those who access the database directly (i.e. not via an application or the application itself) through a query analyzer or the like should only be DBAs.  This reiterates what was said above in that developers or other unauthorized personnel should not have direct access to the production databases.

Popularity: 12% [?]