Branden Williams' Security Convergence Blog

Please join me on July 7 for an informative webcast on Maintaining PCI Compliance! To register or attend, please go to: http://www.brighttalk.com/webcasts/4431/attend.

Now that Level I merchants have undergone a few annual Payment Card Industry (PCI) assessments (and Level 2 merchants are soon to be doing the same), they are addressing the realization that a mature, sustainable compliance program requires more than once-a-year rallying to prepare for, participate in, and pass an assessment. Daily operational focus and ongoing effort are vital to protect investments in compliance, manage risk, and minimize the business disruptions and costs associated with achieving and demonstrating compliance year after year. This presentation discusses best practices for building a compliance program that can be supported and maintained year-round while also alleviating the burden on IT staff. When implemented effectively, the practices can help your company mitigate risk, reduce costs, and boost confidence in compliance by developing a cohesive plan for ongoing PCI assessment, maintenance, and refinement.

Posted by Branden Williams at 12:43 PM | Permalink | Comments (0)

The following is a guest post by Fred Langston, Sr. Product Manager for VeriSign's Global Security Consulting group.

With the stampede to the next big thing gaining speed, Cloud Computing and Cloud Services face the standard, yet utterly preventable, horse-before-the-cart security conundrum. Anytime paradigm-shifting technology that saves money and decreases operational costs hits the market, two things are certain - 1) your company, just like 99% of the other companies in your vertical, will be running with the pack straight towards rapid adoption, and 2) security tools, techniques, and control technologies to find and mitigate the huge business risks associated with the new cloud services are:

• Lacking in essential functionality, scalability, or cloud-wide scope
• Not based on well-vetted best practice policies or standards specific to each particular cloud environment (because none exist yet!)
• Not able to provide the same level of visibility and granularity in security controls your company currently employs in their non-cloud, non-virtualized IT environments

Most likely, little (if any) thought has been given by the business about exactly what your company's security requirements are for most cloud computing projects other than, "Our Cloud Services provider has assured us that..."

So, what are the InfoSec troops, fighting in the trenches, able to do to create the most secure use of Cloud Services possible, other than losing sleep? Well, anyone that knows me knows I'll spout a best practice solution for everything under the sun given a sliver of an opening. It's my nature. But, not here.

Cloud services seem to me to impose on us a devilishly more complicated, already barely tenable enterprise security tableau that we must design, implement, and operate in perpetuity. Like security's not already hard enough or not already too expensive for management. Should we just resign ourselves to the fact that essentially we can no longer provide the security we expect for those outsourced cloud services, that it's Contract's and Legal's and Audit's problem now and not ours? Or, do we demand the right to dig? To dig deep into the cloud service provider's...well, everything?

Why would we not hold a Cloud Services vendor, who's running their security infrastructure in a very similar if not identical manner as a Managed Security Services Provider (MSSP), to the same standards of service that we demand of every MSSP in the space? How logical is that? If they really are protecting the systems, networks, and data to the level they promise to contractually, why would they not have the same set of data ready to share with us about security operations in 'our cloud'? Only the Cloud provider can provide this information and that makes them an MSSP for the Cloud as well, by default. They have the firewall logs, IDS/IPS alerts, configuration data and the like for our cloud.

So, as an MSSP, I have to ask, "Where's my daily aggregated alerts, change control logs, Firewall Rule changes etc, etc?" Seems to be a double standard we really can't continue to live with if we plan on holding the line against the 'bad guys'.

Posted by Branden Williams at 6:17 AM | Permalink | Comments (0)

The Merchant Maven posted a release about Merchant Warehouse's new Blackberry version of MerchantWARE, following in the footsteps of the apparently successful iPhone application. This new trend is yet another example of a need for good moble payment security.

While the software company states that the application complies with both PCI DSS and PABP, it is not listed on the official Validated Payment Application list as either validated under PABP or PA-DSS. That only means that they have not had an assessment performed and paid the required fees to get it listed on the site.

Acquirers are wary of Point of Sale (POS) vendors and POS implementers, all because of a few bad apples. The restaurateur is at a particular disadvantage. A high failure rate and a desire to carry a small amount of debt when opening a restaurant (see high failure rate) causes some of the same equipment to be used in multiple locations throughout its usable lifespan. Not just tables, chairs, and griddles, but POS terminals as well. This means that some of the same vulnerable equipment keeps surfacing because proprietors simply don't know they need to upgrade.

The card brands, specifically Visa, have invested heavily to fix this. First, by starting the Payment Applicaiton Best Practices program (now the Payment Application Data Security Standard), and later by imposing certain payment application mandates on new (and soon to be existing) merchants.

Merchant education is getting better, but you will do yourself a favor by ensuring that any third party POS applications you rely on for your business are listed on the Validated PA-DSS applications, and be sure that you keep up with the patches associated with that version.

Posted by Branden Williams at 6:01 AM | Permalink | Comments (0)

If so, go find the VeriSign booth, and ask for Rob Harvey. He is challenging attendees to a game of Blackjack! Beat Rob, and you win!

Posted by Branden Williams at 8:00 AM | Permalink | Comments (0)

It's been a little over a week now since MasterCard tool the PCI world by surprise and changed their reporting requirements for Level 2 merchants. Whether you are currently a Level 1 or Level 2 merchant, these changes affect you. Here's the summary and rundown.

MasterCard posted a change to their Site Data Protection program that requires Level 2 merchants to use a QSA and perform an on-site assessment before December 31, 2010. In addition, Level 1 merchants that were previously self-assessing may not self assess anymore, and must use a QSA for their PCI Assessments. This is a dramatic change from the current, industry wide requirement of self-assessing for merchants processing less than six million transactions annually, and allowing merchants that process more than six million transactions annually self assess if they choose.

So far, none of the other card brands have changed their status; however, if you have a business unit defined as a Level 2 merchant with any card brand, you are automatically a Level 2 with MasterCard and are now required to have an on-site assessment. Below are a few clarifying points around the change to the levels from an inside source.

1. Level 1 and 2 merchants MAY NOT self assess anymore. They must use the services of a QSA to complete their assessment (still awaiting final confirmation on this).


2. Level 2 merchants must be validated by a QSA prior to December 31, 2010, as well as maintain their current processof submitting a Self Assessment Questionnaire (SAQ). MasterCard's intent is to use the next eighteen months as a transition period (VeriSign can provide both deliverables for you at the same time).
   With this short timeline, VeriSign (and MasterCard) recommends that Level 2 merchants have readiness assessments performed immediately to prepare them for any remediation required to be completed before the on-site assessment in 2010.


3. The on-site assessment must yield a Report on Compliance (ROC), NOT an SAQ. Effectively, Level 1 & 2 merchants will have the exact same reporting requirements for PCI.


4. This does not only apply to merchants processing more than one million MasterCard transactions annually; this applies to any merchant classified as a Level 2 merchant from any other card brand. MasterCard defines that their Level 2 also includes "Any merchant meeting the Level 2 criteria of a competing payment brand." This means that if any other brand defines you as a Level 2 merchant, you are now subject to this requirement. For example, did you know that according to these rules anyone processing more than 50,000 American Express Card transactions per year is now subject to this requirement?

Parts of this may not be as relevant to some Level 1 merchants, after Visa clarified their expectations of what makes up a Level 1 merchant earlier this year. If you are a Level 1 merchant in one country or region, and are also a merchant of a lesser level elsewhere in the world but share data with (or are connected to) the Level 1 merchant operations, all operations should be treated as a Level 1 and reported that way.

For example, Garrett's Gas Guzzling Garage operates 800 car repair locations across the United States. Garrett's recently opened twenty locations in Mexico City to help maintain and upgrade the fuel efficiency of older cars with a patented fuel particalizer. Even though the twenty Mexico locations process through Bancomer locally, the data is shared with the US Headquarters for settlement, reconciliation, and analysis. According to Visa's rules, the Mexican entity is considered a Level 1 based on its relationship with the parent, and a Level 1 assessment must be performed.

When in doubt, always ask your acquirer(s) what is expected of you. Some acquiring institutions may still treat certain subsidiaries as lower levels depending on the circumstances.

Regardless, your PCI Team is ready to assist you with any new PCI needs that you may have! Click here to email us to get in touch with one of our seasoned QSA consultants!

Posted by Branden Williams at 5:15 AM | Permalink | Comments (0)

Don't write Savvis off yet! Dave Navetta posted an update to the Merrick v. Savvis case that every QSA is closely watching. Savvis filed a motion to dismiss in response to the lawsuit.

I'm not a lawyer, but I'm glad David is. He explains the reasoning, and even mentions that Merrick's potential procedural error (or end-around) could get this case dismissed before the substantive merits of the case can be explored, thus continuing to leave the world in the dark about more potential liabilities involved with performing PCI Assessments.

Go check it out!

Posted by Branden Williams at 6:20 AM | Permalink | Comments (0)

Javelin Strategy & Research posted an update to the new MasterCard Requirements. After speaking with John Verdeschi, Robert Vamosi pointed out an error in our initial analysis. After re-reading my material, I looked at one piece of information and made a leap (incorrectly) about the intent.

John clarified that the intent is to use the next eighteen months as a transition period. Level 2 merchants should both submit a SAQ, and also have an On-Site assessment completed so they can submit a Report on Compliance by December 31, 2010.

This means that Level 2 Merchants effectively have eighteen months to complete a readiness assessment, remediate, and validate compliance.

Sorry for the confusion folks, and thank you to Robert & John for setting us straight!

VeriSign is sending a consolidated information briefing on this update with some special discounts on our consulting services for Level 2 Merchants. If you don't get your copy of this alert by Friday, please email me so that you have the information needed to get the discount!

Posted by Branden Williams at 6:48 AM | Permalink | Comments (0)

You've probably heard about it by now. Thanks to a friend doing business in Nevada, I was alerted to this new law last week. Nevada is now the second state to enact laws requiring companies to comply with PCI (though, arguably, the Massachusetts Identity Theft Prevention Regulations seemed to have been lifted at a high level from PCI), the first being Minnesota.

David Navetta has a great analysis from a legal perspective, and Chris Mark published his thoughts as well. One thing that is interesting about the Nevada law is an apparent Safe Harbor provision.

Will this added pressure force more religious views on payment security and compliance inside companies? Or will companies continue to roll the dice with their compliance?

You decide!

Posted by Branden Williams at 5:07 AM | Permalink | Comments (0)

A couple of weeks ago, I jotted down a few thoughts on the letter from the NRF to the PCI-SSC about the PCI Standards. My post was a bit rant-ish, but Anton Chuvakin threw down a great review in his blog yesterday.

The only point that I wanted to add a different opinion on is the use of WEP.

I've been a proponent for wide open wireless networks in corporations for a few years. I argue that because network compromises are either hit-or-miss with advanced encryption technologies, most hackers default to attacking hosts instead. One of our own testers is known to breach networks that security professionals thought were virtually impenetrable. He didn't do it by packing a Cray into his car. He just set up a louder, fake access point that caused a laptop to associate with him, then launched an attack against that laptop.

Instead of trying to protect the network, why not assume that wireless networks are the equivalent of a user operating from home, and make that user interface with it in that manner? Sure, you can cut down on the noise by doing some basic filtering of MAC addresses, or even a basic WEP key. But inside that setup, run VPNs with firewalls on the endpoints (BOTH sides) to connect the machine to the network. Treat a user sitting in your office using wireless as a remote user, and treat your wireless network the same way you would the internet.

From a handheld device perspective (like the ones often found in retail), things get complicated. Almost to the point that it is virtually impossible to continue their use without upgrading them to WPA/WPA2. Add to that the key management issue that can arise when faced with a pre-shared key (which most of those devices have).

Fundamentally, weak wireless security will be compromised. ASSUME it is compromised. Then build your controls around that hostile intermediary. You have already done it at least once, just duplicate it here. Where have you done it? Probably at least two places. 1) Remote access as I mentioned above, and 2) your external website. In both cases, you assume the internet is compromised (oh my stars, is it ever!), and build your security around that assumption.

Posted by Branden Williams at 6:03 AM | Permalink | Comments (2)

On Wednesday, we discussed MasterCard's new requirement for Level 2 merchants to have an on-site assessment performed instead of submitting the Self-Assessment Questionnaire. This news prompted a flurry of information around the new requirement and has merchants asking lots of questions.

I clarified a couple of items from my last post and wanted to make sure they were clear.

1. MasterCard's 2010 deadline is more of an end to submitting SAQs as opposed to a deadline to be validated by a QSA. This means that Level 2 merchants will continue to be able to submit SAQs until December 31, 2010, after which they will need to have the on-site assessment, performed by a QSA.


2. The On-Site assessment must yield a Report on Compliance (ROC), NOT a SAQ. Effectively, Level 1 & 2 merchants will have the exact same reporting requirements for PCI.


3. This does not apply only to merchants processing more than 1 million MasterCard transactions annually, this applies to any merchant classified as a Level 2 merchant from any other card brand. MasterCard defines that their Level 2 also includes "Any merchant meeting the Level 2 criteria of a competing payment brand." This means that if any other brand defines you as a Level 2 merchant, you are now subject to this requirement.

Posted by Branden Williams at 6:43 AM | Permalink | Comments (3)