A teachable moment is that moment when a unique, high interest situation arises that lends itself to serious discussion of a particular topic.

During HITEC, Reneta McCarthy, a senior lecturer at Cornell University’s School of Hotel Administration, told Hospitality Upgrade magazine a story she was directly involved in. When the dust settled, our heads were spinning and HU Publisher Rich Siegel said, “What a genuine teachable moment.” When you hear this true story, you will agree; it is long overdue for thoughtful industry exploration.

Early June 2015, an undergrad student who McCarthy was advising was researching property management systems as part of a summer internship and came across a free, cloud-based property management system (PMS) with all the bells and whistles available to any hotel willing to join a particular brand. This freebie warranted investigation. Following the Web links in press releases, it was easy to download the free .exe software and set up what appeared to be the demo. Once installed, the window prompted for a username and password, so a simple choice was made: “Admin” for username and “Admin” for password. And, as Ali Baba said, “open sesame!” The passwords worked like a charm.
 
Once logged in, the student did a double take. There were multiple tabs containing full credit card numbers related to guest profiles. You read that right! The numbers were displayed in their entirety, unencrypted and including expiration dates, names and address information (personally identifiable information or PII).

The student wondered if this was legitimate and clicked through multiple screens that seemed to allow access to information for past, present and future guests of at least 50 hotels. Were they real hotels or dummy hotels for a demo? Through a series of creative Web searches he confirmed the hotels and guest reservations were real.

Clicking further, incredulously, each hotel had several user accounts designated as owner/administrator. Again, very alarming. Best practice suggests there should only be one person for an entire group with owner or super admin rights since it confers the right to create new user accounts and change passwords. This was not intentional or malicious but the implications were huge; one could change passwords and lock all users out.
 
Anyone with owner privileges at any of the properties could do the same to others. Worse still, all users at some properties were pegged as “owner.” The student had unintentionally discovered a major vulnerability and had logged into a real PMS as the administrator.
 
Shaken by this realization, he logged out immediately and (even though it was almost 1:00 a.m.) emailed McCarthy with a step-by-step narrative of what had just taken place. McCarthy read the email the next morning. She found it unimaginable that her student had penetrated a major system and decided to replicate the experience using the steps outlined in the email before responding. She viewed similar screens, and knowing the card data and PII was unprotected, quickly logged out and picked up the phone to call the CEO of the group. She also sent an email to the hotel group to alert it of the problem.

Although no extraction of data or PII was performed by the student or the educator, one has to ask whether they are the only ones to have ever gotten into this PMS via the supposed demo link. Given how easily it happened, others may have infiltrated this PMS. What if someone with malicious intent gained access to these records?

Let’s look at the incident closely. How could it occur in the first place? What are the implications of this flaw? As part of the investigation we spoke to a variety of industry experts on the matter with three goals: 

1 Help hoteliers understand shared responsibility and password management.
2 Help technology players understand they are not only endangering their own company’s viability but also that of their clients if they are not taking security responsibilities seriously.
3 Review how to react when someone finds a vulnerability and tells you about it.

Review the Basics
Payment Card Industry Data Security Standard (PCI DSS) comprises a minimum set of requirements for protecting cardholder data and applies to all entities involved in payment card processing. The definition of “entity” includes the merchant of record defined here as the hotel who takes payment for a guest stay via credit card, as well as everyone the hotelier works with either directly or indirectly for that reservation as it is attached to a card that guarantees the room or prepaid the room.
 
Any technology that stores, processes or transmits cardholder data (CHD) such as payment processors, acquirers, issuers, Internet booking engines (IBE), central reservation systems, OTAs, PMSs and GDSs, attaches credit cards to confirmations. The PCI council views all aforementioned parties as subject to the requirements because each system either transmits or stores cardholder information.
 
The latest iteration of the PCI DSS (version 3.1) places heavy focus on shared responsibility and password management.

First let’s examine shared responsibility. In this situation, the member hotels of this brand are using technology (a cloud-based PMS) that stores credit card data of their guests. PCI DSS clearly demands the hotel share responsibility for the security of its guest’s card data with the PMS (provider of the technology) as opposed to the old approach of outsourcing (offloading) it to someone else to manage.

All experts interviewed agreed on this point: It does not matter if the hotel using the cloud-based PMS (or any technology for that matter) is part of a membership group, a soft brand or is part of a chain acting as a franchisee; in fact all of those as well as those owned and/or operated by a brand are in the same basket. Furthermore it does not matter if the hotelier knows about PCI DSS or the concept of shared responsibility. If and when guest data is compromised, they cannot use ignorance as a defense and they will be examined as partially responsible.

Understanding that while PCI is not law, there is law involved. The hotel has a legally binding contract with the various banks/card issuers that they signed and must honor so that they can accept credit cards for payment; these contracts demand the merchant be consciously involved in protecting the card data. If the hotel uses a product or works with a company that is not compliant with PCI standards, the merchant could be viewed as not compliant, putting it at risk of breaching the contract with the card companies.

The concept is even more explicit when using cloud-based services. Why? Because when any payment card data is stored, processed or transmitted in a cloud environment, PCI DSS will apply to that environment, not just the system itself. Translation: PCI DSS now requires validation of both the cloud service provider’s infrastructure and the client’s usage of that environment.

It gets even more complex: the hotel brand in this story has a formal agreement with a cloud-service provider (CSP) to extend this PMS technology to its membership base “at no cost” as a benefit. In reality the PMS is remunerated from a percentage of membership fees collected on each booking by the hotel group. Several lawyers indicated the membership group had selected the PMS vendor, endorsed it and set up its members, therefore clearly sharing responsibility for the security of the system. The system stores guest card data for its members’ reservations and is offered as a value add for membership, and money collected then is used to compensate the PMS for what appears to be a free benefit of membership.

Finally it is not unrealistic to expect a certain amount of hotel reservations take place on the website of the brand itself or via the GDS that the brand’s CRS accepts reservations from, and these bookings pass to the PMS under the brand’s code.

Lesson No.1
Even if the technology is not yours and not under your supervision, you cannot say you are absolved of liability if the entity storing the data about your guests is insecure or noncompliant or worse, is breached. The PCI DSS is absolutely clear about this matter. 

When you buy a briefcase or suitcase with a combination lock, typically it is preset at “000” and you reset it to your preferences. This is what is known as a vendor default password. PCI requirement No. 2 states, “Changing default passwords is required for application/service accounts as well as user accounts.”

Many vendors’ products in several industries come preconfigured with default (and thus well-known) usernames and passwords like “Admin, Admin,” but they should be deleted prior to usage in a production environment. It is a common mistake to forget to remove these default login credentials at launch. 

In the case of McCarthy’s experience, it is a big mistake that either the account manager at the PMS or the hotel group advisor who set up any of the members appears to have made. Several experts have insisted that someone at both companies could have or should have caught it. Both had the means to be alerted. Leaving default passwords in place for more than two years is a major mistake that allowed at least two unauthorized people (that we know of) to view unencrypted cardholder data on the PMS. How many other chains, groups or brands are using the PMS? 

Do not let the focus on PMS be the story here. From a point-of-sale system in a restaurant (e.g., Verifone swipe terminals, Aloha terminals, etc.) to a website e-commerce shopping cart (e.g., CreLoaded, osCommerce, etc.), from a PMS or GDS to a CRS or IBE, all are payment applications. PCI DSS 3.1 takes a clear position on vendor default passwords.

In April of 2008, hackers gained access to Wyndham’s system through a single computer in one of Wyndham’s franchised hotels that an employee at the property had connected to the Internet. This computer was also connected to Wyndham’s property management and reservation system. The hackers worked with administrator passwords and access codes, giving intruders a ready pipeline. When companies have such poor password hygiene, hackers do what hackers do. In that breach, within approximately one month, hackers had been able to compromise the computer systems of 41 different properties, which are fewer hotels than the Cornell student and McCarthy had unknowingly accessed. And it took Wyndham a number of months to recognize that the intrusion had occurred. The hotel membership group management claimed it was not its fault or responsibility as it did not own or operate the properties where the breach took place and the staff there were not employees.

In its original lawsuit, the FTC accused Wyndham of a litany of privacy failures, from storing unencrypted credit card information to lacking firewalls to using easily guessed passwords. The latest developments in FTC v. Wyndham announced in late August mean that the FTC has the teeth to go after and will continue to go after the brand whose PMS was accessed despite the argument that the brand can’t dictate compliance to property owners.
Technology companies and hotels, as you read this it bears repeating.

Lesson No. 2
If you are not stepping up your due diligence and security validation/certification and assessments of technology, you are endangering your own company’s viability as well as that of those with which you work, not to mention the data of millions of hotel guests (past, present and future).

Had this been a malicious incident, all three parties (the hotel, the membership group executives who signed the agreement with the hotel and the PMS and the management of the PMS technology) would be parties to a lawsuit (see sidebar), and while everyone would be pointing fingers at the other the card companies, would take the small independent mom and pop member hotelier directly to the cleaners. Taking the security responsibility concept seriously is no longer a compliance strategy but a survival strategy, aimed in part at reducing liability.

Lesson No. 3
Proactive preparation and education of everyone about contracts that relate to the use of a system that stores and/or transmits guest data and card data is of utmost urgency.

The member hotels on the brand’s PMS have full recourse against the brand for supplying technology that was proven to be insecure and noncompliant; the brand or membership group would have full recourse against the PMS for design flaws and lack of training. All the FTC is interested in is that the guest (whose data was compromised) doesn’t know or care about how the hotel where they stayed is connected to the brand. The two are viewed as the same even though those of us in the industry know that the brand does not own or operate the property, and as such is not able to dictate to them. In this case the PMS is compensated by funds paid to the membership office, which may or may not share in the revenues, and therefore are parties to the incident.

Finally if a system is inappropriately accessed, do you have any way of knowing? In this case the only way The X Hotel Group heard about it was that it was notified by an ethical professor. We found the hotel group’s reaction to the revelation shocking. The professor was treated as though she was going to extort or hold the brand hostage in some way, or even worse, as though the student had not really gotten into the system. This just further proves that this teachable moment cannot go unnoticed or unreported. There were many who referred to the concept of responsible disclosure and thought this matter should stay internal and not be exposed.

There seems to be an ongoing, almost incessant debate about the concept of responsible disclosure and whether it’s helpful or not for white hat hackers and other security researchers to publicly reveal details about the information security vulnerabilities they find. According to Tal Klein, a leading writer about white hat hacking, disclosure is an incredibly valuable tool that ensures infrastructure remains reliable.

He reminds us that we’ve been grappling with the problem of information security for a lot longer than two decades, and to drive his point home, shared a telling excerpt from the book, “Locks and Safes: The Construction of Locks” by A. C. Hobbs, published in 1853.

Where things get really interesting is when you start to think at cloud scale. For example, if we solve for patching by delivering software as a service, what happens when one finds vulnerability? Ostensibly if the vendor doesn’t fix it and the vulnerability is published, is the person who discovered it (or in this case reported about it in a trade magazine) actively harming every single one of that vendor’s customers? The question becomes who is to blame: The person who found the vulnerability or the vendor that failed to patch it?

Why does it always end up being a blame game? Who is to blame here? The X Hotel Group (a membership type of entity) or the mom-and-pop hotelier who wanted to save money and bought membership in part because of the value added benefits of what was sold to them as a secure PMS? The PMS vendor who may not actually be complying with PCI DSS getting a Payment Application certification? The writer of this article or the student?

We can spend a thousand and one nights talking about it. The hackers are already in systems in a thousand and one ways. Let the teachable moment be the story that if an undergraduate got in so easily, Ali Baba’s 40 thieves have been in and done the damage, and that should keep us all up a thousand nights. 

Marion Roger, VP Hospitality eResources, is a specialist in the hospitality supply chain landscape who is currently leading an industry initiative to support guest data security and has developed a hotel-focused training curriculum on PII protection.