Bryan Sartin invited me to a Webinar last week that summarized the Verizon/Cybertrust data breach analysis. Kokie Tjan informed me there is a PDF summary available online of the Verizon Business Data Breach Investigations Report.

This is the 10,000 foot view of a horizontal industry (payment systems).  Don’t forget to focus on how data breaches and risk applies to your specific vertical industry (i.e. higher ed, hospitality, travel and entertainment).

Sometimes those risks that affect the wider industry apply directly to you and sometimes you have very specific vertical industry threats.  As you may recall, one of my manrtas is “attack vector based risk management”.  In order to understand your risk you must understand the threats and ways an attacker values your data and systems.

It’s not always just the type and volume of data you store.  It’s also understanding how attackers view your exposed systems and what they think is easiest to attack and monetize.  Just like sailing a boat is not only about your skills as a mariner, you are also affected by the wind and water around you.

Popularity: 16% [?]

Have you considered disaster recovery for your payment systems?  Do you know the only thing that PCI DSS compliance requires you to backup?  David Bergert writes about the basics of how to prepare your payment systems in the event of a disaster.  But missing is the one critical element required for compliance.

The phrase “disaster recovery” does not appear in the PCI DSS.  The phrase “business continuity” only appears once in requirement 12.9.1 as, “[verify that the Incident Response Plan includes a] strategy for business continuity post compromise”.  Instead of referencing disaster planning the PCI DSS references backups.

There are a number of PCI DSS requirements relating to backups, such as:

• 9.5 “store media back-ups in a secure location”
• 10.5.3 “Promptly back up audit trail files”

What was that?  The answer is that audit logs are the only thing companies must backup for PCI DSS compliance.  Now, companies will want to continue business and as a result will backup all of their critical systems and corporate information, but this is outside the scope of PCI compliance which focuses on the security of payment card data.

Popularity: 14% [?]

Many people ask me how they can become a Qualified Security Assessor (QSA).  The only want to become a QSA is to work for a QSA company, be accepted by the PCI SSC, and attend industry specific training.  But what about the rest of us who want a badge of legitimacy without changing jobs?  For this there is the CPISM.

The Certified Payment-Card Industry Security Manager (CPISM) is the de facto certification for those within the payment-card industry who want to prove their security and industry knowledge.  To prepare for this rigorous exam there are a few documents available online to assist you.

First there are the CPISM Knowledge Domains.

• Payment card industry structure
• Payment card structure and data
• Payment card transaction processing
• Compromise fraud statistics and trends
• Merchant risk analysis
• Laws and the regulatory environment
• Payment card security programs
• Third party relationships

Check online for the following documents at the Society of Payment Security Professionals (SPSP):

• CPISM Overview Document
• CPISM Bibliography
• CPISM Study Guide

Still not ready?  Enroll in one of the in-person training classes and get direct education to help prepare you for the exam.  Check the SPSP website for dates and locations for the training classes.  The next one is August 13-14, 2008 in Salt Lake City, UT.

Popularity: 16% [?]

David Gamey pointed me to the Register article on yet another scam fraudsters are using to defeat credit card fraud checks.  We have discussed this topic before with pay-at-the-pump, but this new attack really goes to the heart of a fraud check that is called the Address Verification System or AVS.

Because AVS does not check all values in the address (i.e. just the house number or postal code) it is possible that an attacker could use an alternate address that has the same numbers (i.e. same house number but different street).

However fraudsters have begun exploiting the fact that many addresses can have the same AVS code. By making sure billing addresses and delivery addresses used in scams have the same code they make it more likely that purchases will go through.

This is, at best, a weak attack because it cannot be monetized quickly over a large number of card numbers.  In order to perpetrate the attack the attacker would need to have your name, address, and credit card number.  This information is usually obtained from e-commerce compromises, though could originate from other sources.  The attacker would then need to find a drop site that has the same information that is checked for in your address (i.e. same house number but different street).  This could work for one account number.  If they want to replicate it they need to find a new drop site, which is rather difficult and time consuming.

Also, let’s not forget that AVS is not used globally.   For example it is used in the UK, USA and some other regions, but not in continental-Europe and most of the Asia-Pacific region.  This diminishes the potential for attack.  Also, different Issuers may check different information via AVS which means you would need to know what information each Issuer checks, happen upon a card number from that Issuer, that is associated with an address similar to a fraudulent drop site you already have.  These stars do not align so nicely quite as often as one might think.

Popularity: 16% [?]

If you build a new deck in your backyard, would you test it out before inviting your friends and family over for a bar-b-que?  Well it turns out that many merchants are documenting compensating controls but not actually testing them to make sure they work.  How could this be?  I’m asking myself the same question.

There is a simple approach to understanding compensating controls that starts with asking the question, “When would I use a compensating control?”  The answer to that is any time that you have a legitimate business or technical reason.  For example, you may have some specialized technology that meets the intent of the requirement but not in the prescribed manner of the Security Audit Procedures (SAP).

Then you should document your findings, so you can show them to people if they ever ask, “what in the world were you thinking?”  This documentation should include those items listed in the Compensating Controls Worksheet.

1. Constraint - the business or technical constraint precluding compliance with the original requirement
2. Objective - the intent of the original control
3. Identified Risk - the risk posed by the lack of the original control
4. Compensating Controls - the controls in place that mitigate the risk to meet the intent that could not be achieved via the constraint

But you cannot stop here!  You actually need to test these compensating controls to make sure they hold up.  It’s not sufficient to say that a company uses RACF security on their Mainframe as a compensating controls for something else if you do not evaluate the security of the RACF configuration.  For each compensating control you must actually TEST it to make sure it is sufficient to mitigate the risk to cardholder data.

As Ronald Regan always said, “Trust, but verify!” (“doveryai, no proveryai”)

Popularity: 18% [?]

People complain about many things, but the question is: have you filled out a feedback form?  What, you ask?  There is a feedback form?  Oh yes!  And you should be filling it out and sending it back to the PCI SSC (Council).

Check out the Supporting Documents page on the Council website and make sure you fill out and submit the feedback form to the Council directly.

The feedback form is so merchants and service providers can provide feedback to the Council on what their experience was like.  Did you like your QSA?  Did you like your ASV?  Did you have a positive experience?  They want to hear it all.

If you really want to have an impact on the standard then jump in and become a Participating Organization.  Then you can give your feedback not just on the audit but on the standard itself.

Popularity: 15% [?]

Someone asked me a great question today about edge-case-PCI situations.  The question involved kiosks and their adherance to PCI DSS compliance. We know that kiosks can be just like any other point-of-sale (POS) if they are used as such.  That’s the operative term - how are they used?

Some kiosks actually are POS systems that exist in-line with other POS systems.  These could include self-service POS stations that must be secured and treated just like any other POS.  This is the simplest of scenarios.

Let’s now say that the kiosk exists on the cardholder data environment but is only a web browser that has assess to one web page - the merchant’s e-commerce website.  This system is not meant to be an actual POS but more of an Internet access terminal - that can only access one site.  But if it’s connected to the cardhodler data environment then it would be considered in scope for the PCI DSS audit.

But what if there is no merchant?  What if your kiosk is an Internet access terminal in a mall that can only access 10 different e-commerce sites (from merchants resident in the mall.)  Does this system have to be PCI compliant?  Sure it’s a dedicated e-commerce browser but there is no merchant ID or service provider to adhere to the requirements.

I think the lines of what is a POS and what is not are going to blur in the future as companies deploy more and more of these systems.  Companies will realize they need less and less of the cardholder data and will move towards system that eliminate the data rather than store-and-secure.

Update: 7/30/08 the PCI SSC released an update adding two new device listings to the PCI PED program.  These are “Unattended payment terminals (UPTs) and hardware (also known as host) security modules
(HSMs)”.  As Walt Conway points out, UPTs are basically Kiosks.

Popularity: 21% [?]

I finished a great training session today.  Everyone in the class really enjoyed the entertainment and several people described me as “animated” and “high energy”.  I hope that’s a good thing and I didn’t overdo it on the coffee.  One of the participants offered me a complimentary PayPal Security Key.  These are basically Verisign key fobs used for two-factory authentication.  These retail for about $15-20 but PayPal sells them at cost for about $5.

Being the security geek I am, I immediately enrolled it with my PayPal account.  I know nothing changed really, but I somehow felt more secure about my account (which I never use.)  I told Chipmonkey who immediately asked, “What if you loose the token?”  “Uhm… then I can’t log in… or have to jump through several hoops to log in w/o it.”

I think the mass market adoption of any two-factor technology will ultimately be in the form of cell phone payments.  Either your phone can be loaded with a “soft” token, or you simply get an SMS message with an authorization code you can enter into a POS.  Whatever the future holds, it’s nice to feel a little more secure in the present.

Popularity: 11% [?]

People have asked if Virtual Servers can be used in a PCI DSS compliant environment or if they violate requirement 2.2.1 which says, “Implement only one primary function per server”.  The answer is that virtual servers, virtual clusters, and even cloud computing are perfectly acceptable within the confines of PCI DSS compliance as long as they are properly configured.  The operative question when discussing the use of any technology within a PCI DSS compliant environment is always “Yes, but is it properly configured to prevent abuse?”

Hoff and Siebert both posted this question here and here.  People may think that <insert latest technology here> will somehow prevent a company from being PCI DSS compliant, when in reality the compliance program is built around protecting cardholder data.  That technology you want to implement is probably fine as long as it doesn’t put cardholder data at risk.  But people focus in on that one requirement and then everything falls apart.

PCI DSS Requirement 2.2.1 is like the ‘force’ in Star Wars - it can be used for good or for evil.  Unfortunately, it is the single most abused requirement in the standard.  Some people, using it for evil, go as far as to say that DNS and WINS cannot reside on the same server.  This requirement is meant for situations when companies try to pile every service imaginable onto one computer, causing a situation that actually puts cardholder data at risk.  For example, if a retail store manager uses the back office PC that aggregates their credit card transactions as their personal workstation for browsing the Internet.  This is a unsafe practice and violates several PCI DSS requirements.

Virtualization is an emerging technology that enables companies to securely leverage one physical server to run multiple virtual systems.  This is beneficial in areas with limited physical space.  If a company can run four virtual systems and only use the physical space of one server they can reduce the cost of housing and maintaining excessive hardware.

Additionally, virtualization provides a number of administrative benefits such as centralized data storage and security, centralized configuration and patch management, and a number of other processes.  Companies can benefit from using virtualized systems but they must also consider how these systems segment access from one to the next.

Just as with PCI DSS Requirement 2.4 (shared hosting environment) and the question of what defines “adequate segmentation” one must examine the security systems that separate one virtual system from another.  Any form of segmentation, virtualization, or shared hosting environment is acceptable under PCI DSS as long as it prevents one set of systems or people from negatively impacting the security of other systems or people.  The delineation point for what defines “adequate” virtualization is any system that can properly prevent one virtual system from negatively impacting the security of cardholder data on another virtual system.  It is the responsibility of the implementor to verify that such controls are in place.

Virtualization will continue to grow in popularity and, properly configured, can be used to adhere to PCI DSS compliance.  The technology itself is not often the culprit of non-compliance, instead it is how the technology is implemented or installed that can cause both security and regulatory compliance mishaps.

Popularity: 28% [?]

If you didn’t receive a copy of The Aegis newsletter for May then you may not be subscribed.  Topics discussed were:

• The Growth of Mobile Payments
• Virtual Servers and PCI DSS Compliance
• Visa’s new OpRegs
• QSA Fact and Fiction
• Industry Events and Happenings

Popularity: 22% [?]