Branden Williams' Security Convergence Blog

Webcast, on July 7, Maintaining PCI Compliance!

2009-07-02T19:43:17Z

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.

Guest Post: The IT forecast - Cloud-y with a 10% Chance of Effective Security

2009-07-02T13:17:25Z

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'.

MerchantWARE Goes Blackberry, and the story of the unvalidated payment application

2009-06-30T13:01:49Z

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.

Are you at the Gartner Summit?

2009-06-29T15:00:50Z

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!

The Final Word on MasterCard's New Levels

2009-06-26T12:15:27Z

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.

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).

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.

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.

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!

Much Ado About Nothing, Merrick v. Savvis Update

2009-06-25T13:20:40Z

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!

Clarification on MasterCard Level 2 Requirements

2009-06-24T13:48:47Z

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!

Nevada's New PCI Law

2009-06-24T12:07:15Z

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!

More on NRF's Letter to PCI SSC, and the Wireless Network that Could

2009-06-23T13:03:37Z

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.

More on MasterCard's Level 2 Change

2009-06-19T13:43:41Z

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.

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.

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.

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.

I hope you all have a chance to ponder that over the weekend, and we'll catch you next week for more security fun!

NEWS FLASH: MasterCard Requires On-Site QSA for Level 2 Merchants

2009-06-17T17:13:13Z

Thanks to Smiley for the tip!

MasterCard has posted a change to their Site Data Protection program that requires Level 2 merchants to use a QSA and an on-site assessment. This is a dramatic change from the current, industry wide requirement of self-assessing for merchants processing less than six million transactions annually.

While this is definitely going to put a dent in Level 2 merchant budgets from this point on, I truly believe that this is a smart move by MasterCard. Level 2 merchants are extremely significant in size, many of which being household names. Unfortunately, PCI self-assessments are typically poorly handled simply due to the complexity of the standard and lack of training provided to those individuals performing the assessment. When our folks are contracted to review these, we typically find that a previously fully in-place Self Assessment Questionnaire is only about 70% accurate. Meaning, that 30% of the items answered "Yes" or "N/A" are actually "No."

So far, none of the other card brands have changed their status.

It's unclear if others will follow suit, but regardless, if you are 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.

Are you passionate about security?

2009-06-16T16:47:46Z

People often come up to me and say things like, "Wow, you really are passionate about your work!" Aside from the old "Do what you love, and love what you do" adages our great grandparents regurgitate to us when they see us struggling with some arguably trivial thing in our work lives, passion is something that people can see on you.

We've all sat through one of those talks at a conference or an association meeting where it is clear that the speaker is just going through the motions. Maybe they are not just reading right off the slides, but you can tell that the only thing they are thinking about is hitting the tables, bar, or airport. Did you really listen to their message? Or were you also thinking about hitting the tables, bar, or airport?

When you are talking to co-workers outside of security, do you exude passion for your work? Sure, they may not care that something you did increased productivity of the workforce by deploying a spam filtering solution, or that you helped an inexperienced netizen tell the difference between a real email from your company and a phishing attack.

I'm not trying to pull a Zig Ziglar on you, but stop for a moment and think about your current position. If you are in security, are you passionate about it? Does that passion come through in your interaction with co-workers? Do your projects get extra care and feeding because you really want to see it done right? Are you passionate about security?

If not, maybe you are in the wrong job. We need passionate people to evoke the change required to achieve our goals. We need people who care enough about security to spend the extra twenty minutes helping a curious co-worker understand why we need to block his MySpace, and offer alternatives so that he can use his break time efficiently enough to get his fix.

Security is close to a tipping point. We've finally made it past the whiz kid techie that knows some security stuff to organized security departments and functions that add value to companies. Passionate people will help spread the message farther and wider, further legitimizing our existence and importance!

Jeez, you guys crack me up.

2009-06-11T14:30:25Z

I hate to be a cynic.

OK, fine. SOMETIMES I get secret enjoyment out of being a cynic. Kind of like the enjoyment of making fun of someone in a way that they don't know they are being made fun of. Or that satisfaction of eating candy from your kid's Halloween stash knowing they will never miss it (unless your kid is Ms. KJ... you know who you are, you little Halloween candy auditor you...).

The NRF and others "ganged up" on PCI yesterday by sending a letter demanding easier treatment under the standard. I understand the intent, and applaud them for sending the letter across. While there may be a valid point or two buried in there, I think this is a sad day for Merchants.

I have said many times before, PCI is NOT the scariest thing out there. Savvy merchants have figured out how to win within the rules as opposed to digging their heels in like my 4 year old son when it's time to go inside, running down the sidewalk screaming NOOOOOOOOOOOOOOO. Savvy merchants know that these rules, while a little bit broad reaching, can help them solve OTHER security issues, and help their company realize that security is much more than dealing with fraud & shrink.

These merchant associations only represent a vocal minority among their constituency. Most merchants I deal with really want to get security right, and have conceded that if it has to start with PCI, then that's where it has to start. There are those few that fight you tooth and nail on every single requirement, pushing for a ruling that gets them the easiest pass with the fewest amount of dollars spent. Unfortunately for QSAs, they are also the most likely to be breached, and the ones that will turn on you in an instant, throwing you under the bus.

As another industry expert said (I can't remember who to attribute it to), "It's a scary time to be a QSA!"

Luckily for our customers, we take a partnership approach versus an audit approach. Our customers love the collaborative process that our assessment takes, and understand the value and cost of information security.

If you are a member of these associations and are unhappy with the direction they are taking, I urge you to speak out! Breaches involving PII are much more costly and dangerous to the longevity of the business, and without PCI to raise the general information security flag, your business is next!

Guest Post: Contracts & PCI

2009-06-10T13:10:44Z

The following is a guest post by David Navetta.

Before starting, I would like to thank Branden and VeriSign for allowing me to guest post on this blog. I think it is very important to foster dialogue between security professionals and attorneys as our worlds are colliding on an increasingly faster pace. At the same time both sides tend to speak different languages and have different concerns, even though we share a goal: reducing risk for the organizations we work for. As those concerns overlap both communities need to be able to translate each others' issues into a language that the other side can understand and act upon. Hopefully this blog post is helpful in that regard. One more item, if you want to read more blog information security and privacy law blog posts, please check out my blog: www.infoseccompliance.com Thanks.

As an attorney focusing on information security and privacy issues, I often get called in to assist companies to understand their legal liability risk around the PCI (self) regulatory system. One of the key areas I get involved in is service provider relationships, and in particular section 12.8 of PCI and service provider contracts. There are many aspects of 12.8 (and its subsections) that are potentially ambiguous and open to interpretation, but this particular article is not going to focus on those. This post concerns the "written agreement" referenced in 12.8.2, which provides in full:

12.8.2. Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.

We could debate whether a "written agreement" is the same of as a "contract" as referenced in version PCI v. 1.1 (under the law there is not much difference between a "contract" and an "agreement"). However, rather than concentrating on mere PCI technical compliance, this blog post will discuss the contract terms merchants should consider in their service provider agreements to actually manage their security risk. Of course service provider agreements should address the PCI requirements, but for merchants concerned about truly mitigating their risk, much more is involved. Coincidentally, I am in the middle of writing a book on payment card contracting that will be released through the American Bar Association, this post summarizes some of the ideas/concepts that will be in that book.

Pre-Contracting Activities

In general, as most understand, organizations cannot "outsource" compliance with PCI. That is to say, while merchants work with service providers that do some or all of the merchant's storing, processing or transmission of cardholder data, interested parties will still attempt to hold the merchant responsible for the service provider's non-compliance with PCI, and the impact of a service provider's payment card security breaches. The service provider contract is one of the key places where this risk can and must be dealt with (the other mechanism for managing service provider risk is insurance, but that is another topic for another day).

The first step in the process is understanding what the merchant has legally obligated itself to. This requires an analysis of the merchant's "upstream" contracts: the various "merchant agreements" it has in place with payment processors and/or merchant banks. If a merchant deals with more than one card brand there could be multiple contracts. In essence, the goal here is to identify the merchant's upstream obligations and transfer those obligations down to any service providers utilized by the merchant. For example, if the merchant agreement requires the merchant to indemnify the payment processor for fines and penalties imposed by card brands, the service provider agreement should require the service provider to do the same. One thing to note. Most modern merchant agreements require merchants to adhere to the relevant payment card brands' operating regulations. As such, merchants should understand those obligations (e.g. Visa's Account Data Compromise Recovery process) as well in order to transfer risk to their service providers.

The second step is attempting to understand the risk posed by the particular service provider the merchant is dealing with. What is the transaction volume the service provider is handling? What controls does the service provider have in place or not have in place? Has the service provider's security been independently assessed (e.g. by a QSA)? What would happen to the merchant's business if the service provider went down (e.g. not all the risk is liability risk)? If the service provider suffers a breach, does it have an incident response plan to mitigate harm and provide notice to the merchant? In addition to general security requirements, depending on the nature of the transaction, this risk assessment may result in specific service provider contractual obligations.

Security Contract Terms

So what security-related terms should be in service provider contracts? This answer to this question will vary depending on many factors (e.g. the type/purpose of the transaction, the data at issue, the laws that apply, the upstream contractual obligations of the merchant, etc.), but the following should be considered:

(1) Definitions. The payment card world relies on particular definitions and terminology. To avoid confusion, where warranted, some definitions should be incorporated into the contract (e.g. PAN, sensitive authentication information, etc.). This can be achieved in part for some key terms by referencing the PCI standard and/or the PCI glossary.

(2) "Preventative" Contract Terms -- Compliance and Controls. The overall purpose of these terms is to contractually obligate the service provider to certain controls and practices with the hope of preventing non-compliance and/or a security breach (or at least to decrease the risk of those events). In these sections the service provider should be required to comply with the requirements of the PCI regulatory system. This includes, but goes beyond, the PCI standard itself. Other elements of the PCI regulatory system include card brand security programs, FAQs, Guidance papers and other documents issued by the PCI Council, and the card brand operating regulations themselves.

In addition, if there any specific controls or security measures that the merchant wants the service provider to implement and maintain, that should be indicated. Merchants can also draft other standards into the contact, such as ISO 27001, if desired. Last, regardless of the specifics, the service provider should have an obligation to maintain "reasonable security" to protect the sensitive data that is the subject of the agreement. By broadening the duty to "reasonable security" the hope is to avoid cases where technical compliance with PCI was achieved, but the service provider's systems were not actually secure. The reference to "reasonable" establishes an "objective" standard under the law that allows for scrutiny in a litigation context. Note that all duties in this section should be made ongoing and continuous (none of this PCI compliance only matters on the day the contract is signed), and the service provider should be required to comply with changes to the PCI Standard.

(3) Monitoring and Reporting. These contract terms should provide the merchant with the right to monitor and enforce compliance with the service provider agreement, the PCI standard, payment card company security programs, etc. There are many ways this can be achieved, including imposing reporting requirements on the service provider, providing the merchant with security assessment rights or actually requiring a periodic third party audit. With respect to PCI, the agreement should require the service provider to allow the merchant (or third parties selected by the merchant) to conduct quarterly network scans, as well as QSA assessments.

What are the consequences of non-compliance with the agreement or PCI? Monitoring is good, but if non-compliance is found the merchant must also have enforcement rights. Without enforcement mechanisms the service provider's promises may be hallow. Contractual penalties may be put into the contract, indemnification rights (discussed below), termination rights and other remedies may be considered. The key here is to have some leverage to get the service provider to actually comply instead of having to abandon the relationship and find a new service provider. .

(4) Security Incident Response. Service providers and outsourcers act as an extension of the merchant's operations. However, if their incident response procedures are out of sync it could be problematic. Merchants need to understand their service provider's internal incident response procedure and then build contractual obligations that allow the merchant's incident response procedure to seamlessly meld with the service provider's. This section may require service provider to identify a response coordinator to act as a liaison and cooperate fully with the merchant. In addition, it may require an investigation, remedial action, notice and reporting to the merchant and payment card network, collection of evidence, documenting incident response and access to service provider systems, logs and data.

One of the key considerations here is identifying the party responsible for complying with breach notice laws. Arguably, based on the statutes themselves, the primary duty would rest with the merchant, and the merchant would have to pass it on contractually to the service provider (note the primary duty would still reside with the merchant, so if the service provider refused, the statutes still require the merchant to comply).

(5) Rights, Remedies & Indemnification. These terms transfers risk of loss between the merchant and service provider and provide other rights for breach of the service agreement or in the event the service provider suffers a security breach. These terms are amongst the most important in the agreement, and are also the most contentious to negotiate. However, they are also the most important and truly establish the baseline for the merchant's liability in the event the service provider makes a mistake. The following should be considered.

Indemnification rights should require the service provider to pay for/reimburse the merchant for claims, attorney fees, lawsuits, fines, penalties and other costs associated with the service provider's non-compliance with the agreement and other requirements of the PCI regulatory system, as well as security breaches (whether compliant or not). If there is a limitation of liability clause, exceptions should be considered for security breaches, fines and penalties due to non-compliance and other issues. The same holds true for any consequential damages limitation clause that finds its way into the contract. Additionally, termination rights should be built into the contract based on service provider non-compliance or security breaches.

(6) Insurance Clause. An insurance clause requiring the service provide to purchase insurance covering security breach notice law compliance, liability arising out of security breaches and other professional errors or omissions should be considered (especially when utilizing smaller vendors). If possible, the merchant should be named as an additional insured on the policy so that it can tap directly into the policy proceeds. This clause should specify required limits and should require the insurance to be primary. In addition, the contract should note that insurance proceeds are not intended to limit the amount of the service provider's liability.

To implement these terms, what I often do is create a security schedule or exhibit that contains all/most of the security-related obligations of the contract. Oftentimes a merchant will be forced to work with the service provider's contract. If the security terms are in a pre-established exhibit, that exhibit can be incorporated into the contract (with some careful drafting of course). On a final note, please understand that while this post has focused on PCI, a framework similar to that described above could be used for other statutory or security requirements, including GLB, HIPAA, EU Data Protection Directive and others. In fact, for organizations with multiple security standards or laws to comply with, a security exhibit or schedule can be an efficient way for addressing all of the requirements at one time and in one place.

Conclusion

At this point in time when reliance on service providers and outsourcers to handle payment card information is high, while the legal liability risk associated with payment card security breaches is significantly growing, the security terms in a service provider contract have increasing importance.

In fact, I counsel my clients to raise some of the terms they want (especially indemnification) at the RFP phase instead of waiting until later. The key here is to create competition between potential service providers not only on price and scope of services, but also acceptance of risk and contract terms (those willing to accept more risk being potentially better candidates than those not so willing). Organizations that wait to request protective contract terms until after they have selected a vendor may find those terms watered down during negotiations, and may be stuck holding all the risk of a service provider mistake (and you know that for most service providers the default is contract terms that completely insulate them from risk - don't settle for that!). As it currently stands the focus of risk mitigation with respect to security are technical controls and other security measures, and the importance of the contract as a risk mitigating tool is overlooked. As litigation increases in this area, for risk-conscious organization, the protections (or lack of protections) in the service provider contracts are going to become very important.

The Ready-Fire-Aim Method to Software Security

2009-06-09T13:55:44Z

It's now day two of WWDC, and amidst the AT&T iPhone 3G customers crying foul at the upgrade price to the 3GS, we've seen previews of the newest revision of the OS X series, Snow Leopard. After listening to the keynote (btw, I am not actually there, just living vicariously through the twits that are), I finally understand why Apple did a total stoner's give-up on the name to the new OS. At first, I was a little bummed.

I mean, can't you imagine what the Apple commercials would look like if it were code named Cougar? Rawr!

Snow Leopard is largely based on Leopard, but with several core components rewritten or enhanced to add amazing new functionality that is making my mouth water like crazy. My first computer was a Mac--the old all in one that had the OS loaded on the first 3.5" diskette you put in. Total awesomeness. In High School, I discovered the greatness of Unix with my first internet account through Netcom. Then running some Linux machines in the lab at school. Man, I hosed MANY a Linux box back in the day. After High School, I switched to PC for a while. OS 9 seemed stagnant, and at the time PCs were experiencing much more of the cool factor than Macs were.

After OS X released, I'd always wanted to get back into Mac. So I took the plunge! Now that I live in the Mac world (except for my work PC... not bitter), I am very excited to see Snow Leopard continue to grow in functionality and integration into the corporate networks we live with every day. The Exchange functionality in Mail is looking super sexy! With the new line of eco-friendly laptops being released just before the release of Snow Leopard, there is no question that we will see a swell in the growth of this platform in IT.

OS X has largely flown under the radar from a security vulnerability perspective. That's not to say that Apple has not had to scramble to fix some serious vulnerabilities in the past, but when you look at the number of vulnerabilities in OS X over its lifespan versus say Windows XP, it is largely flying under the radar. Also, consider that Microsoft owns anywhere from 85-90% of the PC market depending on error and data source. If I were a bad guy, I would target something that will get me the biggest bang for the buck, or Microsoft Windows.

As Apple's market share grows, this will change. This article from Darknet UK suggests what many in the industry have suspected, Apple is woefully unprepared and may end up becoming a victim of their own success.

Software vendors are sometimes pressured to push software out the door before being able to complete security reviews. I know this because I used to write software for a company that routinely did this. Security is something that is an afterthought in most of the development world. Instead, companies like Apple, Microsoft, and Adobe (as mentioned in the Darknet post) should put their software through the rigors of code reviewing technology to find as many vulnerabilities introduced by sloppy coding BEFORE releasing the product to the world.

The Ready-Fire-Aim method is the way we deal with security in software today. Release it, wait for something to happen, and then fix it later on. It's like the Dump & Chase method in hockey. You are relying on your offensive players to chase down the puck on the opponent's side, beating their defense, while using your own defense to keep the puck in the zone.

In order to move that Aim back one step where it should be, we need to focus on security before code is released. Even to the point where we might choose to delay a release by a month in order to find and fix these vulnerabilities. The easiest vulnerabilities to fix are the ones that don't show up in the final code base in the first place.