IBM Security Services PCI Blog
Andi Baritchi 27000216AA email@example.com Tags:  security flow analysis mapping data 781 Visits
Install and lock down firewalls. Change your passwords. Encrypt this. Encrypt that. Secure it all ad nauseam. And you're done. Right?
Well, not so much...
It takes a thorough understanding of how something works in order to fix it. In the case of security, that means understanding what it is you're trying to secure. The more experienced the security professional (or should I say jaded? ), the more likely you are to see him or her perform a data flow mapping as step zero of any infosec project. This exercise isn't just about plotting data points - you're performing a business process analysis and documenting how the business functions. You just happen to be focusing on how the data is stored, transmitted, secured, etc. in the process.
This is a prereq for any PCI security assessment, but it applies to all the other kinds of sensitive data. Does your business deal with SSNs? Protected Health Information? ITAR data? Or is perhaps your own corporate data of value to you?
If so - can you confidently say you know all the places you're currently storing, transmitting, processing, or otherwise touching ___-data? Can you identify all the security measures in place?
Andi Baritchi 27000216AA firstname.lastname@example.org Tags:  virus trojan lawsuit pdf malware compliance heartland merrick qsa 2009 virtualization recession security computing pci year savvis review cloud new 1,489 Visits
Wow . Another one's gone by. 2009 felt like a flying lap around the Nürburgring. The ups. The downs. The slip angles. And ah yes, the opposite lock.
So... Let's take a look at look at the top events and trends that helped shape the year from a PCI perspective:
Best of luck to everybody in the new year and have a happy, successful 2010!
¡Felíz año nuevo! La mulţi ani!
Andi Baritchi 27000216AA email@example.com Tags:  security website compliance ibm solutions pci iss 1,155 Visits
Andi Baritchi 27000216AA firstname.lastname@example.org Tags:  pci security business compliance roi 922 Visits
IBM whitepaper hot off the presses: The Return on Investment of PCI DSS Compliance (PDF).
Andi Baritchi 27000216AA email@example.com Tags:  cardholder risk compliance security lawsuit breach pci 1,611 Visits
Co-written by Andi Baritchi and David Mundhenk
The recent news that Merrick Bank is suing Savvis for negligence regarding the CardSystems compromise back in 2004 is creating quite a buzz on security blogs and other sites across the web. Merrick Bank is alleging that Savvis was negligent when conducting a CISP audit (a contributing predecessor to PCI DSS assessment) for CardSystems, that this negligence led to a serious breach of credit card information, and ultimately to related large scale liabilities and costs that Merrick Bank incurred. They are seeking compensation for these costs, to the tune of $16 million.
This news is polarizing the security blogosphere. The popular “buzz” over the announcement is that this is supposedly a wake-up call for the industry, especially if Merrick ultimately proves that Savvis was indeed negligent. The mounting anxiety over this is creating a scenario whereby all those who have complained about the pitfalls and complexities and costs of compliance, in a figurative sense, are now lining up with a big stick in hand ready to flail away at the PCI compliance piñata. They are ready to vent their collective pent-up frustrations by disparaging and dismissing the PCI compliance process, and especially the QSAs who perform these assessments. (Note they are now called assessments by the PCI SSC, not audits). They do so hoping the figurative “spoils” that might spill from the busted PCI piñata will include relaxed compliance requirements and reduced fines and penalties for non-compliance.
The PCI SSC has gone to great lengths to write a unified security standard to help protect the cardholder information (CHI) for the founding member card brand customers. It has developed a fairly rigorous training and certification program for those who perform PCI DSS compliance assessments. Only certified companies with certified Qualified Security Assessor (QSA) personnel can perform such work. In addition, there are Quality Assurance steps in place to help identify and restrict those QSAs that do not, or cannot perform to minimum levels of professional competency. There are also stipulations that companies who perform this work must not only recommend their own products for solutions. That having been said, no standard is perfect, nor are companies or people. There can be instances where mistakes are made. It is also quite possible that there are some bad apples involved in this business who have somehow circumvented the checks and balances designed to establish and maintain a minimum level of professional competency. But this is why the Council has its QA process.
The PCI DSS at a rudimentary level can be compared to Information Security 101, but it goes much deeper than that. Much like the more mature audit frameworks in the financial sector, the goal of PCI is to protect sensitive private information – and in doing so install a level of transparency into enterprise information security, reduce fraud, reduce risk, and increase confidence. PCI isn’t perfect, and its biggest weakness is its reliance on the integrity of the business being assessed. It is, however, the strongest driver for information security in the business world we’ve seen to date. Thus far PCI and its predecessors have identified and helped mitigate a staggering amount of risk to CHI due to insecure systems and business processes.
While there has been an impressive improvement in the overall protections afforded by all of these Infosec standards both individually in a collectively, there is still no guarantee that systems assessed for compliance are completely secured against compromise or misuse. There are no guarantees with this, just as there are no guarantees in business. A significant component of managing businesses and organizations involves managing all risk to corporate assets. And even if all reasonable and cost effective protections are in place, stuff can still happen. In addition it is important to understand that all IT environments, including those that process credit card payments are highly dynamic environments. An audit or an assessment of such an environment takes place over a finite time period. It represents a “snapshot” in time at the time of the assessment. The assessor attests to the overall compliance of a given environment during that time period, and then provides a reference date for making that assertion. If a compliant business or organization induces any change to that environment after the fact, there are no guarantees that the environment is still compliant.
What does this all mean when it comes to the Merrick Bank lawsuit against Savvis? Merrick has a large burden of proof ahead. They have to prove that (a) Savvis was negligent and that the alleged noncompliance was there at the time of the CISP audit, meaning their Report On Compliance (ROC) was false, (b) the breach would not have occurred had they been compliant, and (c) this is their biggest hurdle: they have to prove that Savvis is somehow liable for Merrick’s damages even though Savvis had no business relationship with Merrick Bank (Savvis was hired by CardSystems, not Merrick). Whichever way the lawsuit goes (with today’s legal system I’d rather go to Vegas than call that one), the real lesson here is to be damn sure all requirements are met before professionally attesting to security related organizational compliance.
There is one key to
understanding PCI compliance (or any compliance program for that
matter) – there is no ‘silver bullet’ solution. There are vendors that
will try to sell you solutions that will guarantee 100% hackproof
security with full compliance, however the truth is that such a thing
doesn’t exist. It’s a panacea to think otherwise. Security is all
about risk management, and the bad guys tend to be pretty skilled and
resourceful. Not only that, they only have to be “right” just one time.
As a merchant or service provider pursuing PCI compliance, the goal
shouldn’t be to achieve it and then put a “safe from hackers!” sticker
on your website. Doing so or anything like it will only increases
possible risk. The end goal is to determine your business’ risk tolerance, and bring your risk tolerance profile to acceptable levels.
Similar decisions are made when determining “should I become compliant
with PCI or just pay the costs of noncompliance?” Same risk management
model as the one you use every day deciding whether to speed on the
freeway, except PCI compliance actually makes sense.
Look for our new IBM ISS white paper on the ROI from PCI Compliance, coming to this blog soon.
Anybody want to start a pool on how long it takes before we start seeing longer PIN numbers?
It won't help at all with the cases where they're stolen at the source, but it would certainly cut off brute forcing and shoulder surfing dramatically.
Andi Baritchi 27000216AA firstname.lastname@example.org Tags:  breaches middleware security webinar pci 577 Visits
Got middleware above your databases? You won't want to miss this webinar:
Middleware Security Holes You Need to Know About
With T.Rob Wyatt, Senior Managing Consultant at IBM
April 15th at 12 Noon ET / 9 am PT
Andi Baritchi 27000216AA email@example.com Tags:  card compliance dss security credit iss cardholder pci 2 Comments 894 Visits
In today’s challenging economic landscape, clients in every vertical are looking harder than ever to lower costs and maximize ROI. It’s a delicate balancing act between tactical and strategic – one we often see left unbalanced.
In order to be successful, a security program must be:
All cost centers, including security and compliance, have been made prime targets for CFOs’ slash hunts. The most common mistake we’ve observed in such times is to shift security and compliance to a tactical-only paradigm. This shift may save costs in the short term, but chops ROI at the knees in the long run.
For example, building a security program for your organization wholly around PCI DSS compliance is a sexy, but fallacious idea. A security program built on top of the DSS is totally dependent on the Standard – you’ll have to re-think your security strategy every time the PCI Security Council issues an update (and/or clarification). Same goes for any other reg.
Before you ask us the question, I don’t have the budget to get an A in security – I just need a C in compliance, consider the consequences of building a security program that hyperfocuses on compliance.
To contrast, say you implement a sound security framework that, as one of its core dimensions, addresses cardholder data security and PCI DSS compliance. Other dimensions may address your company’s other regulatory, security, and privacy vectors – such as SOX404 compliance, web 2.0 threats, and so on. All the elements of this comprehensive security framework, if designed properly, will work together to keep your and your customers’ data secure. Compliance will just be a natural byproduct.
As a final thought, remember that any standard, whether it’s religious, regulatory, or simply an internal rule, can only be effective once all stakeholders understand and adopt it both in spirit and in function.