PCI compliance anxiety ratchets up

In the last few weeks our office phones have been ringing with calls from clients concerned about PCI compliance. A mounting realization that enforcement of these credit card standards is indeed coming, the October deadline to use compliant applications, and widespread confusion about what the standards are and who they apply to, is bringing the issue of credit card security to a boil. [UPDATE: I've created an entire page of PCI information at: http://membersonlysoftware.com/pci ] The background: PCI is an association of the major credit card issuers. The PCI Data Security Standard (PCI-DSS) is a list of twelve security requirements that merchant account holders must meet. According to the standard, "PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply." In other words, if you ever send a credit card number through to the bank for processing, you've got to pass muster. Validation of compliance may require an on-site audit, or may be done by self-assessment and a notarized attestation. And while 12 requirements does not sound like much, the sub-points of each requirement make it clear that the standard affects pretty much every aspect of your IT system and your payment processes. The biggest misconception we see among our clients is the idea that if they are using the right credit card processing system or software, they are compliant. Of course there are requirements that payment applications must meet. Failure to use compliant software is a sure path to flunking your compliance audit. But using compliant software does not begin to guarantee that you the merchant are yourself compliant. The entire security of your computer system comes under the purview of the PCI. In addition, any paper systems that might contain account number data are also involved. Failure to use compliant software is a sure path to flunking your compliance audit. But using compliant software does not begin to guarantee that you the merchant are yourself compliant. Let's look at one example. Requirement #1 reads "Install and maintain a firewall configuration to protect cardholder data." You might think the fact that you have an industry standard firewall product installed gets you a pass on this one. But that is just a starting point. The requirement's details indicate that you need a written policy on how any change to the router or firewall configuration is approved and made. a network diagram that shows all connections and all devices and a process to make sure the diagram is up to date. documentation of the business case for all ports that are open and all protocols that are in use. a formal review of all firewall and router settings every six months. But back to the your software applications. Requirement 6 simply reads "Develop and Maintain secure systems and applications." How is secure defined here, and how do you prove it in a PCI audit? Software applications that are sold "off the shelf"" can apply for the PA-DSS certification. (The Payment Application Data Security Standard - this is a separate standard governing just the software that management credit card payments). Software that is customized for a user organization cannot receive the PA-DSS designation. Instead custom software comes under the scope of each user's PCI compliance audit and may require a code review. The best solution for a customized application is for it to avoid ever coming into contact with a credit card account number, and simply delegate all card handling to a certified PA-DSS compliant application. This is a bigger deal than you might think. For example, if you want to capture the credit card number for a donation in page you have carefully designed and branded, you will need to code review and validate this page as part of your compliance even if all it does is pass this number to a PA-DSS certified payment app. But your greatest exposure arises if you store credit card numbers for any reason after the moment of the transaction. For example, many non-profits charge sustaining donors' pledges against their credit cards on a monthly basis; YMCA's often charge for their dues this way. The requirements for protecting credit card data of this sort are daunting. Maintaining this sensitive data in an encrypted database using the latest encryption technology may not be enough if you cannot document your procedures for controlling access to the keys, monitoring physical access to the server, and so on. The best solution, is to hand off ALL credit card storage as well to a PA-DSS certified application that stores the numbers out in the internet cloud, far from your server, and your liability. We've selected to partner with CAMcommerce, for example, whose PA-DSS certified xCharge application is a dream to integrate with and will provide Members Only users with the security they need. All of this demands that custom applications find new ways of interfacing with payment software. For example, a very widely-used method for interfacing with payment applications involves the business application creating a batch file that is submitted to the payment app. This file contains credit card numbers written out in plain text. And the application returns a batch of response data, again with the number in plain text. This approach is certainly not compliant with the new security requirements. Like Y2K a decade ago, PCI and PA-DSS compliance are going to keep programmers busy for a while. Additional Information: The PCI Security site is full of information about the standard and compliance testing. "Navigating PCI-DSS" is a fifty page introduction to the terms of the standard and the meaning and intent of each clause. It's the best thing to read to get a sense of what this is all about. The Full PCI_DSS specification can be downloaded from this page. And when you are ready, you can also find the self-assessment questionnaire here.

Capability Stairsteps

When we begin a new deployment of our software applications at an organization, we always ask the users "How will you know if this project was a success or not?" We're usually expecting to hear things like "Our staff will spend significantly less time putting together monthly reports" or "We will finally have agreement between the membership lists on the website and in the AMS." But at a recent project kickoff the bar for success was really low: "Our staff will actually use the system." Problems with the adoption of new IT tools can rob an implementation of much of its ROI. And the the solution is not simply making sure you've picked the right tool and delivered the proper training. There are specific steps that need to be taken to encourage user adoption. My friend Russ Eisentstat of TruePoint uses the phrase "capability stairsteps" to emphasize the incremental nature of such transitions. These steps may involve partial use of the new tool, use by a subset of the eventual target user community, or both. But before you can climb these steps you need to design them - adoption will not necessarily spread naturally or completely unless the organization creates a plan and monitors it. The example Russ and I discussed related to the use of a wiki to capture organizational knowledge. One of my long-standing contentions is that an enormous amount of organizational knowledge exists in emails between stakeholders. If these emails were simply captured and organized, a great deal of knowledge documentation could be managed with little or no new writing. But both of us had limited success in encouraging our own organizations to use our wiki. What would a stairstep model for adoption of the wiki look like? First we need to put someone in charge! This is a step that is often ignored in this type of change management. Someone needs to take personal responsibility for the effort to develop the wiki into a useful tool. As soon as we have identified the wikimaster, we have at least one more committed user. The next step is to identify the barriers to adoption so we can plan to eliminate them. Russ and I both agreed that the main barrier is the catch 22 of social sites: the wiki is not attractive to users if it is not yet rich with useful information -- but this will not happen until people begin using it. This barrier can be reduced by "priming the pump." Step two is that the wikimaster takes active responsibility for getting the first fifty articles on the site. He can poll users frequently to get them to send him any material that would be apporpriate for inclusion. This spreads some buzz about the wiki without asking people to utilize it themselves in any way. A second barrier: it takes a bit more learning to become adept at posting than just to read the site. So this suggests the next increment. Step three is to encourage the use of the wiki as a passive repository of information, without leaning on people to post. People can still rely on the wikimaster to post their articles, but can begin to turn to the wiki to look for information they might need. Only now do we tackle active contribution - again a step at a time. In Step four might the wikimaster to encourages people to comment on exisiting articles - reminding them of this capability, and having existing champions comment to prime the discussion on this forum. Step five might be then to put in place rules for how others should post their own articles - how to tag them, how to deal with the home page, how new articles are announced, and so on. At this point a training or informational session might be held for new posters. So what I had thought was a one step procedure - "let's start using this new tool" - has become a five step staircase. This model of identifying barriers and building a step to climb over each one in sequence can be used to encourage adoption of systems of all kinds.

Earth Day Roundup

Links to some interesting reading this Earth Day: Green IT. A couple months ago I posted about "Green IT" and the growing awareness that information technology demands fuel and creates emissions like all other energy consuming activities. But this article in the BBC took me by surprise... email SPAM is a major contributor to IT energy consumption, utilizing 33bn kilowatt-hours of energy every year, enough to power more than 2.4m home, and in the process contributing 17 million tons of carbon dioxide to our greenhouse gas burden. Green Education. A bit of good news for all the non-profits making efforts to educate their constituency about green issues: it makes a difference. The EPA reports that there is a measurable improvement in air quality associated with environmental education. Nearly half of the surveyed institutions hosting education programs reported an improvement in air quality at their facilities due to actions taken by students, including doing service-learning projects and fostering community partnerships. Examples include decreased levels of carbon monoxide and mold, and enactment of a policy that decreased car or bus idling. Green Markets? Free-marketeers have been extolling the value of "Cap and Trade" solutions to control emissions... but there is mounting evidence that it is not so simple. An article in the British New Scientist reviews the results of the ETS (Emissions Trading Scheme) currently in place in the EU. The approach works when the price of permits is high. But if the value falls, the incentive to improve emissions falls right with it: As heavy industries mothball factories, energy use drops and demand for permits goes down. At the same time businesses try to raise cash by selling their unused permits, flooding the market and further depressing prices. French energy company EDF recently complained that carbon markets were failing just like the market for subprime mortgages. As a result, all kinds of green energy schemes are grinding to a halt.

Daily News, Daily Blues

In the last few months, it seems that at every social gathering I attend, the conversation gets around to "Newspapers - what's going to happen to them?" The closing of the Seattle Post-Intelligencer's print operations a few weeks back, coupled with Hearst Corporation's announcement that may close the venerable San Francisco Chronicle as well, has brought the plight of print journalism into focus. And I've been finding that my friends get really worked up about it -- it's clear the newspaper as it exists today has real meaning in people's lives. It's not a problem that suddenly snuck up on us. Back in the summer of '06, The Economist was already talking about the decline of print, and predicting that the future would see the closing of most local papers, and a new mix that consisted of "an elite group of serious newspapers available everywhere online, independent journalism backed by charities, thousands of fired-up bloggers and well-informed citizen journalists..." The problem of course is the collapse of the traditional business model of the newspaper. In that model advertisers pay publishers enough to support the news-gathering operation because advertising in a newspaper with decent reporting was the best way to get their copy in front of readers. As essay by new-media guru Clay Shirky points out, this is no longer the case, because "...the core problem publishing solves — the incredible difficulty, complexity, and expense of making something available to the public — has stopped being a problem." The Internet has disrupted the old economic realities of information distribution. Because of that, advertisers have migrated to the net in droves. In the past, classified advertising was the most lucrative source of advertising revenue for the publisher - Rupert Murdoch referred to it as "a river of gold" - but that river is now reduced to a trickle, leading the Economist to say that Craigslist has done more than anything to destroy the newspaper. And publishers' reponse to that loss of revenue has been to cut expenses by shrinking the paper and reducing the news staff - in other words, by making their product less desirable. Shirky says, "Society doesn’t need newspapers. What we need is journalism." But the newspapers have provided a concentration of resources for serious journalism that the new media alternatives, such as The Huffington Post, let alone individual bloggers, have not yet demonstrated an ability to replace. Walter Isaacson, former managing editor of Time and former CEO of CNN, assumes that the print edition is dead but the institution need not perish with it. He proposes that the solution is for the major pappers to begin charging for their websites. Even an old print junkie like me has quit subscribing to the New York Times, because if it doesn't see fit to charge for its content, I'd feel like a fool paying for it. This is not a business model that makes sense. Isaacson envisions both a subscription basis (as the Financial Times and Wall Street Journal currently have) as well as a micropayments model where individual articles have a small fee (five or ten cents each) for non-subscribers. Conventional wisdom is that people will not pay to read the newspaper online, but Isaacson is convined that it can be done. After all, he points out, people pay to text. Some resources: "Who Killed the Newspaper", The Economist, August 24, 2006. Eric Alterman, "The News Business: Out of Print," The New Yorker, March 31, 2008 Clay Shirky, "Newspapers and Thinking the Unthinkable",March 13th, 2009 Walter Isaacson, "How to Save your Newspaper", Time, Feb 5th, 2009 Scott Adams, "The Future of Newspapers", Oct 1, 2007

What is Green IT?

For a couple of years now we've been seeing talk of Green IT, and as early as 2007 management consulting giants Gartner and McKinsey were addressing Green issues as a major issue facing IT managers. The McKinsey report offers a concise statement of the issue: The rapidly growing carbon footprint associated with information and communications technologies, including laptops and PCs, data centers and computing networks, mobile phones, and telecommunications networks, could make them among the biggest greenhouse gas emitters by 2020. However, our research also suggests that there are opportunities to use these technologies to make the world economy more energy and carbon efficient So Green IT is really two issues: making information technology itself more energy efficient, and going beyond that to using IT to reduce the carbon footprint of other operations. Today's EnergyWise announcement by Cisco underscores the growing concern managers have in both these areas. The EDS blog The Next Big thing devoted eight posts last autumn to an in-depth look at the idea of Green IT and lays out a path that considers both of these issues in detail, focusing on the green data center. Many of these ideas seem more appropriate for a Google or Microsoft than for a medium-sized non-profit or association. Techsoup offers some suggestions for Greening the smaller workplace. These include virtualizing your servers to use fewer boxes, and using your technology to minimze travel. Has your organization grappled with these issues? Have your solutions saved you money, added complexity, or both?