How Social Networking Will Affect Privacy and Data Security of Your Events

Last week, Certain Software exhibited with other meetings technology companies at the HSMAI Affordable Meetings conference in Washington, D.C. The show hosted a separate Event Technology Expo for companies like ours, whose booths surrounded a 40-seat demo area where vendors spoke each half-hour on event technology topics. Rather than repeat the product sales pitch that I used in our booth, I elected to speak about the emerging data privacy and security issues as social networking applications work their way into face-to-face events.

Event Technology Expo Short Seminar

I prepared these slides before I read my speaker instructions and learned that the 15-minute presentation was audio-only. But these are the talking points that I used at the expo.

Identity theft - the most prevalent crime in America?

I spoke at the Society of Government Meeting Professionals regional meeting in Oklahoma City this weekend. If you haven't been to Oklahoma City recently, its Bricktown area is nice - with a great baseball park, new NBA stadium, and a nice "riverwalk" (really a concrete canal, but well done anyway).

Enter the Secret Service

Daniel A. Baker spoke immediately before me. He's a Special Agent from the Oklahoma City Field Office of the U.S. Secret Service and he gave a fascinating talk on identity theft. I spend most of my time trying to prevent credit card and information theft, so it was interesting to see the law enforcement perspective that takes over when prevention fails.

One statistic that hit me was that 3 or 4 out of ten Americans have been victims of identity or related theft (e.g. credit card fraud) either directly or through family members. To me, that implies that identity theft is the most prevalent crime in America.

Do we spend most of our time fighting crimes people don't commit?

Another interesting statistic came in my mail from the City of Lewisville. Homeowners with registered alarm systems now must pay $50 per year, because 99% of the 6,000 residential alarms that Lewisville police respond to are false. So, last year our police spent more time responding to about 50 break-ins (and nearly 6,000 false alarms) than to the several hundred identity fraud crimes that I'd expect in a city of 100,000. As I've blogged in the past, I've had $1500 stolen (and refunded) from credit card fraud and an attempted theft of nearly $24,000 in check fraud, yet no law enforcement agency I contact has the resources to tackle such "small" crimes.

I'll keep working on fraud prevention, but I wonder if the criminals are staying a step ahead of us with these newer electronic crimes?

PCI Data Security Standard Version 1.2 Takes Effect

The PCI Data Security Standards will update to Version 1.2 as of December 31, 2008, when Version 1.1 will "sunset". On October 1, the PCI Security Standards Council released version 1.2, which did not change requirements, but provided additional clarity and flexibility and addressed evolving threats. Windows IT Pro provides a nice summary table detailing the changes between version 1.1 and 1.2.

The end of Wired Equivalent Privacy (WEP) wireless security

The major practical change that I found in PCI v1.2 is that new implementations of WEP security in Wi-fi Internet access are not allowed after March 31, 2009. Current implementations must discontinue use of WEP after June 30, 2010. WEP is a popular security option for Wi-fi installations, however, it became obsolete in 2004 with the completion of the Wi-Fi Protected Access (WPA) standards, and WEP is dangerously vulnerable. Nevertheless, WEP remains the default option for wireless security with many Wi-fi routers.

If you haven't migrated your Wi-fi networks away from WEP yet (or if you are still using unsecured Wi-fi), make it one of your New Year's resolutions to update your wireless security.

Happy New Year

2008 marked my ten-year anniversary working on Certain Registration (originally Register123). I wish you all a Happy New Year and best of luck in 2009.

Security for Web 2.0 presentation at MTE in Washington DC.

Yesterday, I had the opportunity to present at the Meetings Technology Expo in Washington, D.C. I modifed my Web Security presentation from the Chicago show to include "Web 2.0" technologies. I loosely define "Web 1.0" as technology where the site owner pushes content to a user. "Web 2.0", by contrast, includes technologies where the site owner provides a platform that allows users to publish, consume, and interact with each other in a community. (For example, Blogs, wikis, social networks, forums, etc.)



Security for Web 2.0



Below are the slides from my presentation. Click on any image to see a larger version.

Why be PCI Compliant?

I've spent three weeks discussing PCI Compliance, but why am I so concerned about protecting financial and personal information? Because there are a lot of bad people in the world, and the Internet has given them access to the more trusting (or "gullible", from their perspective) audience in relatively safe countries like the United States. Here are two recent experiences that could have led to financial loss.

Scam 1: "Please refund my other card"

I heard this story from one of our clients during a recent Performance Analysis.

An attendee registered for a training conference and attempted to use several different credit card numbers to pay for his tuition. (He eventually completed payment with a Visa card.) Weeks later, he sent an email to the event's registration support contact explaining that he would be unable to attend the conference, but that he had recently switched credit cards and would like the refund to be posted to his new credit card number. The support contact decide not to do this, because (1) PCI Compliant systems like Certain Registration don't support this process and (2) the request, combined with the number of failed payment attempts using multiple credit card numbers, "smelled fishy".

Later, the client found out that the Visa card used for tuition payment belonged to a older woman in Arizona, and after piecing this puzzle together, they refunded the full amount to the original card. Our contact notified their corporate security department, who in turn contacted the FBI's Internet Crime Complaint Center (IC3). It turned out that the "attendee" was a Ghana national involved in a fraud operation much larger than this incident. Fortunately for our client, because they listened to their instincts instead of immediately trying to satisfy the attendee's request (and because they were using a PCI compliant system), the investigation could be turned over to the FBI without financial loss for either them or the credit card victim.

Scam 2: "Sorry, but I wrote the check for too much"

The second experience hit closer to home. I recently moved and listed my previous townhouse for rent. I received an email from "Marcus", who informed me that he was placing a colleague in the north Dallas area for a year and would like to rent the house, and would it be okay to pre-pay six months' rent in advance? My suspicion was raised by the poor grammar in his email, but you can't argue too much with cash up front, so I accepted the offer.

Two days later I received a DHL overnight package from Dubai, United Arab Emirates with a cashier's check for $35,300 drawn on JP Morgan Chase Bank in Florida. Great - except that six months rent plus deposit was only $11,200. He then sent me an email stating that he had accidentally cut the check for too large of an amount, but he was not able to change it so could I please cash the check and then wire transfer the difference ($24,100) to his bank in the UAE?

Well, that was the end of the business deal for me, but I have learned that this con is common enough to get it's own FTC warning, and successful enough that the FBI IC3 is only interested in your case if you actually lost money. A few mornings later, I received a phone call from "Marcus" (which showed on my caller ID as originating from a Dubai country code) and from the background noise activity it certainly sounded like he worked in a call center operation as busy as that of any medium-size business in the U.S.



It's a jungle out there

The Internet has brought the world together, but unfortunately much of our world is still the Wild West. Be careful out there, and follow best practices like those of the PCI Standards.

PCI Compliance Part 3 - Don't lose that credit card data!

Two weeks ago, I discussed what PCI Compliance is and where it came from. Last week, we reviewed the first 6 requirements of the PCI Data Security Standards (DSS). Today we'll finish this series with an explanation of what requirements 7-12 do to protect your clients' cardholder information.

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know

This sounds like a page out of a classic spy novel, but the principle of "need-to-know" is a foundation of good security. Only users who specifically need access to credit card data should have access to the system that contains that data. If a user has access to other parts of the system, then by default they should not have access to unencrypted, sensitive credit card data. Lastly, administrators should grant access to cardholder information only to the minimum number of users who specifically need to see that information for a legitimate business reason that has no alternative.

In Certain Registration, for example, some meeting planners still collect credit card numbers from their attendees in order to "guarantee" their room reservation. These planners need to deliver the unencrypted credit card number to the hotel if the registrant is a "no-show" for the room, thus they have a legitimate business reason to view the full credit card number and their User access can be granted permission to see those numbers. However, all other users will only see the last four digits of the credit card number if they attempt to view the same reports.

In the near future, as more companies adopt PCI compliance, I suspect that no hotels will be willing to receive a list of unencrypted credit card numbers and will thus require room blocks to be guaranteed against the master account. Then the current "legitimate business need" to view these numbers will disappear, and such access can be ended. In this case, the planner can still store the credit card information in encrypted, unreadable format, and they can charge the registrant's card if they are a no-show without any human being able to read the cardholder data.

Requirement 8: Assign a unique ID to each person with computer access

If you are going to restrict access to data via an authentication scheme (such as username/password), then each individual person must have their own authentication. If multiple people share a single username, for example, then the system cannot audit which person made specific actions, only which username made those actions.

In order to make sure that only the intended user has access to a given username / password combination, PCI places multiple restrictions on systems:

• Passwords must be at least 7 characters long, with a combination of alphabetical and numeric characters
• Every 90 days, passwords must be changed and inactive user accounts must be removed
• The user must be authenticated prior to changing or resetting passwords, e.g. by sending a temporary password to the User's email address
• User sessions without activity for 15 minutes must be automatically timed out and require login to re-start

Some of these security requirements, such as the 15-minute timeout rule, can be annoying for users who don't need access to credit card information. Thus our system gives those users the options to adhere to a less restrictive security policy - but they cannot view credit card data. Any user who can view cardholder data must adhere to the PCI guidelines and live with its inconveniences.

Requirement 9: Restrict physical access to cardholder data

PCI requires companies to control physical access to cardholder data; this includes access to the database servers, backup media files (which are often stored offsite), paper hardcopies, etc. Modern Network Operations Centers (NOC), such as ours at NTT Verio, provide this control through 24/7 security, photo-badges with biometric hand scans, individual cages and cabinets, and constant video monitoring.


Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data

PCI requires us to log all activities related to accessing cardholder data, plus all activity related to controlling access to that data. So everytime an Administrator creates a new user with access to cardholder information, we record the action in a log. If a user runs a report with cardholder data, the action (and content of the report) is logged. These logs cannot be deleted by Administrators, and are available online for a year after the action occurred.

Requirement 11: Regularly test security systems and processes

Periodically, security vulnerabilities appear due to new techniques discovered by hackers or researchers or software updates. PCI requires adherants to monitor critical files for changes, scan internal and external network vulnerability quarterly, and perform annual detailed security tests on all systems.

In addition, networks need to have an "Intrusion Detection System" (IDS), which is basically an observation post that watches the data traffic flowing through your network and looks for patterns that indicate malicious data attacks or a security compromise.

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

Companies that collect cardholder information must publish written security policies that adhere to PCI compliance. The policy should be known by all employees and contractors, and any outside vendors who receive cardholder information must also be PCI compliant.

Since most data security breeches are caused by internal behavior, all employees who have access to credit card information in bulk format must be screened prior to hiring. For example, we perform credit checks and criminal checks on employees as part of the hiring process.

PCI Compliance Part 2 - Don't lose that credit card data!

Last week I discussed what PCI Compliance is and where it came from. Today we'll look at the details of the PCI Data Security Standards (DSS) and explain what each standard does to protect your clients' cardholder information. If you want to see how well your organization meets these criteria, contact your registration software provider or conduct the self-assessment questionnaire.

Below are the 12 major requirements of PCI Compliance, described in layman's terms.

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
A firewall is an electronic barrier between the outside world (which is dirty) and your data (which is hopefully clean). Computers and servers are like houses with thousands of windows, called "ports". Data can flow in and out of these ports, for example, web browsers typically use port 80 for "http" requests and port 443 for "https" requests. A firewall is like a window shutter - it provides a barrier to traffic flow on the ports that you don't need to use.

Sophisticated firewalls can even close ports to specific types of data and can provide "dual-zone" protection. A dual zone firewall means that you can have one set of protection for your web servers (which must have ports 80 and 443 open to the world in order to deliver web pages) and a second set of more restrictive protection for database servers (which only need to communicate with the web servers and thus can be closed to the rest of the world). The more ports you close or restrict, the tougher it is for bad guys to get in.

It's like the battle for Helm's Deep in Lord of the Rings - Twin Towers. If the orcs get through the outer defenses, then they still have to breach the walls of the keep in order to get to your people. Yeah - it's exactly like that…

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
This requirement is so obvious that it is painful to write, but a surprising number of web servers use blank or system default passwords for their administrator access. Just ask my neighbor, who purchased a Linksys WI-FI router last year and still doesn't know that I get better access on his network from my laundry room than I do on my own network. (Actually, please don't tell my neighbor.)

Protect Cardholder Data

Requirement 3: Protect stored cardholder data
This requirement is really two parts:

1. You can't store certain types of cardholder data at all, e.g. the CVV/CV2 number or PIN or magnetic stripe contents. You can only use that data one time for authentication, and then must remove the data from memory.


2. Any data that you do store (Cardholder name, card number, expiration date, bank information) must be protected.

At Certain, if we need to store the full credit card number, e.g. because the event planner is going to provide it to the hotel for room guarantee purposes, then we first encrypt it using a 128-bit Blowfish cipher. This is a fancy way of saying that even if a malicious user were to get through our firewall and administrator passwords, then instead of seeing credit card numbers like 4111111111111111, they would get encrypted values like "A29D075CA20EF9E892045671ACBED93D8A". This won't do you a lot of good at Amazon.com.

The PCI standard requires the your encryption key, the code which unlocks the encrypted value, to be stored only in temporary memory. That means that we have to enter the code phrase every time we reboot our servers, and there is nowhere on the physical drives that someone could read this key and decrypt the stored credit card numbers. Furthermore, registrants and administrators only see the last 4 digits of the credit card number on their screen (e.g. ******1111) and even the encrypted card information is deleted 90 days after the event ends.

Requirement 4: Encrypt transmission of cardholder data across open, public networks
Most internet users know the difference between "http" pages, which are transmitted in plain text across the Internet from your browser to the server, and "https" pages, which are encrypted by your browser prior to transmission to the server. Whenever we deal with credit card data, we use an "https" connection. This way if someone were to tap into your data lines and read the information passing between your computer and a web server (which is surprisingly easy to do), then they couldn't get any meaningful information.

Secure connections ("https") require the web site to have a secure certificate, which must be renewed periodically. For example, ours comes from Entrust:



Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software
PCI requires companies to have anti-virus software on all servers and personal computers that collect, store, or transmit cardholder data. Modern anti-virus software is continually updated to protect against new viruses, and it scans the computer's files and data traffic for viruses, spyware, adware, and other undesirable programs that might be trying to collect credit card information for a malicious user.

Requirement 6: Develop and maintain secure systems and applications
Requirement 6 means that software vendors must follow processes that maintain their application at the highest level of security, for example:

• Apply all security patches from software companies within 1 month of release


• Subscribe to alert services for newly-discovered vulnerabilities


• Separate development, test, and production environments


• Develop applications within the best practices of the Open Web Security Project


• Have an outside application security firm review code for common wulnerabilities

I'm tired of writing for today, so we'll cover the last 6 requirements next week.

PCI, FACTA, CISP, SDP - Just don't lose those credit card numbers!

No online service wants to read about themselves in the news under the headline "ACME Web 2.0 loses 350,000 credit card numbers". So I felt a shiver of fear last week when a client told me that our registration application was not FACTA compliant. My fear soon turned to anger, after spending the past six months pushing through new development to achieve Level 1 PCI Compliance, after we decided to move beyond CISP without having to implement SDP.

Lost yet? Well, it turns out that the politicians and various credit card companies each tackled the problem of credit card security separately.

Payment Card Industry Data Security Standards

PCI stands for Payment Card Industry - an association that reflects the combined interests of VISA, MasterCard, Discover, American Express, and JCB to promote financial data security standards. Prior to publication of the PCI Data Security Standards in September 2006, each card brand managed their own set of requirements. I first implemented VISA's Cardholder Information Security Program (CISP) in 2001, and Certain had maintained compliance with it ever since. We were about to embark on MasterCard's program (Site Data Protection or SDP) when the PCI Standard was announced, which obviously saved a lot of time and money for online vendors who accept multiple credit card types.

We fall into the "Level 2" category for PCI Compliance, for processors with between 150,000 and six million annual transactions. Nevertheless, we plan to grow and want to be as secure as practical, so we opted to achieve Level 1 compliance.

There are six categories of PCI compliance security standards, with 12 broad requirements. I'll cover these details another day, but if you want to read ahead there's always the PCI Compliance Guide.

FACTA and Your Taxpayer Dollars at Work

While the five major credit card brands were solving the problem of data security in a way that made business's lives easier, in 2003 Congress passed the Fair and Accurate Credit Transactions Act (FACTA), an amendment to the Fair Credit Reporting Act (FCRA).

Section 113 of FACTA (don't follow that link!) took effect in December 2006, three years after the amendment was passed into law.

SEC. 113. TRUNCATION OF CREDIT CARD AND DEBIT CARD ACCOUNT NUMBERS.
Section 605 of the Fair Credit Reporting Act (15 U.S.C. 1681c) is amended by adding at the end the following:
(g) Truncation of Credit Card and Debit Card Numbers.--
(1) In general.--Except as otherwise provided in this subsection, no person that accepts credit cards or debit cards for the transaction of business shall print more than the last 5 digits of the card number or the expiration date upon any receipt provided to the cardholder at the point of the sale or transaction.

However, page 6 of the PCI DSS self-assessment questionnaire says nothing about expiration dates, but it does ask, "Are all but the last four digits of the account number masked when displaying cardholder data?"

I guess Congress thinks they know more than the businesses whose livelihoods depend on the security of cardholder data, but anyway, after our patch this week the transaction on Certain's confirmation page will change from

Richard Borry (Visa ******1266 exp. 10/08)

to

Richard Borry (Visa exp. 10/08)

and as a result we will be compliant with FACTA, PCI, CISP, and SDP.

The Bottom Line

Enough with the acronyms and anti-government over-regulation diatribe. What I hope you learn is that:

1. Professional web software providers care deeply about the security of your credit card data
2. Companies like Certain spend hundreds of thousands of dollars to adhere to the state-of-the-art standards, and to maintain compliance to those standards as they change
3. You do *not* want to deal with this yourself

Ask your software vendor about PCI Compliance, ask to see an independent audit report, and think twice when your IT group says "No problem" about building an in-house system that will handle credit card data online.

How do web-based event management solutions protect customer data?

Event Solutions magazine requested content for an article about how event management solutions like Register123 help protect customer data, compared to using manual systems like Excel spreadsheets to track financial information, credit cards, personal data, etc. While I cannot tout specific Register123 features in a contributed article, I can do that here.

The short answer to this question is that, compared to manual systems like Excel, Register123:

• Collects data safely
• Transfers data safely
• Stores data safely
• Monitors potential vulnerabilities better

Data Collection
Online registration systems collect private and financial data more securely than do paper, email, or phone processes. With Register123, registrants can submit credit card payments without any human (other than themselves) seeing the cardholder information. With traditional systems, someone within the event management office must receive and reenter the credit card information into their transaction system.

Data Transfer
Another threat to private information is during data transfer between parties. R123 transfers data using 128-bit encryption standards via https, so that only the sender and recipient can read the information. With email, flash drives, and paper files, data can be read by anyone who happens to see it in transit between the two parties.

Data Storage
Register123 stores data more securely than do typical computer systems. Credit card numbers are encrypted prior to storage in the database and are deleted physically 90 days after the event ends. Card security codes (CVV numbers) are never stored, and address verification is used to validate cardholder authenticity. Our database is located behind a dual-zone firewall, and undergoes continuous intrusion detection, anti-virus protection, physical security, and anti-hacker monitoring. This storage environment is much more save then the typical event management practice of storing data in unencrypted Excel spreadsheets on desktops that don’t use file-level password protection.

Vulnerabilities
The greatest threat to personal and financial data is through human error and theft. With Register123, all data is stored securely in a central location, which is less vulnerable to data theft compared to files stored on easily-stolen laptops or desktop PCs with screens that are visible to any passer-by.

Certain Software and other organizations that adhere to the Payment Card Industry (PCI) standards must perform background and credit checks on all employees, and we must "silo" data access on an "as needed" basis. This level of human security is closer to that found in banks and other financial institutions that deal with PCI standards, and the result is higher data security when compared to the typically open environment of many event management organizations.

In addition to monitoring human vulnerabilities, Certain subscribes to anti-virus and anti-hacking programs that daily update known technical vulnerabilities. Our server farm also has an intrusion detection routine that looks for suspicious behavior on our network and alerts our team if something is amiss.

Scalability - How to keep data flowing as registration volume increases

I spent two drizzly days in Seattle last week visiting some of our best clients, including Weyerhaeuser and Safeco. With our phenomenal growth over the past two years (we've processed over 2.7 million registrations in 2006 - already twice as much as last year), we continually have to upgrade our servers and network equipment in order to handle the increased load. So what can we do to make sure that registration forms respond quickly when 10,000 people try to log onto the system at the same time?

The first thing to realize is that event registration is a very demanding web-based process. A single page of an online registration form will require 10-100 times as much computer processing power as a single page of a content-driven web site such as Yahoo! This is because registration systems involve a great deal of data storage and retrieval, while news sites simply deliver static web pages to viewers.

So to keep the registrations flowing, we have to eliminate bottle-necks at every step of the process:

1. Registrant requests a page from their browser
2. Certain's servers receive the request and pass it to one of several web servers
3. The web servers handle the request and retrieve and store data into the database
4. The database server processes individual queries to read or write information
5. Backup systems make copies of the data to disc and magnetic tape
6. Security systems monitor the process to prevent unauthorized intrusion

All of this processing must occur within about a half-second, or the registrant will "feel" like the system is sluggish.

So to go from a million registrations per year to two million, to four million, to ten million, we continue to make large investments in our network operations.

Network

The first requirement is to make sure that data can get in and out of our servers fast enough to handle all incoming page requests. Internet "bandwidth" is a measurement of how much data can be transmitted in a given period of time. Internet Service Providers (ISP) measure bandwidth by both average usage and peak usage. For example, in September 2006 we increased our bandwidth from "1/10" to "2/100". This means that we pay for a monthly average usage of 2 Mbps (Megabits per second), but we are allowed to use up to 100 Mbps during peak periods.

For comparision, an average web page has about 100 Kb (kilobytes) of text and images. That means that the web server had to deliver 100,000 bytes, or about 800,000 bits since there are 8 bits in a byte. (Note that these calculations aren't exact, due to various small descrepancies between measuring systems of disc, computer, and network engineers.) With a million bits in a megabit, you would need 0.8 Mbps to receive the page in a second. High definition digital cable requires about 20 Mbps to deliver HD movies to your monitor.

Our current daily average bandwidth usage is just over 1 mbps, and our peak usage is around 15 mbps, so we have plenty of room for future growth and spike loads.

Software Foundation

Another way to improve performance is to upgrade the underlying software that the web and database servers use to deliver the page requests. We currently are upgrading our database servers from 32-bit Microsoft SQL Server 2000 to 64-bit Microsoft SQL Server 2005. This allows the database to process requests for information much faster. In addition, SQL Server 2005 allows for simple configuration of clusters of multiple servers. Instead of using one database server for processing and another as a backup in case of failure, we can use the processing power of multiple servers, which improve performance during normal operation and provide for redundancy during periods of failure.

Data Storage

With a data intensive application such as online registration, the overall performance can be limited by how fast the servers can read and write the data to disk. We are implementing high-speed Storage Area Networks (SAN), which improve speeds by orders of magnitude for more rapid read/write actions to discs and for database transaction log backups.

Application Architecture

Once the network, hardware, and software foundations are ready for high performance, it's up to the application to deliver.

• First, we are modifying Register123 to “cache” information, such as event and form configuration, that does not frequently change. Data stored in the cache is located in the ultra-fast memory of web servers, so when a page request comes in, the information can be delivered immediately instead of requiring a round-trip request to the (relatively) slower database servers. The specifics of caching are complex, but basically if the information has changed, then the web servers will automtically update the information in the cache from that in the database (this is called "refreshing the cache"). Caching will reduce database utilization by up to 35% per page without any sacrifice to the Users' experience.
• Second, we are going to implement a queue system for incoming requests. During the vast majority of time, registrations will be handled immediately when our servers receive the request. But in rare periods of exceptionally high demand (when database utilization exceeds 75%), incoming requests will be placed in a queue and handled on a “first-come, first-served” basis. While in the queue, registrants will see a “System Processing” message, much like the ones on online travel sites that so many Internet users have seen before. Their total wait time will be a few seconds (depending on system load), which is vastly superior to not being able to access the system at all.

Performance improvement is a never-ending battle with increasing registration volume. It is one that Certain Software is committed to win.