Archive for the ‘Compliance’ Category

Filed Under (Card Associations, Compliance, PCI DSS, Uncategorized) by Michael Dahn on May-21-2008

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% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Compliance, Merchant) by Michael Dahn on May-19-2008

Walt reminded me today of a conversation being had about the cost of PCI compliance.  Him and Scott have been calculating the cost of compliance within the USA.  They say it’s about $2 billion or more, give or take.  I cringe whenever someone calculates the cost of anything with so much variance.  It’s so difficult to determine the actual numbers because of the variance within each factor.  For example, within Level 1 merchants some are very, very large and others are very small.  Also, there is a variance in the mindset about compliance and the risk tolerance someone is willing to accept so they may implement different levels of each requirement.

It boggles the mind to think of how varied these numbers can be.  But what if.  What if you *could* calculate the total cost of compliance?  What good is that information?  Do you want to balance it against the cost of other alternatives for the industry?  The problem with such big numbers is that they rarely apply to the industry, but should apply to the individual.  It’s the old saying of “think globally, act locally.”  For example, companies quote the cost of card replacement, in the event of fraud, anywhere between $1 and $25 per card.  What does this large variance mean to the industry?  Not much, but it should mean something to the individual.  It should mean that, cumulative with other costs, it makes business sense for companies to comply with the PCI DSS.

I think the more interesting question is, “Why is the cost of compliance so high?” The answer here is that companies do not look to reduce the scope of compliance before pulling the trigger on security.  If business people drive the audit they look at cost and balance business requirements against security.  If security people drive the audit they will secure the hell out of a bad business process.  A part of defining scope is understanding the rules of compliance and your options for getting there.  Too often companies do not understand the intent behind each requirement, the attack vectors being used to perpetrate fraud, and thus do not understand how best to allocate security capital.

The resources are out there.  The truth is out there.  It’s your job to find it.  It’s our job to help you get there.

Popularity: 25% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Banking, Compliance, Merchant) by Michael Dahn on March-28-2008

aegenis.jpgAs you may know, my company, The Aegenis Group specializes in education services for PCI DSS and other regulatory compliance areas.  I’m happy to announce to announce we have taken it to the next level.

The Aegenis Group recently introduced an eLearning Solution specifically developed to meet the unique learning needs of the Payment Card Industry. The solution also allows Acquiring Banks to meet the education requirement mandated by certain card brands. The mandate requires Acquiring Banks to educate Level-4 merchants regarding their responsibilities for the protection of Cardholder Data and compliance with the Payment Card Industry Data Security Standard (PCI DSS).

This means that we are now offering merchant training for all merchant types, with a focus on educating the Level 3-4 (smaller) merchants.  It’s both scalable and global in its reach.  You can check it out online, and visit our booth at ETA in a few weeks.

Are you interested in educating your merchant base?  If you are an acquirer, large service provider, franchise, merchant association, etc. then contact us directly for more information.

Popularity: 27% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Compliance, PCI DSS, Vendors) by Michael Dahn on March-20-2008

transparent-official-blogger-bug-small.gifOver the past few weeks I have received hundreds of emails from vendors asking for a meeting at RSA.  As most media flacks, I’ve ignored these for the most part, but replied to any that mentioned “PCI” in their product description.

I’ll be attending and blogging at RSA 2008 and would like to interview as many product vendors as I can as they relate to the Payment Card Industry.  If you have a product positioned towards PCI compliance or the Payments Industry, I would like to meet with you.

Please email me or call direct (number on the blog as always.)

Popularity: 31% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Compliance) by Michael Dahn on March-19-2008

After ranting a bit about some security bloggers, I want to also give them kudos for some well written content. David Mortman writes a very compelling piece on Leveraging Compliance for Security.

… compliance is not a technology problem — it’s a business problem which needs a business solution. By instituting sustainable business processes that effectively leverage people and technology, enterprises will become not just more secure but also compliant with current and emerging regulations.

Popularity: 26% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Banking, Card Associations, Compliance, Merchant, PCI DSS) by Michael Dahn on March-3-2008

einstein.jpgOne of the terms economists have been throwing around is that of ‘stagflation‘.  This term describes an uncommon situation where both inflation is high and there is a stagnation in terms of production and employment.  You see, inflation typically implies higher production, which implies higher employment.  Currently, unemployment is high and combined with increasing inflation.

‘Stagpliance’ is how I describe the current compliance environment.  We have high compliance numbers (pdf) that should reflect a decrease in data compromises.  The problem is that data compromise numbers are still high. So the question is, why is this seemingly atypical situation happening?

Well, one explanation is that not everyone is compliant, meaning hackers are moving from the low hanging fruit to the next branch up the tree.  This is certainly the case in some large merchants and many small merchants.  Anyone who has investigated cardholder data breaches over the last five years can tell you that attacks are becoming more complex and hackers are moving to smaller merchants. But this is not the only explanation.

What has this experience shown us?  I believe the reason for our current stagpliance is due to the continued need for proper education.  Experience has shown us that (1) technology alone is not enough and that (2) data compromise is not the the result of failing technology but the lack of education.  Data loss is not the result of poor technology, but poorly configured technology.  As more and more people pay attention to compliance, data loss is moving to the edge, where merchants do not know data exists.  It is also continuing to happen in places where merchants do not properly understand their risks - based on active attack patterns.

Last year Visa published a Visa Business Review (VBR) that specifically called for acquirers to address compliance with their Level 4 merchant population using a risk based approach.  This VBR outlined several points, some of which are here blow:

  • “Define a process that prioritizes Level 4 merchants into appropriate risk categories or subgroups”
  • “Describe plans to educate Level 4 merchants about cardholder data security, storage of prohibited cardholder data and PCI DSS compliance. Include the planned communication channels and approximate frequency.”

The concept here is that acquirers empower their merchants through education to understand the risks facing them, and both address compliance and mitigate those risks appropriately.  This type of grass-roots effort is a great way to give merchants the knowledge to make risk based decisions on their own.

How many merchants that are hacked understand the Top 10 risks (and associated attack vectors) they face?  Large merchants don’t even always understand their risks because they are not aware of the current ongoing attacks.  I’ve always stated that security is not created in a vacuum.   In order to implement proper security you must first understand the current attack landscape.  Many small merchants have no idea of the top attacks they need to protect against.  An equal number don’t even know they are storing something that attackers want.

What has education shown us?   Compliance without education does not equal security.  In 2007, Visa trained thousands of merchants on the intent behind compliance requirements, the top methods of data compromise, definitions of cardholder data and cardholder data environment.  In each of these classes merchants felt empowered to take a risk based approach towards achieving compliance.  They felt empowered to make the right decision instead of the checkbox decision.  This is the kind of empowerment we need to properly address the security of cardholder data.

The problem is that there are many more merchants, millions in the US, and even more globally.  We need to educate those merchants, not just about compliance, but about risk!  I’ve long said that all the information about PCI is freely available to the world today.  It exists on blogs like this, on online forums and other places.  The problem is digesting that information into something useful.  What we need is true experts to assemble risk based, guided education for the large number of merchants globally.

In person training provides the greatest value but is also the most costly form of education.  The Aegenis Group teaches classes for large and medium sized merchants, but there is also training you can obtain from other sources such as Visa’s merchant education program, and industry specific venues like the Treasury Institute.

Stay tuned for more educational assistance from The Aegenis Group.

Popularity: 52% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Compliance) by Michael Dahn on February-28-2008

I wrote in the last post about the importance of education in mitigating risk.  I teach, literally, thousands of people around the world about PCI every year, and speak with even more people online and offline.  Even those who feel well versed in compliance and security have something to learn when we talk, because the problems we are trying to solve are not trivial.

There are over 370 people in the PCI Forum posting thousands of threads about the nuances of compliance.  This is not to say that compliance is impossible.  As long as you take a risk based approach to meeting the intent of the requirements it can be rather simple.  The problem is, it takes understanding how systems are compromised (specifically within the payments industry) to understand how to protect them.

On this note note, I really enjoyed reading about the One Laptop Per Child (OLPC) Bitfrost security architecture, designed by Ivan Krstić.

I constantly preach the following topics:

I’m happy to hear that others, such as Martin McKeay, also agree that compliance there is no single solution to compliance.  Compliance is more than the sum of it’s parts - the gestalt of PCI compliance is specific to each organization and encompassed the risk mitigation, specific to that companies business operations, as they work to protect cardholder data.

“There is no list, no resource to refer to, no silver bullet for compliance and despite many marketeers’ wishes, there probably won’t be.” - Martin McKeay

Popularity: 28% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Compliance) by Michael Dahn on February-26-2008

book.jpgI have worked in the Payments Industry for a long time and in information security long before that.  I have learned something from all my work protecting systems, simulating attacks, and investigating data compromises.  I’ve learned that compromises rarely result from a failing of technology but from the lack of proper education.

There are numerous merchants who are compromised and shocked that they even store cardholder data.  This is systemic in the small (Level 4) merchant community who either do not know about the risks associated with cardholder data retention or are promised by their POS vendor that they do not store any such data.  Later when they are compromised they all say the same thing, “I would have done something had I only known.”

Another example is when merchants feel that one component alone will secure them.  Many smaller merchants feel that having a vulnerability scan will make them compliant and thus secure.  Without proper education they end up paying hundreds of dollars a year for someone to scan their static website.  What has the world come to?  Are we so willing to sell security that we ignore the care involved in properly educating someone how to use it?

There are a number of programs available to educate and drive compliance in the Large merchant community (i.e. Visa CAP program and acquirer specific programs.)  These large merchants have the time and resources to educate themselves.  But what about the smaller merchants?  Some could say they have the PABP Implementation Documentation but that educates them about the technology not the data.

What we need is a focus on educating Level 4 / small merchants on the basics of cardholder data, compliance, and validation.  We need to refocus our efforts, not on the technology, but on the transference of knowledge to these merchants so they can protect the data.

Achieving high compliance numbers for small merchants would be great, but actively reducing their risk would be even better.  To achieve this we need a grass-roots effort on behalf of the small merchant community driven by top-down guided education.

Update: The comments people have posted are great.  I just want to add that the Visa CAP and PABP programs have been a great success in driving merchant compliance.  The PABP program offers secure tools to protecting cardholder data.  I argue that merchants need to be educated about these programs and how to implement the systems properly.  They need to know what cardholder data is and how to make risk based decisions from that information.

Popularity: 22% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Card Associations, Compliance, Merchant) by Michael Dahn on February-6-2008

level.jpgSince Visa has been reporting significantly higher compliance levels among Level 1-2 merchants, it is important to focus on the smaller merchant community. I was discussing this with a friend who asked, “What is a Level 4 merchant?” This is a very good question because it shows that some merchants do not understand the merchant level hierarchy and the associated reporting procedures.

The definition of a Level 4 merchant may vary depending on your geographic location and card acceptance type. For example the Canadian arm of Visa Inc. lists both Level 4a and 4b merchants. The other Visa regions (with the exception of Latin American and the Caribbean) define a Level 4 merchant as:

  • Any merchant processing less than 20,000 Visa e-commerce transactions per year, or
  • Any merchant processing less than 1,000,000 Visa transactions from any other acceptance channel (i.e. in-store POS) per year

MasterCard Worldwide does not have a Level 4 classification, but list them as any merchant that is not a Level 1-3 merchant. If you read the Level 3 definition you will see that they classify Level 4 merchants in much the same way as Visa Inc.

What does this mean?

Well, it simply tells you where you fall in the grand scheme of PCI DSS compliance. Remember that although compliance of the Level 4 community is mostly optional and managed by the acquiring bank or transaction processor, that all merchants regardless of level definition must be compliant.

Level 4 or small merchants should look to their point of sale (POS) system and make sure that it is in compliance with both the PABP and PIN security requirements. If you want more information on validating your compliance, then take a look at the latest self-assessment questionnaire released by the PCI Security Standards Council.

Popularity: 30% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Compliance, Payment Applications, pa-dss) by Michael Dahn on February-1-2008

I really like the reminder that Mike Rothman has to say about compliance, “The sad truth is that compliance is still the engine that is running most security operations.” Let’s not forget that the people who complain about compliance are also those who’s jobs are based on necessity for it.  Business is an easy formula: make more money and reduce your costs.  Is security is perceived as an unnecessary cost, it too will be reduced.

So instead of bemoaning and fighting the various aspects of compliance, why not leverage them to benefit the business.  Mike continues:

As we focus on 2008, the first order of business for security professionals should be implementing a structured security program that is focused on protecting what’s most important to the business, setting goals and milestones to ensure accountability and communicating how and why certain security controls are implemented. The end goal is to distinctly show the value and importance of security to the operations of the business.

So what’s next?  Well, those long time readers of this blog will know that it’s in inclusion of the Visa USA PABP into the PCI suite of standards under the PA-DSS moniker.

“With the PA-DSS managed by the council, we will ensure that payment application providers and their products are subject to data security requirements consistent with the current PCI DSS.”  Bob Russo,
general manager, PCI Security Standards Council

Furthermore, Visa has taken a proactive approach and outlined a series of Payment Application Security Mandates. These mandates outline the phasing out of vulnerable applications and phasing in of validated application with a fine deadline in 2010.

Popularity: 24% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]