« December 2008 | Main | February 2009 »
This month's article entitled "Trust THIS" tackles Trusted Computing and the role it might play in corporate security today. There's a mini iPhone rant in there... and while I don't have one (yet), it certainly would irk me if I did.
Click here to read Trust THIS, or go see the whole repository of articles!
Evan Schuman of StorefrontBacktalk has a pretty shocking article today. Apparently, the Heartland malware hid in the unallocated file space.
Right on the heels of my last blog post too. Nuts.
Our forensic examiners at VeriSign look for this type of malware during every investigation because it is not a new trick. It surprises me that it was almost missed. Even still, I stand by my original premise which is that the standard (properly implemented) would prevent this. In order to get the malware on there, a software flaw or credential had to be exploited. Both of those vulnerabilities are addressed by PCI-DSS.
What is more troubling is the same noise that came out after the Hannaford breach last year. Bill Homa, their CIO at the time, first said that PCI was not hard enough (seriously?!? If it was harder, do you think there would be more adoption?), and that end to end encryption would have saved the day. On the surface, I disagree.
At this time, banks cannot process encrypted credit card data (PIN Debit may be the only exception). At some point during the many processes that occur in order for money to actually change hands as a result of a credit card transaction, the data must be decrypted. I'm not saying there are not opportunities to increase the security of payment data, or even take large areas of your network out of scope, but just saying that end-to-end encryption is the solution is irresponsible.
Let's take this example that is fictitious, but not so much so that I have not seen this in the field somewhere. Merchant A encrypts everything from the POS Controller to the back office processing. That leaves the POS Terminal to POS Controller link vulnerable, as well as the machine that does the processing to send transactions to the bank. You could not solely rely on encryption to protect you here, you would need to make sure the rest of the standard is properly enforced on those key machines.
Another example, where the POS Terminal to Controller link is encrypted, but nothing past that. It leaves the controller open to attack, especially if it has access to the internet (don't laugh... I have seen that on many occasions).
I understand minimizing the exposure of unencrypted card data, but even with malware combing through memory, that is not something that we should rely on (or that a developer should argue when you are conducting a PCI Assessment).
We should continue to pursue end-to-end encryption solutions because it will make life for Merchants a TON easier, and will boost the overall security inside the payment process. Remember though, if you take away one vulnerability, the bad guys will find another. I predict you will see an increase in the threats against the devices themselves. More skimming devices, and more fake ATMs/PEDs are coming. That's a management and training problem to fix (NOT a technology problem).
I stand by my original point. The standard, properly implemented, could have prevented a breach like this.
It's one week later. With limited public announcements, what is this post going to tell you? Well, let's start off by stating what it won't tell you. You won't find any gory details about the breach or the other parties involved. You won't find anything here that cannot be deduced using public information sources. You won't find anything here that has not been stated before.
So what use is it? How about we assemble some key points and do a little bit of analysis to understand how something like this can be prevented in your company.
According to the original press release, the investigation uncovered malicious software that compromised data that crossed Heartland's network. Before we start attacking PCI and saying that the standard should require encryption over any network, let's think about what the standard does today that would prevent that.
To start, PCI Requirement 5.1.1 states:
Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.
We don't know what kind of malware this is, so we don't know if there are signatures to detect it; however, there are many types of software that can detect malware without signature. White-listing software is particularly useful here, and properly managed could easily have thwarted this breach.
Next, let's have a look at PCI Requirement 6.1:
Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release.
Malware rarely finds its way onto a system that is fully patched. Exceptions would include a zero-day exploit, or someone that already had administrative credentials for the machine in question. Zero-day exploits for machines behind firewalls are not as probable as those in front of them (or workstation/desktop machines). Administrative credentials could be particularly crippling, but getting access to them can be tricky. You would not typically see those outside the corporate network, unless the attack targeted an individual or team inside of a company. Besides, we know that no default credentials should work because of PCI Requirement 2.1 (Always change vendor-supplied defaults before installing a system on the network).
OK... One more, and then I will stop (although you can keep going). PCI Requirement 11.5:
Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.
This one is the key. Malware cannot go undetected on systems that have proper file-integrity monitoring performed. Note I said PROPER, but let's face it. Even a BASH script that computes a SHA-1 hash on all the files in a particular tree will find malware when it compares those hashes to previous versions.
CEOs, keep reading. Your part is coming, but first I need to address the CISO that is screaming at me right now.
Yes Mr. CISO, you are well informed. A targeted attack can be pretty effective against the base controls I mention above. The reality is that targeted attacks don't happen (in the US anyway) as much as you might think because the basic security principles mentioned above are simply not being followed. Why would a criminal invest countless hours and money creating a targeted attack when generic malware works just as well?
Mr. CISO, you should not give up. You need to understand the risks in your environment, and that starts with strategic things like governance, and tactical things like mapping out data flows. This also means that when you are ready to ask for funding to address a risk, you don't tell the board that the world will end with EVERY SINGLE ITEM on your agenda. Pick something appropriate, and SELL IT.
I know, you hate salespeople. Face it, if you are going to be effective, you will become one.
Now, Mr. CEO. As the Chief chief, you are responsible for all the things that happen on your watch. If a data breach occurs, you can bet that your compensation will suffer, your employees will suffer (through layoffs and poor financial performance), and in some extreme cases you will find yourself reporting to outside legal counsel instead of the board (this happens more often than you think). I'm not saying you should throw all of the company's money toward security, but you should be taking it seriously. Make your CISO (or CIO... and if that is the case, go get a CISO) do his research and justify his position. When he does, you should listen.
What can we all learn? Going through the motions of something like PCI without actually committing to it will land you in the "PCI Validated, but Compromised" bucket like so many before you. The Anti-PCI crowd comes in two flavors, the "It's Too Damn Hard" flavor, and the "It's Doesn't Address X Issue" flavor. Both of those flavors have valid points, but they are sooo 2006. 2009 is the time to OWN your security, and PCI is a great place to start.
If you are shopping for the easiest pass, or looking for an assessor that will pass a halfway implemented control, you are asking for trouble. 2009 is yet another year to do more with less, but don't skimp on something like this. A good assessor will provide you with the concrete evidence you require to secure funding and fix problems you have been sitting on for years. It's time to take security and PCI seriously and get your program in place to maintain them every single day. Why? Because breaches put their victims at a competitive disadvantage to their peers, thus impacting their long-term outlook.
Need help on finding a place to start? Drop us a line! We can help!
We've got another one in the news. Heartland Payment Systems recently reported a breach that may have affected up to 100 million cards.
That's a lot.
Heartland joins another elite group of companies that suffered a breach, but was also validated as compliant by a QSA. I want to make something very clear in this next paragraph, but before I do, none of the comments here should be tied directly to any incident that has been in the news. We keep our customer lists private unless we get permission to use one as a reference.
There is a big misnomer out there that needs to be cleared up. I've even written about it before in this blog. In our investigations of PCI related breaches, we have NEVER concluded that an affected company was compliant at the time of a breach. PCI Assessments are point-in-time and many companies struggle with keeping it going every day.
Is there a problem with PCI? If there is one, the problem lies in the QSA community (or internal auditors that have not been through something like the CPISA training), not the standard itself. The new QA program aims to fix this, and time will tell if it hits the mark. The only snag I can see there is that virtually every question that is posed to the Council nowadays comes back with a standard answer that looks something like this:
The PCI Council empowers QSAs to make a determination if the stated controls meet the intent of the requirement. It's up to the QSA.
In some cases, this answer is warranted. I've heard of some of the questions they get. Things from "Does X technology meet Requirement 5 (usually from that technology vendor)" to questions that arguably look like free consulting. I do believe the Council has taken such a strong stance against making specific interpretation rulings that there will be room for a QSA to wiggle out of potential liability if they are remarkably good at paperwork.
So, to recap, our experience shows companies that suffer a breach are not compliant with the entire standard at the time of the breach. We should refrain from saying that another PCI Compliant company was breached because the facts show that it just is not true.
James DeLuccia IV noticed that Discover has officially matched their merchant levels to Visa (sorta). While this is a big step for Discover, I think most will find that they become Level 1 merchants of Visa before they become Level 1 merchants of Discover.
There are exceptions. Some merchants are exclusively Discover. Those merchants will have to double check their levels (if Discover has not already told them they are a Level 1) to see if they have new compliance requirements.
Greetings all! Join me for a Free Compliance Webcast put on by BrightTALK! I'm one of the featured speakers and will be discussing "Beating PCI in 2009!" You can review the agenda and register here: http://www.brighttalk.com/webcasts/2158/attend. You should also be able to look below this paragraph and log in and register there!
One thing about Botnets that scares me is the amount of idle computing power that is available to the owner of the Botnet. Suddenly, things that were once computationally infeasible with one machine become plausible or even possible with thousands of machines.
It seems like most Botnets churn out SPAM right now to the tune of trillions per day. SPAM may be profitable--the fraud generated by the SPAM anyway--but in light of recent attacks, I wonder if there are more enterprising methods.
If Botnet owners didn't happen to have 200 PS3s laying around for a research project on SSL, they could develop a program to break a large task down into work units, and have each bot on the net work on one of those units in the background (just like how SETI works). [Thanks BU!]
Even better, maybe it could be an interesting way to re-use those empty cycles. Business idea for someone. Develop a legitimate agent that can do that, and pay owners of computers some cash value for their cycles. Better yet, have that agent look for malware and alert and destroy it. Maybe the best yet is have it be part of an anti-virus program. Enrique Salem (SYMC), David DeWalt (MFE), or Mingjiang Chang (TYO:4704), there's a freebie for ya.
I'd be very interested to see what kind of illegal profits could be squeezed out of botnets outside of SPAM. SPAM is one thing that everyone hates, but maybe those guys could be more creative and find other ways to bring in cash?
Finance and Commerce Magazine published an article based on a survey revealing that most companies are unprepared for IT risks.
*blink*
What? You mean that with all the emphasis we put on it, and all the spending after some of the biggest breaches in history, we're still not ready? This is not coming from the consultant who sees this stuff every day, this is coming from people working for these unprepared companies.
With the economic situation as it is, will your own employees finally turn on you and take advantage of weak security controls in your network?
This may be an unpopular position, but while the risk is definitely much higher for insider threat, it doesn't seem to make the news as much as the external breaches do. Maybe it is because most of the employees that are in a position to take advantage of something like that have too much to lose by committing such a crime.
This blogger is not sure.
Maybe things will get nasty for those companies who have ignored good security with employees facing the threat of an imminent layoff or being financially overextended. I would suggest there is a better chance of a hacker using an employee to exploit these poor controls, probably without them knowing it is happening.
Be it through phishing, social engineering, or just the right place at the right time, appropriate motivation may end up costing companies and their customers big dollars in 2009.
