Changes for PCI In October: "No Surprises"

I just saw a report that reference recent statements by Bob Russo, General Manager of the PCI Council, where he talked about possible changes to PCI in October.

According to an article at SearchSecurity, Russo said "There won't be any surprises. We're more likely to see guidance documents." In a lot of ways, this makes sense. The Council is studying a number of relatively new technologies (a couple of examples are end-to-end encryption and tokenization, but there are others) and their impact on both merchant compliance and the DSS itself. With some guidance from the Council, merchants will be more comfortable making choices and deciding how to implement them. As Russo explained:

"End-to-end encryption is a catchphrase because at a certain point along the line, the data needs to be decrypted," prompting key management questions, Russo said. "Key management introduces a whole new series of issues that could cause you to be less secure."

Russo said he doesn't expect an end-to-end encryption special interest group will study the issue. Instead encryption within the payment process will be addressed when other technologies that affect the payment process are identified and studied. The Virtualization Special Interest Group, due to recommend guidance in March on protecting card data within virtualized environments, will address the role of encryption as well, Russo said.

"Unfortunately there are so many different technologies that merchants may have started down the path with that we need to be careful and study them before prescribing them in the standard," Russo said.

We are just over 3 months away from May when the Council will publish the revisions to the DSS for Participating Organizations. I am hoping we have specifics for the Treasury Institute's PCI Workshop (hint, hint...), but at least we'll have Bob Russo himself there - live and in person - speaking to us.

Cost of Data Breach Study Updated

Ponemon Institute together with PGP Corporation just released their 2009 U.S. Cost of a Data Breach Study. The bottom line is that the cost of a data breach increased to $204 per record compromised, a small increase from the $202 figure for 2008. Perhaps more important than the average, per-record statistic is the total cost of a data breach. Despite an overall drop in the number of reported breaches, the average total per-incident costs in 2009 were $6.75 million, compared to an average per-incident cost of $6.65 million in 2008.

Some of the highlights of the study are:

• The cost of a data breach as the result of malicious attacks and botnets were more costly and severe.
  
  
• Negligent insider breaches have decreased in number and cost most likely resulting from training and awareness programs having a positive affect on employees’ sensitivity and awareness about the protection of personal information. Additionally, 58 percent have expanded their use of encryption up from 44 percent last year.
  
  
• Organizations are spending more on legal defense costs which can be attributed to increasing fears of successful class actions resulting from customer, consumer or employee data loss.
  
  
• Average abnormal churn rates across all incidents in the study were slightly higher than last year. The industries with the highest churn rate were pharmaceuticals, communications and healthcare, followed by financial services and services.
  
  
• Third-party organizations accounted for 42 percent of all breach cases, dropping from 44 percent of all cases in 2008. These remain the most costly form of data breaches due to additional investigation and consulting fees.
  
  
• The most expensive data breach event included in this year’s study cost a company nearly $31 million to resolve. The least expensive total cost of data breach for a company included in the study was $750,000.

You can download the entire report (registration required) here.

Will Cyber Attacks Hit Higher Ed Next?

With the recent attacks on a number of high tech companies like Google and Adobe, can we expect similar cyber attacks soon against higher education institutions?

I have to believe leading research institutions are or have been targeted for their research and intellectual property assets. I am speaking on this topic next week at the Treasury Institute's Symposium. My talk ("A Senior Management Perspective on Cyber Security") was originally aimed at the usual trojans and malware, but the news these past weeks have me updating my message.

What has me particularly concerned is an article in CSO Online entitled Botnets: The Democratization of Espionage by Brian Krebs. Read it. While the attacks on Google et al were not by botnet, the scope of botnets can give hackers - even the ones that are just plain old criminals and not nation states - the tools to compromise your systems and data.

Your networks are being scanned continuously by the bad guys looking for a way in. The threat is not going away. It can only get worse.

PCI Security Policies and You - Part 3

When the going gets tough, the tough get help.

At least that's how I look at it, especially when dealing with policy development.

An automated PCI security policy template is a productivity tool that makes sense. A tool - any tool - can't write a good policy for you. What it can do, however, is give you a starting point and guide you along the way to developing all the policies you need. A good tool provides a discipline and thoroughness to keep you from missing something important. It also saves you and your colleagues time and effort by letting you focus on what is important: developing actual policy details that work for your school.

A good security policy template provides you with a structure while preserving flexibility. It also should lead you to additional resources where this can be useful. I've provided an example of this above for a policy addressing web application security policy. (Yes, I know it's impossible to read, but if you click on it you should get an enlarged version.)

Another feature to look for in a policy template is the ability to cross-reference your policies to the PCI requirements. I'm not saying that your policies have to mimic the DSS numbering system, but being able to cross-reference your policies to the DSS can be a time saver.

So the obvious question is where can you find a security policy template? The obvious first answer may be to search the web, but my personal opinion is that this would be one case where Google is not your friend: I searched for "security policy template" and turned up over 41 million links.

A better approach would be to start with the public sources noted in the previous post. Some of these sources may have templates although I'm not sure all are PCI-specific. You also can ask your QSA if they have a policy template tool. Many QSA firms have templates that you can buy and use on your own or with additional consulting assistance. Either way you get a tool that is designed to help you write high quality PCI security policies in the fastest and (hopefully) most painless way. There will be a cost for the templates and for additional support, but compared to the person-hours you will save over developing your own policies from scratch the investment may make sense.

Another approach is to take advantage of the fact that Higher Ed institutions collaborate. Check with your peers who are managing the PCI program for their schools to see if they have policies that you might be able to use as a guide. They may not be able to solve all your needs, but maybe they can give you a start.

I am planning on a session at the Treasury Institute's PCI Workshop in May addressing PCI policy development. Several individuals have volunteered to help, so I am hopeful we will have a good discussion. (You have registered for the Workshop, right...?)

In the meantime, give a thought to using a policy template. Your PCI policies do not have to be long, wordy documents. My own belief is that policies should be simple declarative sentences. The fewer words the better. Your procedures may be more lengthy, but the policies can be straightforward, so don't fall into the trap of making them cover every possible contingency.

That's another advantage of a template: it keeps you focused.

PCI Security Policies and You - Part 2

Above is a table. It's kind of hard to read, but if you click on it you should be able to get a larger view of it. Security poicy requirements affect to some degree every campus merchant the table maps the PCI requirement needing a written policy to the respective Self Assessment Questionnaire (SAQ).

For example, a merchant that outsources its processing and qualifies to SAQ A has to implement policies for managing their service provider(s) (12.8) and for handling the paper media with cardholder data (9.7, 9.9, and 9.10). I decided to include 3.1 in the table since to meet the relevant parts of requirement 9 you need to develop a data retention and disposal policy.

If you use another SAQ you have more policy work to do.

Your first option is to develop your security policies independently from scratch. This choice has the advantage of responding to your organization’s operations and business needs and culture.

Your second option is to search for models templates to give yourself a head start. This is the “Google is your friend” approach. If you decide to follow this approach, three sites in particular merit your attention:

• SANS Institute has a excellent resources including whitepapers that can help get you started
  
  
• NIST’s Computer Security Resource Center is another good source

• Educause has a Data Incident Notification Toolkit.

One problem with any of these resources is that the examples may not match your school's exact needs. Another problem is that none is designed to be PCI-specific, and none really covers all the requirements. That is, you will still have a lot of work to do modifying whatever you download to fit your PCI needs.

The good news is that many schools view their security policies as public information. As a Higher Ed institution, you are part of a very collaborative group of people. Therefore, some of the best potential examples may be available to you on the web.

But if you can't find good examples, there may still be an option.

That will be the subject of Part 3.

PCI Security Policies and You - Part 1

[This blog post deals with an article I wrote for the third quarter 2009 issue of Secure Payments Magazine. I have adapted it here particularly for Higher Education. --Walt]

Imagine this situation:

You have been told to create your school’s security policies. You research all the components and compile the requirements for notification in your state, but you have not yet written the policies. OMG! How do I get started?

There is something about security policies – drafting them, reviewing them, following them – that causes otherwise calm professionals to behave badly, or at least irrationally. Responsibility for drafting a policy can get passed through the organization faster than swine flu. Then once they are drafted, suddenly everyone’s too busy to review them. (On a personal note, this is one part where I disagree with the Council's otherwise excellent Prioritized Approach - it holds policy development until the end.)

Possibly this behavior results from our associating “policy” with “control.” Policies are perceived as restrictive, difficult to follow, and an attempt to control behavior. Policies affect everyone in the organization, so they are by their nature political.

I am not going to debate the wisdom of having a comprehensive set of security policies. That conversation is over: PCI DSS compliance requires it. Instead, in this post and the ones that follow I want to focus on what you need to do to help your school develop security policies to meet the requirements of PCI and reflect your institution’s needs effectively and efficiently.

Let's start by looking at what actually are all the PCI Policy Requirements.

Searching PCI DSS version 1.2 yields more than 65 references to the word “policy.” Some references like Requirement 3.1 are straightforward: "Develop a data retention and disposal policy." But other references are broader. For example, 12.1 and 12.1.1 form a catchall requirement to have a security policy that “addresses all PCI requirements.” I put a table together that lists each PCI DSS requirement referencing a written policy. This table becomes your guide for complying with 12.1.

PCI DSS v1.2 Requirement and Corresponding Policy Objective

3.1 Document retention and destruction
3.3 Masking PANs
4.2 Sending unencrypted PANs
5.2 Anti-virus updating
6.1 Security patching
6.3.7 (a and b) Reviewing custom application code changes
7.1 Restricting access to Cardholder Data
8.5.1 User IDs
8.5.7 User passwords
8.5.8 Shared passwords
9.7 Distributing media containing Cardholder Data
9.9 Storing media containing Cardholder Data
9.10 Destroying media containing Cardholder Data
10.6 Reviewing security logs
10.7 Retaining security logs
11.2 Quarterly vulnerability scans
12.1 Policies for all PCI Requirements
12.3 Employee-facing technologies
12.4 Security responsibilities for employees and contractors
12.5 Security management responsibilities
12.6.2 Employee acknowledgement
12.8 (12.8.3) Managing service providers
12.9 Incident response plan
12.9.3 24/7 incident response
12.9.4 Incident response training
12.9.6 Modifying incident response plan

Some of the policies doubtlessly already exist in your organization, and others can be just a few sentences long. Nevertheless, PCI compliance requires a lot of policies. We will look at how your policy writing task may depend on your SAQ in the next installment.

In the meantime, let me know your thoughts. If you have already done this for your institution, I’d love to talk to you about presenting at the Institute’s PCI Workshop in May (and yes, registration is now open!).