A Lesson Learned from Global Payments

Stories like the recently announced breach of security by Visa partner and mammoth online payments processor Global Payments happen with alarming regularity. In brief, Global Payments said it “identified and self-reported unauthorized access into a portion of its processing system. In early March 2012, the company determined card data may have been accessed.”

For a full report, see here

What we know is that the company experienced unauthorized access into a portion of its processing system that may have exposed payment card information and other consumer personal details. Reports say that over 1.5 million credit and debit cards may have been affected.

I don’t want to spend the time on this blog excoriating this organization although I know they will surely take their lumps from their customers, the media and consumers at large. In fact, just today, Visa kicked them to the curb.

What I do want to focus on is the fact that even the largest and potentially most secure organizations have security holes; ones small enough for any enterprising criminal or corporate anarchist to take advantage. Yes the breach was detected, and yes the breach was contained, but the damage is done. Not only to the victims whose data was left exposed …but to the confidence that the company can do the one thing it is truly asked to do—keep transaction records and information secure. It would be easy to blame GP for being asleep at the wheel, but without knowing more about the particulars, it is safe to say, they should have done more to protect their data rather than congratulate themselves on how they recognized and closed the breach…after the cows have left the barn.

Again it would be presumptuous for me to say if they did A, B, or C that this issue could have been avoided, however how does a company filter through all the white noise for every log and every event to determine that one instance is the instance you must detect, alert and prevent. Companies like GP need to process millions, perhaps even trillions of pieces of data every day, and every single one needs to be cleared. I’m sure companies as large as GP have state of the art SIEM and log management systems, but even the best of products fail if not properly monitored or prepared to engage the latest threats. What GP failed to do is recognized this event as a threat to its security.

This is one of the greatest benefits of managing SIEM or log management from the cloud. It easily manages the same functions as any on premise set-up (and in many cases, out performs them), but through the automations, live monitoring and updating by experts, reporting and through the complex correlation and alert matrices, the white noise is significantly reduced to manageable actions and prevention strategies. And because it takes care of a vast majority of the work performed (and in way too many cases left unmonitored due to budget and workload constraints) by staff analysts CIOs and Security Directors can now redeploy personnel resources more judiciously to directly combat the kind of issues experienced by Global Payments. What the cloud (security-as-a-service) provides is a new flexibility that shares threat intelligence across its platform and quickly isolates malicious or compromised hosts. This goes well beyond the latest Trojan virus, but is a new way to protect an entire organization through enterprise-class security solutions.

If you consider that it is not an army that is coming to storm your gates, but a quiet cyber-ninja looking for the smallest crack in your wall, it is easy to hide amongst the volumes and volumes of information getting processed. If we can learn a lesson from the Global Payments disaster, it is about how best to allocate resources to find and neutralize intrusions. But not all intrusions are created equal. If you are able to properly correlate, automate and filter all the events, you will be able to spot and prevent potential threats, isolate and analyze them and launch a plan of action against them…and not after the damage has been done.

by Kevin Nikkhoo
http://www.cloudaccess.com