The MasterCard Hokey Pokey

Earlier this year, MasterCard issued a somewhat radical change for their SDP program stating that Level 2 Merchants had to have an onsite assessment by a QSA by the end of 2010 as stated here:

http://www.mastercard.com/us/merchant/pdf/SDP_Program_Revisions.pdf

However, this hokey pokey move put the Level 2 Merchants "in" the same boat as Level 1 merchants significantly upped the ante. First of all, it would certainly mean an increased cost for their PCI program by requiring an audit. But more importantly, many of these merchants would no longer be able to just claim they are following PCI via an SAQ form but would now have to prove it to an auditor. That really was the alarming part.

Needless to say, MasterCard got a lot of complaints from merchants and even banks. So, they did the hokey pokey and put their Level 2 Merchants back "out" - at least partly. Now they have moved the date back to mid 2011 and they have conceded that the SAQ can still be done, only now the company must send an employee to training before that employee can perform the SAQ.

http://www.mastercard.com/us/sdp/merchants/merchant_levels.html

On a positive note, this was a wake up call for Level 2 Merchants to enforce the understanding that no matter what size they are, compliance is really to the PCI DSS in full - not just filling out a form.

As far as the banks, who really need to absorb these positions and communicate them back to the merchants, we are still waiting to see how they consistently position this. For example, will the person trained also have to sign the SAQ? Are they liable for a breach? Will the annual test be the same as the QSA? Do they need to have cyber liability insurance like a QSAC needs to? How will there be enough training sessions to cover all the Level 2 Merchants?

Ultimately, this still leaves the merchants with the decision of whether it's more valuable to pay someone internally to go to training or engage a QSA to perform an onsite assessment. The burden to be compliant is the same, but clearly a QSA has more experience. Given the number of breaches that still occur, one would hope that merchants want their program evaluated with the most due diligence.

Read more!

MS08-067 Strikes Again

Firewalls, anti-virus, and intrusion detection systems can protect you from many things threatening you information security. What about your employees? Can they be easily locked down? The quick answer is no. The human element is the weakest link, and the following story is no exception.

While performing a social engineering attack, we were given a list of users to impersonate. The goal was to retrieve passwords verbally for either email or a website. On the site, I noticed that if your account was locked you could get a PIN from IT to unlock it.

I placed a call to the IT department using a spoofed number and made sure the IT person, we'll call him Joe, knew I was pressed for time. I told him I needed a PIN because my account was locked and he asked me for my name first. The person I was impersonating had a difficult name to spell, but I attempted to spell it for him and made a little joke about how difficult the name was to spell. Joe chuckled a bit and said he could send the PIN to my voicemail.

I told Joe I was calling from my mobile phone and didn't have access to my voicemail at the moment. I reminded him that I really needed to get my PIN quickly so I could log-in and asked what my options were. Joe said that if I verified the employee number he could give the PIN to me over the phone. I told him I would have to look for it and to hold for a minute.

After thinking about what to do next, I figured all was lost. So I decided to have a little bit of fun first. After about a minute, I picked the call back up and said, "Okay, I got it. It is MS08-067."

There was a brief pause and Joe said, "Your new password is _____."

I was stunned and I didn't think he was being serious until I logged in successfully. I told him thank you and how much I appreciated his help. From there, I continued accessing everything that I could log-in to and retrieved corporate email, social security numbers, pay rates, and gained access to the employee database. While Joe probably felt pretty good about helping me, I was helping myself to all of his co-workers' and corporate information.

Experience teaches us that it is human nature to want to help someone in need. We all aspire to be a hero of sorts. It may be just helping out that person on the phone, or holding a door open for someone with their hands full. Just keep in mind that while your intentions may be good, theirs may not be.

Education is very important. Teach your employees it is okay to question others. People who believe that they can't be social engineered most likely have already fallen to victim to it.

How do YOU protect yourself?

By Chris Murrey

Read more!

Are Your Applications PA-DSS Compliant?

The PA-DSS deadline is closer than you may realize and there is bound to be a mad-rush at the end. July 2010 is the deadline for Phase 5 of Visa’s “Payment Application Security Mandates”. By that date, Visa is requiring that acquirers certify that all their merchants and processors are using PA-DSS certified payment applications. Did you get that? Stop, backup, read it again. If you are using a purchased payment application (those that are sold, distributed or licensed to third parties), it better be on the PA-DSS list.

PA-DSS is nothing new. It was introduced in 2007 as the successor to Visa’s Payment Application Best Practices (PAPB), which is intended to help software vendors and others develop secure payment applications, which could include anything from a POS system to online shopping cart software. PA-DSS requires that payment application be assessed by a 3rd-party, pass a series of security tests, and adhere to leading-practices before it can be distributed. If it fails any part of the assessment, it cannot be used as a payment application.

What does this deadline mean? First, it means that merchants’ time of using anything but compliant payment applications is nearing an end. Second, any new merchant applying for a merchant account will have to, as one of the steps to getting the account, show the acquirer, that they are using a PA-DSS certified payment application.

It's unclear how hard of a stance the payment brands are going to take on non PA-DSS or PCI compliant payment applications. If they go the full mile, they could shut down any organization whose credit card processing isn't compliant. They could also hand down some major fines for non-compliance. No one really seems to know what those fines are, but obviously if credit card data is compromised while you are non-PCI compliant, you could be subject to hefty fines. With the ability to accept credit cards at stake, trusting non-compliant applications hardly seems like a risk worth taking.

July will be here quicker than you might realize. Are you ready? It's quiet in here... can you hear the echo?

Read more!

Securing a PCI compliant vendor

Seven restaurants are suing Radiant Systems and Computer World for producing and selling insecure systems that led to security breaches, which then led to fines and other costs for the breached companies.

The restaurants claim that they were sold a product that was not PCI compliant, and the two vendors should be held responsible for the data lost and the money spent as a result of the breach.

Radiant Systems is a point of sale terminal company and Computer World is the company that sold and maintained the Radiant Systems product. The question is, should the vendors or the restaurants be held responsible for the data breach? After reading a blog that left the matter undetermined, it was necessary to clear up the confusion.

First off, a ROC or SAQ from the restaurants must have signed off on the product. As a certified QSA, the first thing we would do is check the PCI list to ensure that the product is listed. The point of sale system is certified by version. While version 1.0 of the product may be certified, 1.5 may not be. The restaurants should have spent the time and money to determine that the vendors and the products purchased would be keeping their company data secure, and they clearly did not.

Anyone can say they are PCI compliant. It's a very lucrative business right now, and many people are falsely claiming compliance to make money. As a business who is interested in hiring a vendor to provide or implement a product, it is your responsibility to research the vendor and choose the best product. Ultimately, the fault falls upon the breached restaurants.

An easy way to prevent situations like this in your company:

• Look at the PCI list. PCI provides an Approved Service Provider list that includes products, product versions and the codes used. Before bringing in any vendor to your company, check the list to be sure their product is PCI compliant.

Read more!

iPhone App Developer Sued for User Phone Number Theft

As the saying goes, it’s not IF, but WHEN will your personal information will be stolen in a data breach.

On October 8, 2009 I wrote a blog entitled “What’s the Value of Your Mobile Phone’s Address Book?” which highlighted the fact that iPhone applications have access to your phones entire address book and you are trusting that the developer is (hopefully) not a rogue one. This has been known since at least January 26, 2009. The possible abuse that my blog was aimed at pointing out to readers came to light recently. A class action lawsuit has been filed against app developer Storm8 and the full details of the proceedings can be found here.

Read more!

Is Your Response Time Less Than 120 Days?

I recently read a blog about ChoicePoint and the ongoing coverage of their business, especially after 13,750 people had their personal information compromised. Tina Stow, who seems to represent ChoicePoint, left a comment on the blog stating:

“We have several monitoring tools and the one in question was not intentionally switched off. Due to human error for which the Company took appropriate action, one of our monitoring tools was temporarily and mistakenly turned off for a four month period. The other monitoring tools and our information security program were working. We have added redundancies to try to prevent future human error.”

4 months?!!? Holy cow! If a “monitoring tool” is unintentionally switched off for 1/3 of an ENTIRE YEAR and no one notices, I wonder what else has been going on that went unnoticed. No wonder they had a breach! That statement reminds me of clients that never see brute force attacks on their systems simply because they never review logs. Whatever the reason that the said system was not discovered to be down or malfunctioning, a core deficiency exists within the system and/or process(es) surrounding it; or the statement presented simply lacks validity.

With that being said, you can buy the latest, greatest, or most expensive tools, systems, and software out there, but unless installed, configured, and used in a correct or proper manner, do you little to no good. It’s like putting in a web application firewall without having it “learn” your web application, or dropping in a firewall with any/any rules in place; it will only get you so far. Unfortunately, it may have earned a “checkmark” or opportunity to issue a press release saying “we did something”.

Read more!

To Pen Test or not to Pen Test, that is the question…

Time and time again I am challenged by clients and security professionals alike on what is the real benefit of penetration testing. Though this seems like an age old debate with many famous hackers and security professionals weighing in, I am not entirely sure I understand the argument undermining the importance/benefits of penetration testing. Below are arguments from both black and white hat security professionals:

White Hat – “Pen testing can show one of two things: your security sucks or your security is better than your pen tester”

Black Hat– “The very concept of "penetration testing" is fundamentally flawed. The problem with it is that the penetration tester has a limited set of targets they're allowed to attack, while a real attacker can attack anything in order to gain access to the site/box. So if a site on a shared host is being tested, just because site1.com is "secure" that does NOT in any way mean that the server is secure, because site2.com could easily be vulnerable to all sorts of simple attacks. The time constraint is another problem. A professional pentester with a week or two to spend on a client's network may or may not get into everything. A real dedicated hacker making the slog who spends a month of eight hour days WILL get into anything they target. You're lucky if it even takes him that long, really.”

Though I understand the point of the above arguments, I believe the logic behind these statements is fundamentally flawed. The point they are trying to make is that an organization is never going to be entirely secure and that an attacker with dedicated time and resources WILL in all cases break in, so performing a pen test is only validating something already known. I see penetration testing differently. Penetration testing is not designed to make an organization 100 percent secure but to make them MORE secure (assuming identified vulnerabilities are remediated) and MORE aware what they were before the penetration assessment was performed. It also is a good means to test current logical and physical security controls. From my experience, many security professionals responsible for an organization’s security do not understand the full ramifications of vulnerabilities and thus can become complacent in fixing them.

Case Study:


A vulnerability scanner returns one vulnerability on Company A’s external presence. The vulnerability identified was Cross Site Scripting or SQL Injection. A report is issued to Company A showing a “High” risk rating based on this vulnerability. Company A may not understand how a single vulnerability can translate into a “High” risk rating and thus chooses to ignore or at least delay remediating this vulnerability until time and resources become available. Does this mean Company A’s security is bad? I would say if that if Company A had an external presence of 50 servers and 10 applications, and only one vulnerability was identified, the answer would be no. Company A may very well have good security, but as with everything else in life, mistakes happen. Now let’s assume a penetration assessment was performed on Company A’s external presence instead. Not only would the penetration assessment identify this vulnerability, it would attempt to exploit it. Let’s go on to say that this vulnerability is in fact exploitable and allows for full system compromise. What is a client going to react to more? A report stating they have one critical vulnerability stating what could happen or a report stating they have one critical vulnerability and, oh yeah, by the way we compromised your entire domain controller? A client who just had their entire domain controller compromised is going to be more inclined to fix the vulnerability in a timely manner than one reading a report stating what could happen if not fixed.

How can one argue that this penetration assessment was not beneficial to Company A? It effectively made Company A more aware as to the dangers associated with a critical vulnerability, which in turn made them take a proactive approach to fixing the problem almost instantaneously, thus reducing their overall risk rating.

This is one simple example. I can go on and on about the benefits of penetration testing. Security is about managing and reducing risk to an acceptable level. A penetration assessment isn’t intended to reduce an organizations risk to zero percent, but then again neither is any security assessment. Any time an organization connects a device to a network it assumes a certain amount of risk. It’s understood that zero-day vulnerabilities will always surface and cannot be prevented. So sure, a dedicated attacker could decide to spend 6 months developing an exploit for an unknown vulnerability, however this is going to take a more sophisticated attacker which makes this a less likely scenario.

A penetration assessment is simply used as a means to identify vulnerabilities and provide proof of concept examples on exploiting these vulnerabilities. By doing so, it effectively better explains ratings associated with vulnerabilities which in turn produce much more conscious/aware security professionals. A much more aware security department will be able to better help reduce the overall risk for an organization.

Read more!