We’re clueless about PCI . . . Let’s blame the auditors

For whatever reason, it seems that every conversation that I’ve been having with security folks these days has tended to gravitate towards PCI compliance.  Maybe it’s just that SOX is so 2004, and NERC critical infrastructure protection compliance just hasn’t quite hit its’ stride yet.  In any case, PCI is a hot topic right now.  Heartland Payment Systems and more recently Network Solutions have had a wee bit of a problem with PCI data being breached.  A fellow member at the Central Indiana ISSA chapter brought some interesting PCI news to my attention at our monthly meeting last week.  First, some background information for your reading pleasure.  Utah based Merrick Bank has recently filed a lawsuit against Savvis, the auditor of CardSystems.  CardSystems provided processing services for Merrick Bank and was certified as having met Cardholder Information Security Program (CISP) standards, which were the predecessor to PCI DSS, by Savvis.  That was in June of 2004.  In May of 2005, CardSystems was breached.  I will spare you a full explanation of the legalese, and simply say that Merrick thinks that Savvis was full of it and that CardSystems should not have been certified as meeting CISP standards.  

So, who is at fault here?  Well, not having all the facts, it’s tough to say, so I will let this be slugged out in the courts.  I will say this however, that unless Savvis was completely negligent in certifying CardSystems, then this just becomes another case of folks thinking that a checklist is a cure-all for what may ail their IT infrastructure.  Case in point would be Heartland Payment Systems whose CEO, Robert Carr, had a Q&A session with CSO magazine regarding their massive data breach that occurred in January. 

In the article published last Wednesday,(http://www.csoonline.com/article/499527/Heartland_CEO_on_Data..) Carr places blame directly on Heartland’s QSA’s whose job he evidently feels was to save Heartland from itself.  In the article Carr says “(W)e certainly didn't understand the limitations of PCI and the entire assessment process. PCI compliance doesn't mean secure.”  My hunch about the compliance part is that’s what Heartland’s IT security staff has been trying to impress upon upper management all along.  To quote my fellow ISSA member, “management just doesn’t care until a breach hits home.  Until then, (the feeling is) it’s not going to happen to us.”  As I’ve said in earlier blog posts, there is a disconnect between the realities of compliance and what upper level management thinks about it.  So, management can blame the auditors for not telling them that “PCI compliance doesn’t mean secure,” or they can educate themselves and start listening to their IT security personnel.  Of course, managers are concerned about dollars and cents.  They often think of IT as a cost center, not an asset that can save them money.   Maybe they should look into what Heartland has shelled out so far and then rethink whether adequately securing their IT systems is worth it.

PCI DSS 2.0 released - What does it mean for you?

The new version of the PCI DSS requirements were released last Fall. If you were thinking that the new version would bring you enough work to occupy your every moment for the next several months, fear not. The changes from version 1.2 to version 2.0 are relatively minor, primarily clarifications to a number of existing requirements to give clearer explanations as to the true intent of the requirement. You can download the new requirements here.

The true cost of non-compliance

Cardholder data represents a large risk to any company that holds, processes, or transfers it. Fines levied by card issuers such as Visa and Mastercard can be extremely costly, not to mention the costs of notifying cardholders of a breach, legal action, and loss of your valuable reputation. While large enterprises typically take steps to ensure their PCI compliance, many small to mid sized firms fail to do so, believing that compliance is too difficult or costly.

The good news is that achieving compliance is often less difficult than imagined, and many requirements of PCI-DSS represent good information security practices you should already have in place. Deployment of other specialized tools such as integrity and compliance monitoring should be implemented to allow you greater insight into your PCI environment and automate checking of system settings for compliance. While achieving and maintaining PCI compliance is not without cost, costs should be weighed against the risk to your enterprise should a breach occur.

International Monetary Fund, Citibank Suffer Security Breaches

This past week, it was widely reported that both the IMF and Citibank’s IT infrastructure was breached. With a breach at Sony Online Entertainment and Sony Pictures occurring slightly more than a month ago, it appears that hackers are finding more holes in the IT defenses of organizations. In an eWeek article last week, Mark Hatton, president and CEO of Core Security, noted that deploying defensive technologies and hoping they keep the bad guys out is “clearly not working.” You can read the entire eWeek article on the Citibank breach here. For more information on the IMF breach, read the SC Magazine article.

Given that hackers seem to be readily gaining access inside networks, bypassing traditional “perimeter” defenses, what are companies to do? Certainly, perimeter defenses have their place, but now is the time to investigate other technologies that give multiple layers of security. In other words, ensuring a defense-in-depth strategy. Newer, advanced IT system integrity monitoring technologies such as CimTrak function as a last line of defense in IT networks, monitoring not only critical files, but also configurations on perimeter protection devices such as firewalls. Knowing when changes occur, such as a file being added or a port being opened, can mean the difference between timely detection of malicious activity and a breach.  Visit www.cimtrak.com to learn more.

Can you see paradise by the dashboard light???

The big buzz around RSA this year seems to be the concept of dashboards.  By establishing frameworks, various vendors will be able to integrate data from their respective products.  Users will be able to view a simple interface and “see” the status of their network security.  While at first blush this may seem to be a giant leap forward and a truly helpful product, is it really all it is cracked up to be?  I think not.  Much like compliance checklists, a nice pie chart or bar graph can deceive users into thinking they are truly secure; but are they?  A deeper understanding of what these dashboards are truly quantifying or measuring is essential.  While almost everyone knows that the gauge in their car with the little gas pump icon tells how much gas is in the car’s tank, will every viewer of a “security dashboard” really know what information is being conveyed?  This especially applies to those not in the trenches but to those that make decisions about money, specifically, how much of it will be allocated to IT security projects.  Time and time again we see short sightedness because the minimum has been done and the enterprise is technically “in compliance.”  Why would we need to do more, the money dolers ask?  I fear that a fancy dashboard with nice colorful lights will only serve to delight a select few and cause further battles for those truly in the know.  

Focused too much on perimeter protection?

Security experts at the Government Technology Research Alliance Council meeting held this week in Pennsylvania discussed the challenges facing cybersecurity professionals in 2010.  You can read the article in Government Computer News here.  Too much focus on network-layer defenses seems to be a major problem plaguing the cybersecurity community.  Heavy reliance on signature based tools means reacting to only the known, while heuristic based tools rely on past experience.  With the emergence of new and more sophisticated attacks, these types of tools are often simply not enough.  Using more sophisticated cybersecurity tools in addition to signature and heuristic based options would go a long way towards greater IT security.  It's also important to remember that threats can originate internally and many sources will suggest that internal threats, while fewer in number, often have more catastrophic consequences than external threats.  Increasing utilization of tools that don't rely on signatures or heuristics, and do not differentiate between internal or external threats can help those in both the government and commercial space stay one step ahead of emerging and unknown threats whether internal or external.

Upper Management . . . . Are you Listening Now?

On Friday, July 24th., Network Solutions, LLC announced a large data breach of customer’s payment card information.  According to Network Solutions, ”it identified unauthorized code on servers supporting some of its ecommerce merchants’ websites.  After conducting an analysis with the assistance of outside experts, we determined that the unauthorized code may have been used to transfer data on certain transactions on approximately 4,343 of our more than 10,000 merchant websites to servers outside the company. On July 13, 2009, we were informed by our outside forensic experts that the data being transferred may have included credit card information. The code may have captured transaction data on approximately 573,928 cardholders.”  Network solutions has further stated that “assuring the security and reliability of our services to customers is our most important priority. We store credit card data in an encrypted manner and we are PCI compliant. Unfortunately, any company operating in our business could have become a victim of this type of invasion. In this situation, the unauthorized code appears to have transmitted information about credit card transactions as they were being completed; it did not involve a vulnerability in the way we store data in our systems.”

Anyone who processes payment cards should read and re-read the last paragraph.  Yes, any company who processes payment cards is vulnerable to this type of attack.  While Network Solutions asserts that they are PCI compliant, they do not specify if they were PCI compliant before, at the time of, or after the breach occurred.  Even if they were PCI compliant at the time of the breach, PCI compliance does not guarantee that malicious code will not be placed on a server.  Unfortunately, it does not seem as if anyone is getting the message that simply being compliant with any type of regulation is enough.  Compliance should be viewed as a bare minimum to protect IT systems and information.  While the costs associated with responding to breaches is high, the hit to the breached firm’s reputation is likely even more costly.

Management is still not realizing the potential liability that they face when IT systems are not secured well.  Certainly there are effective controls that can be put into place to greatly reduce or even eliminate the potential of malicious code being placed into a firm’s IT infrastructure.  These controls are almost certainly less expensive then the losses that are incurred by a firm when a breach occurs.  I believe that the problem lies in the fact that many C-level executives do not fully comprehend IT and the vital role that it plays in their business success or failure.  Given the relative recency of  IT playing a vital role in companies, it will take some time before business school curriculum catches up to the current realities that companies face.  It will also take time for grads with a firm grasp of the role IT plays in business to reach the upper management ranks.  Hopefully, in the meantime, with the rise of greater publicity and costs surrounding breaches,  IT will be able to get the attention of management with the message that compliance simply isn’t enough.

A Great Article on PCI Compliance-or Lack Thereof

I ran across this article in the Washington Post.  I think it sums up PCI compliance problems very succinctly.

Here is the link:

http://voices.washingtonpost.com/securityfix/2009/04/the_number_scale_and_sophistic.html