Archive for May 13th, 2010

13
May
10

Annoying Requirements – 9.7.1

There are some requirements that just seem silly and appear to have no real purpose other than to be lightening rods for PCI DSS naysayers as why the PCI DSS is an inconsequential standard.  One of those requirements is 9.7.1 which states, “Classify the media so it can be identified as confidential.”

I think we all understand what the PCI SSC is getting at here.  They want to make sure that all removable media, in particular magnetic tape, is labeled as “classified” so that if any removable media goes missing, people that find any such media know that it is to be treated as confidential and not be released in the public domain.  This is predicated on the idea that people are basically honest and would obey such a labeling and would not investigate further.  However, the people that are the threat could really care less that the media is labeled confidential, that is why they want to get a hold of it.

Then there are the security experts that argue that by labeling something as ‘confidential’ all you are doing is further identifying the media as something that needs to be further examined by a person to see why it is confidential.  After years of conducting social engineering testing, I tend to agree with these experts.  Human nature just begs some people to find out why something is labeled ‘confidential’.  This is why leaving thumb drives or CD-ROMs in parking lots labeled ‘Customer List’ and sending out spam with links to the latest naughty celebrity interview, pictures or video still are very effective social engineering ploys.

The PCI DSS was created with numerous requirements that cover one another such that if one requirement is not performing completely, the other requirements will fill the gap.  In this case, there are a number of other requirements that cover 9.7.1 such as:

  • 3.1 – Keep cardholder data storage to a minimum.
  • 3.2.1 – Do not store the full contents of any track from the magnetic stripe
  • 3.2.2 – Do not store the card-verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions.
  • 3.2.3 – Do not store the personal identification number (PIN) or the encrypted PIN block.
  • 3.4 – Render the PAN, at a minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs).
  • 9.5 – Store media back-ups in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility and review the location’s security at least annually.
  • 9.6 – Physically secure all paper and electronic media that contain cardholder data.
  • 9.7.2 – Send the media by secured courier or other delivery method that can be accurately tracked.
  • 9.9 – Maintain strict control over the storage and accessibility of media that contains cardholder data.
  • 9.9.1 – Properly maintain inventory logs of all media and conduct media inventories at least annually.

Even if these other requirements are not met, just what does the PCI SSC and the card brands think a label is going to do?  It does nothing to improve security and ends up as “make do” work for some clerk to label all tapes, CD-ROMs, thumb drives, etc.  The epitome of those Dilbert cartoons from the 1990s that lambasted the ISO 9000 compliance craze.

To comply with this requirement, all I ask my clients to do is to declare all information, at a minimum, as confidential or whatever their second lowest data classification is called.  That way all employees know that, at a minimum, all information they come in contact with is confidential.  As such, they are not to share this information with anyone else unless there is a valid need to know that information for someone to complete their job.  But I do not require them to label removable media as ‘confidential’.

The message to the PCI SSC, get rid of this requirement.  It does nothing to improve anyone’s security.




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

May 2010
M T W T F S S
« Apr   Jun »
 12
3456789
10111213141516
17181920212223
24252627282930
31  

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

Join 1,775 other followers