NIST SPECIAL PUBLICATION 1800-27B


Securing Property Management Systems


Volume B:

Approach, Architecture, and Security Characteristics



William Newhouse

Information Technology Laboratory

National Institute of Standards and Technology


Michael Ekstrom

Jeff Finke

Marisa Harriston

The MITRE Corporation

McLean, Virginia



March 2021


FINAL


This publication is available free of charge from

https://doi.org/10.6028/NIST.SP.1800-27


The first draft of this publication is available free of charge from https://www.nccoe.nist.gov/projects/use-cases/securing-property-management-systems



nccoenistlogos




DISCLAIMER

Certain commercial entities, equipment, products, or materials may be identified by name or company logo or other insignia in order to acknowledge their participation in this collaboration or to describe an experimental procedure or concept adequately. Such identification is not intended to imply special status or relationship with NIST or recommendation or endorsement by NIST or NCCoE; neither is it intended to imply that the entities, equipment, products, or materials are necessarily the best available for the purpose.

National Institute of Standards and Technology Special Publication 1800-27B, Natl. Inst. Stand. Technol. Spec. Publ. 1800-27B, 61 pages, March 2021, CODEN: NSPUE2

FEEDBACK

As a private-public partnership, we are always seeking feedback on our practice guides. We are particularly interested in seeing how businesses apply NCCoE reference designs in the real world. If you have implemented the reference design, or have questions about applying it in your environment, please email us at hospitality-nccoe@nist.gov.

All comments are subject to release under the Freedom of Information Act.

National Cybersecurity Center of Excellence
National Institute of Standards and Technology
100 Bureau Drive
Mailstop 2002
Gaithersburg, MD 20899

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE

The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and academic institutions work together to address businesses’ most pressing cybersecurity issues. This public-private partnership enables creation of practical cybersecurity solutions for specific industries, as well as for broad, cross-sector technology challenges. Through consortia under Cooperative Research and Development Agreements (CRADAs), including technology partners—from Fortune 50 market leaders to smaller companies specializing in information technology security—the NCCoE applies standards and best practices to develop modular, easily adaptable example cybersecurity solutions using commercially available technology. The NCCoE documents these example solutions in the NIST Special Publication 1800 series of practice guides, which maps capabilities to the NIST Cybersecurity Framework and details the steps needed for another entity to re-create the example solution. The NCCoE was established in 2012 by NIST in partnership with the State of Maryland and Montgomery County, Maryland.

To learn more about the NCCoE, visit https://www.nccoe.nist.gov. To learn more about NIST, visit

NIST CYBERSECURITY PRACTICE GUIDES

NIST Cybersecurity Practice Guides (Special Publication 1800 series) target specific cybersecurity challenges in the public and private sectors. They are practical, user-friendly guides that facilitate the adoption of standards-based approaches to cybersecurity. They show members of the information security community how to implement example solutions that help them align with relevant standards and best practices, and provide users with the materials lists, configuration files, and other information they need to implement a similar approach.

The documents in this series describe example implementations of cybersecurity practices that businesses and other organizations may voluntarily adopt. These documents do not describe regulations or mandatory practices, nor do they carry statutory authority.

ABSTRACT

Hotels have become targets for malicious actors wishing to exfiltrate sensitive data, deliver malware, or profit from undetected fraud. Property management systems, which are central to hotel operations, present attractive attack surfaces. This example implementation strives to increase the cybersecurity of the property management system (PMS) and offer privacy protections for the data in the PMS. The objective of this guide was to build a standards-based example implementation that utilizes readily available commercial off-the-shelf components that enhance the security of a PMS.

The NCCoE at NIST built a PMS reference design in a laboratory environment to demonstrate methods to improve the cybersecurity of a PMS. The PMS reference design included the PMS, a credit card payment platform, and an analogous ancillary hotel system. In this example implementation, a physical access control system was used as the ancillary system.

The principal capabilities include protecting sensitive data, enforcing role-based access control, and monitoring for anomalies. The principal recommendations include implementing cybersecurity concepts such as zero trust architecture, moving target defense, tokenization of credit card data, and role-based authentication.

The PMS environment outlined in this guide encourages hoteliers and similar stakeholders to adopt effective cybersecurity and privacy concepts by using standard components that are composed of open-source and commercially available components.

KEYWORDS

access control; hospitality cybersecurity; moving target defense; PCI DSS; PMS, privacy; property management system; role-based authentication; tokenization; network security; zero trust architecture

ACKNOWLEDGMENTS

We are grateful to the following individuals for their generous contributions of expertise and time.

Name

Organization

Sapna George

Cryptonite

Hans Ismirnioglou

Cryptonite

Mike Simon

Cryptonite

Rich Walchuck

Cryptonite

Justin Yackoski

Cryptonite

Katherine Gronberg

Forescout

Timothy Jones

Forescout

Scott Morrison

Forescout

John Bell

AjonTech LLC

Shane Stephens

Forescout

Oscar Castiblanco

Häfele

Ryan Douglas

Häfele

Chuck Greenspan

Häfele

Sarah Riedl

Häfele

Harald Ruprecht

Häfele

Roy Wilson

Häfele

Kartikey Desai

MITRE

Eileen Division

MITRE

Karri Meldorf

MITRE

Paul Ward

MITRE

Trevon Williams

MITRE

Kevin Garrett

Remediant

Paul Lanzi

Remediant

Nicole Guernsey

StrongKey

Pushkar Marathe

StrongKey

Arshad Noor

StrongKey

Bill Johnson

TDi

Pam Johnson

TDi

The Technology Partners/Collaborators who participated in this project submitted their capabilities in response to a notice in the Federal Register [B1]. Respondents with relevant capabilities or product components were invited to sign a Cooperative Research and Development Agreement (CRADA) with NIST, allowing them to participate in a consortium to build this example solution. We worked with:

Technology Partner/Collaborator

Build Involvement

Cryptonite

network protection appliance that provides additional layer of protection against cyber attacks

ForeScout

policy-based control enforcement for guest Wi-Fi networks and visualizations of diverse types of network-connected devices

Häfele

physical access control system, including door locks, room-key encoding, and management

Remediant

real-time incident monitoring and detection, privilege escalation management, and reporting functions

StrongKey

payment solution appliance that secures credit card transactions and shrinks the Payment Card Industry compliance enclave

TDi

access control platform that secures connections and provides control mechanisms to enterprise systems for authorized users and authorized devices; also monitors activity down to the keystroke

List of Figures

Figure 4‑1 Secure PMS High-Level Architecture

Figure 4‑2 Staff Process Flow

Figure 4‑3 Secure Credit Card Process Flow

Figure 4‑4 Secure Interaction of Ancillary System with PMS Process Flow

Figure 4‑5 Guest Internet Access Via Guest Wi-Fi Process Flow

Figure 5‑1 Tenets of Zero Trust

Figure 5‑2 Components of Zero Trust

List of Tables

Table 4‑1 Components, Functions, Technologies

Table 5‑1 Zero Trust Tenets/Components/Cybersecurity Framework Subcategories

Table 5‑2 Zero Trust Component and PMS Reference Design Component Mapping

Table 7‑1 Test Case Fields

Table 7‑2 Functional Analysis Requirements

Table 7‑3 Authorized User Can Log In

Table 7‑4 PMS Authentication

Table 7‑5 No Unauthorized Lateral Movement

Table 7‑6 Prevent Unauthorized Function

Table 7‑7 Only Authorized Data

Table 7‑8 Guest Reservation Editable

Table 7‑9 Provisioning Room Key

Table 7‑10 Guests’ Limited Wi-Fi Access

Table 7‑11 Prevent Unauthorized Guest Lateral Movement via Wi-Fi

Table 7‑12 Tokenized Credit Card Data

Table 7‑13 Verify that Credit Card Data Is Hidden

Table 7‑14 Authorized Device Provisioning

Table 7‑15 Prevent Unauthorized Device from Connecting

Table A‑1 Securing Property Management Systems: NIST Cybersecurity Framework Components Mapping

Table B‑1 Securing Property Management Systems: NIST Privacy Framework Components Mapping

1 Summary

Hotel operators rely on a property management system (PMS) for daily administrative tasks such as reservations, availability, pricing, occupancy management, check-in/out, guest profiles, guest preferences, report generation, planning, and record keeping, which includes financials. This PMS controls the on-site property activities for guests and colleagues and connects with other applications such as the hotel point-of-sale (POS) and central reservation system (CRS), which support availability, reservations, and guest profile information.

Additionally, various interfaces are available to create further links from the PMS to internal and external systems such as room-key systems, restaurant and banquet solutions, sales and catering applications, minibars, telephone and call centers, revenue management, on-site spas, online travel agents, guest Wi-Fi, loyalty solutions, and payment providers.

The value of the data in a PMS and the number of connections to a PMS make it a target for bad actors. This guide documents a system that prevents unauthorized access to a PMS and applies both security and privacy protections to the data used in the PMS.

1.1 Challenge

Volume A of this publication described why the National Cybersecurity Center of Excellence (NCCoE) accepted a hospitality cybersecurity challenge as a project. Here, in Volume B, the focus shifts to the challenge of building an example implementation that offers hotel owners and operators some options to secure their property management systems.

Securing Property Management Systems supports the following security and privacy characteristics:

  • prevents unauthorized access via role-based authentication

  • protects from unauthorized lateral movement and privilege escalation attacks

  • prevents theft of credit card and transaction data via data tokenization, explicitly allows only identified entities access (allowlisting), and enables access control enforcement

  • increases situational awareness by auditing, system activity logging, and reporting

  • prevents unauthorized use of personal information

To build the example implementation, hereafter known as the PMS reference design, the project collaborators reached consensus on an architecture that implements aspects of a zero trust architecture (ZTA), moving target defense (MTD), and data tokenization to reduce cybersecurity risk for a hotel’s PMS.

1.2 Implementation

The project demonstrates to hospitality organizations how to protect against loss and misuse of customer data and how to provide more cybersecurity and privacy for guest Wi-Fi networks, employee workstations, and electronic door locks.

Best practices for network and enterprise cybersecurity as put forth by the collaborators include role-based access control, allowlisting, data tokenization, and privileged access management. Utilizing these tenets, theft of credit card and transaction data is prevented. Allowlisting is the practice of listing entities that are granted access to a certain system or protocol. When an allowlist is used, all entities are denied access, except those included in the allowlist.

The PMS reference design enables and enforces role-based access control to define exactly who or what will be allowed to make connections within the PMS reference design. ZTA utilizing dynamic provisioning specifies permitted connections and data transactions. Privileged access management defines, enforces, and monitors the privileges for each user, machine, and data transaction.

The NCCoE PMS reference design includes three types of authorized users: hotel guests, hotel staff, and system administrators. Each user has defined access privileges in the simulated hotel environment. Guests can connect to the internet via the Wi-Fi. Staff are allowed authorized access for only the systems and applications needed to perform their work and are not allowed to make any connections outside the scope of their role. System administrators are granted back-end access, but only for the systems and applications they provision, maintain, and troubleshoot.

1.2.1 PMS Reference Design

Within the constructed PMS reference design in this guide, registered hotel guests can connect to the internet via the guest Wi-Fi. Registered hotel guests attempting to connect to the internet will initially be challenged to provide a response, which is validated against information from their reservation. Once validated, the guest is able to connect to the internet and any public-facing hotel websites or guest service portals but is not able to discover other devices using the guest Wi-Fi, which could also be used to support hotel operations and guest-facing Internet of Things (IoT) devices.

The PMS reference design represented in the example implementation constantly changes the internet protocol (IP) addresses of devices, enabling a moving target defense tactic that is transparent to the staff. They can reach the systems that allow them to perform their work while the defense tactic hinders lateral movement of attackers, who will be challenged to achieve and maintain persistent access.

In developing the hotel PMS reference design, some of the tenets of zero trust were adopted. This resulted in secure, authorized, dynamic access to data or resources on a per-transaction, per-user, and per-system basis, based on factors such as device health and hygiene and other cybersecurity considerations.

The PMS reference design includes a network protection device and an access control platform to support privileged access management. Adding a wireless protection and visibility platform enables allowlisting, network segmentation, and role-based authentication to the Wi-Fi. All access to resources is granted on a per-connection basis, based on a security policy.

1.2.2 Standards and Guidance

In developing the PMS reference design, we were influenced by standards and guidance from the following sources, which can also provide an organization with relevant standards and best practices:

Note: The titles of some of the documents below include the following acronyms: HTNG, which stands for Hospitality Technology Next Generation; EMV originally stood for Europay, Mastercard, and Visa, the three companies that created the standard; PCI, which stands for Payment Card Industry; and GDPR, which stands for General Data Protection Regulations

  • HTNG: Secure Payments Framework for Hospitality, version 1.0, February 2013 [B2]

  • HTNG: Payment Tokenization Specification, February 21, 2018 [B3]

  • HTNG: Payment Systems & Data Security Specifications 2010B, October 22, 2010 [B4]

  • HTNG: EMV for the US Hospitality Industry, October 1, 2015 [B5]

  • PCI Security Standards Council: Understanding the Payment Card Industry Data Security Standard, version 3.2.1, May 2018 [B6]

  • HTNG: GDPR for Hospitality, June 1, 2019 [B7]

  • National Institute of Standards and Technology (NIST) Cybersecurity Framework, April 2018 [B8]

  • NIST Special Publication (SP) 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, September 2020 [B9]

  • NIST SP 800-63-3, Digital Identity Guidelines, June 22, 2017 [B10]

  • NIST SP 800-181 Rev 1, Workforce Framework for Cybersecurity (NICE Framework), November 2020 [B11]

  • NIST Privacy Framework: A Tool for Improving Privacy Through Enterprise Risk Management, Version 1.0, January 16, 2020 [B12]

  • NIST SP 800-207, Zero Trust Architecture, August 2020 [B13]

  • Trustwave Holdings: 2019 Trustwave Global Security Report [B14]

1.3 Benefits

The NCCoE’s practice guide Securing Property Management Systems can help an organization:

  • reduce the risk of a network intrusion compromising the PMS and preserve core operations if a breach occurs

  • provide increased assurance for protecting hotel guest information

  • ensure that only hotel staff with a business need are given access to the PMS

  • increase overall PMS security situational awareness and limit exposure of the PMS to incidents in systems that interface with it

  • avoid exploitations that decrease consumer confidence of the property owner, chain, or industry

  • increase consumer confidence in the protection of sensitive consumer data

In the hospitality space, cost is a major driving factor for many enterprise decisions, so the example implementation documented in this guide is designed to be modular. The PMS reference design documented here offers opportunities for an organization to choose only those components of the implementation that fit its enterprise.

2 How to Use This Guide

This NIST Cybersecurity Practice Guide demonstrates a standards-based reference design and provides users with the information they need to replicate a more secure PMS. This reference design is modular and can be deployed in whole or in parts.

This guide contains three volumes:

  • NIST SP 1800-27A: Executive Summary

  • NIST SP 1800-27B: Approach, Architecture, and Security Characteristics–what we built and why (this document)

  • NIST SP 1800-27C: How-To Guide–instructions for building the example implementation

Depending on your role in your organization, you might use this guide in different ways:

Business decision makers, including chief security and technology officers, will be interested in the Executive Summary (NIST SP 1800-27A), which describes the:

  • challenges that enterprises face in making a PMS more secure and protective of privacy

  • example implementation built at the NCCoE

  • benefits of adopting the example implementation

Technology or security program managers who are concerned with how to identify, understand, assess, and mitigate risk will be interested in this part of the guide, NIST SP 1800-27B, which describes how the PMS reference design mitigates risk.

The following sections may be of interest to users of risk management and privacy frameworks:

  • Section 3.4, Risk Assessment, describes the risk analysis performed.

  • Section 3.4.3, Cybersecurity Control Map, maps the security characteristics of this example implementation to cybersecurity standards and best practices.

  • Section 6.2, Privacy Protections of the Reference Design, describes how we used the NIST Privacy Framework Subcategories.

Technical-savvy readers who wish to implement the security offered in this document might benefit by sharing not only this document but also the Executive Summary, NIST SP 1800-27A, with leadership to push for resources needed to secure the PMS and reduce risk.

Information technology (IT) professionals who want to implement an approach like this will find the whole practice guide useful and will find the how-to portion of the guide, NIST SP 1800-27C, to have all the details that would allow replicating all or parts of the PMS environment built for this project. The how-to guide provides specific product installation, configuration, and integration instructions for implementing the example implementation—in this case, a functioning PMS environment.

This guide assumes that IT professionals have experience implementing security products within the enterprise. While we have used a suite of commercial products to address this challenge, this guide does not endorse these products. An organization can adopt this example implementation or one that adheres to these guidelines in whole, or this guide can be used as a starting point for tailoring and implementing parts of a more secure PMS. Your organization’s security experts should identify the products that will best integrate with your existing tools and IT system infrastructure. The NCCoE encourages organizations to seek products that are congruent with applicable standards and best practices. Section 4-1, Architecture Description, lists the products in this project’s PMS environment and maps them to the cybersecurity controls provided by this example implementation.

Acronyms used in figures are in the List of Acronyms appendix.

2.1 Typographic Conventions

The following table presents typographic conventions used in this volume.

Typeface/ Symbol

Meaning

Example

Italics

file names and path names;

references to documents that are not hyperlinks; new terms; and placeholders

For language use and style guidance, see the NCCoE Style Guide.

Bold

names of menus, options, command buttons, and fields

Choose File > Edit.

Monospace

command-line input, onscreen computer output, sample code examples, and status codes

Mkdir

blue text

link to other parts of the document, a web URL, or an email address

All publications from NIST’s NCCoE are available at https://www.nccoe.nist.gov.

3 Approach

This practice guide highlights the approach that the NCCoE used to develop the example implementation. The approach includes a risk assessment and analysis, logical design, example build development, testing, and security control mapping.

The NCCoE worked with hospitality organizations, such as the American Hotel & Lodging Association and HTNG, to identify the need for an example implementation that improves the security of connections to and from the POS and PMS and other integrated services and components. These organizations, along with the Retail and Hospitality Information Sharing and Analysis Center, offered opportunities for the NCCoE to discuss this project and solicit input from stakeholders used to shape this effort.

In developing the example implementation, the NCCoE:

  • met with hospitality entities and stakeholders such as hotel operators and managers to identify cybersecurity challenges with property management systems

  • regularly interacted with members of the NCCoE Hospitality Community of Interest to discuss current cybersecurity trends and challenges

  • received input from the collaborators participating in the project documented by this guide

    • The collaborators provided technologies to address the project’s requirements and partnered in developing the PMS built for this project.

  • implemented stronger security measures within and around the PMS through network segmentation, point-to-point encryption, data tokenization, and business-only usage restrictions

    • We considered including analytics and multifactor authentication but did not include these security measures in the PMS reference design.

3.1 Audience

This practice guide is intended for any hospitality stakeholder concerned about and/or responsible for securely implementing and mitigating risk in and around a PMS. This includes system owners; IT and cybersecurity engineers, specialists, and technicians; hoteliers; and cybersecurity vendors.

Cybersecurity specialists, in particular, may find this document useful for its focus on the following:

  • preventing unauthorized access via role-based authentication

  • protecting against unauthorized lateral movement and privilege escalation attacks

  • preventing theft of credit card and transaction data via data tokenization

  • allowing only identified entities access by providing access control enforcement

  • increasing situational awareness by auditing, system activity logging, and reporting

  • preventing unauthorized use of personal information

The technical components of this guide will appeal to those who are directly involved with or oversee the PMS and its connections.

3.2 Scope

This project is focused on increasing cybersecurity and privacy of a PMS environment. This includes protecting the data moving between ancillary systems such as a POS, physical access control systems, and hotel guest Wi-Fi as well as data at rest within components of the PMS environment.

After an open call in the Federal Register [B1] inviting vendors to become collaborators, the project was scoped to create a PMS reference design that offers the following:

  • protection against loss of customer data

  • cybersecurity situational awareness

  • cybersecurity for ancillary systems such as hotel guest-facing Wi-Fi networks, hotel staff workstations, and electronic door locks

We considered the following areas and determined they are outside the scope of what we documented in this project:

  • use of a cloud-based PMS

  • point-of-sale terminals

  • validation of compliance with the PCI Data Security Standard (DSS)

  • key management techniques—while mentioned in this document in discussions of secure payment—were not in scope for the implemented architecture

  • securing web servers and web applications

  • mobile device security

  • penetration testing and vulnerability assessments

  • risk checks that relate the login history of users with their login locations as criteria for granting access to the requested system

  • wireless access concerns for conference attendees, as well as other concerns that involve large-scale testing

3.3 Assumptions

This project is guided by the following assumptions:

  • availability of skills—The organization has employees or contractors who can implement a security architecture around its property management system.

  • uniqueness of lab environment—The example implementation was developed in a lab environment. It does not reflect the complexity of a production environment, and we did not use production deployment processes. Before production deployment, it should be confirmed that the example implementation capabilities meet the organization’s architecture, reliability, and scalability requirements.

3.4 Risk Assessment

For this project, Risk Management Framework Quick Start Guides [B15] proved to be invaluable in providing a baseline to assess risks from which we developed the project and the security characteristics of the build. For a deeper dive into the application of a risk management framework, the NCCoE recommends following the guidance in the publicly available NIST SP 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations [B16].

NIST SP 800-30 Revision 1, Guide for Conducting Risk Assessments, states that risk is “a measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence” [B17]. The guide further defines risk assessment as “the process of identifying, estimating, and prioritizing risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system. Part of risk management incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place.”

3.4.1 Threats

All organizations face external and internal threats. While not every threat can be eliminated, an architecture can be built to mitigate and/or reduce the potential realization of various threats. The PMS reference design mitigates threats related to unauthorized and elevated privileges, data exfiltration, configuration modification, data modification, and access to sensitive data. Any or all of these unmitigated threats could lead to fraud, which is one of the largest concerns in the hospitality industry.

3.4.1.1 External Threats

One managed security service provider’s annual global security report [B14] shows that the hospitality industry has the second highest number of incidents being investigated by the provider. The same report notes that motivation or types of data targeted by malicious actors for hospitality organizations includes “credit card track data, financial/user credentials, proprietary information, and PII” [personally identifiable information].

Since 2014, a targeted technique labeled DarkHotel hacking [B18] by security services leverages a hotel’s Wi-Fi to selectively target and deliver malicious software to traveling executives. Further, identity theft and doxing—searching for and publishing private or identifying information about an individual on the internet, typically with malicious intent—are persistent threats within the hospitality industry.

3.4.1.2 Internal Threats

Hotels also face internal threats, including misuse, inappropriate sharing or disclosure of personal information by employees with malicious intent, and accidental breaches. In fact, it is suggested that more than 50 percent of security incidents are initiated from current or former employees. Mitigating internal threats involves more than just physical concepts, such as locking doors; rather, the process needs to include cybersecurity concepts that help protect against insider threats and unauthorized lateral movement within the enterprise by hotel staff and hotel guests.

3.4.2 Vulnerabilities

A vulnerability is a “weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source” [B19]. Among this project’s goals is mitigating the ability of an actor to exploit vulnerabilities. Often, vulnerabilities are self-inflicted. For instance, organizations may:

  • commit integration and configuration errors due to poor configuration management processes

  • delay and/or not perform patching/updating regularly

  • improperly deploy assets

3.4.3 Cybersecurity Control Map

Visit Appendix A to see the security control mappings that have been identified for this project’s PMS reference design. A Cybersecurity Framework Components Mapping table (Table A-1) shows the result from examining all the NIST Cybersecurity Framework [B8] Core Subcategories and picking the Subcategories supported as a desired outcome of the PMS environment. Each of the Cybersecurity Framework Subcategories shown in the table maps to PCI DSS [B6], controls in NIST SP 800-53 rev 5 [B9], and work roles in the NICE Cybersecurity Workforce Framework [B11]. Section 5 of this document reiterates the security control mappings and introduces zero trust as another method of analysis and planning.

3.4.4 Privacy Control Map

Best practices for privacy protection include data minimization, transparency, and preference management. The NIST Privacy Framework Core [B12] is a set of privacy protection activities, desired outcomes, and applicable references that are common across all sectors. The Core presents industry standards, guidelines, and practices in a manner that enables communicating privacy activities and outcomes across the organization from the executive level to the implementation/operations level. The Privacy Framework Core consists of five Functions—Identify-P, Govern-P, Control-P, Communicate-P, and Protect-P. When considered together, these Functions provide a high-level, strategic view of the life cycle of an organization’s management of privacy risk arising from data processing. The Framework Core then identifies underlying key Categories and Subcategories–which are discrete outcomes–for each Function and provides example informative references such as existing standards, guidelines, and practices for each Subcategory.

Visit Appendix B to see privacy control mappings that we have identified for this project’s PMS reference design. A Privacy Framework Mapping table (Table B-1) shows the result from examining all the NIST Privacy Framework Core [B12] Subcategories and picking the Subcategories supported by components of the PMS reference design. This work was done after the collaboration team designed the PMS reference design. We include it to draw attention to NIST’s Privacy Framework, a tool for improving privacy through enterprise risk management, to enable better privacy engineering practices that support privacy by design concepts and help organizations protect individuals’ privacy.

We did not run a privacy risk assessment methodology during this project on any existing PMS as a first step that would enable an organization to subsequently identify a target privacy profile. Table B-1 simply identifies the Subcategories addressed by the PMS reference design and indicates which PMS reference design component is responsible for covering the Subcategory’s desired outcome.

4 Architecture

The PMS reference design built for this project demonstrates a typical hotel process for reservations, issuing room keys, and check-in and checkout credit card transactions. This section presents a high-level architecture showing the reference design implemented. It also introduces the use cases and process flows supported by the PMS reference design.

4.1 Architecture Description

The NCCoE worked with project collaborators to develop a standards-based, commercially available reference design demonstrating the following capabilities:

  • Data protection and encryption provides the capability to securely store PCI/PII data using additional data protection measures such as data encryption, limiting transmission of payment card data, secure data tokenization, and a secure data vault.

  • System protection and authentication provides the capability to protect the functionality of the PMS, including the POS system and the reservation systems. This function also employs multifactor authentication and eliminates unauthorized access to data and services via dynamic authorization. This also includes making the access control enforcement, on a per connection basis, as granular as possible for internal and third-party users. Finally, it involves the use of network segmentation and controlling change across multiple system dimensions to increase uncertainty and complexity for attackers, thereby reducing their window of opportunity.

  • Logging gives continuous and near real-time auditing and reporting of user activity, network events, and component interactions.

4.1.1 High-Level Architecture

This section introduces the components, functions, and technologies implemented. The PMS reference design includes the components shown in Figure 4-1.

Figure 4‑1 Secure PMS High-Level Architecture

The high level architecture of the secure PMS system. Internet access goes through a Network Protection Device, and guest wi-fi access goes through a Wireless Protection and Visibility Platform. Within the Protected Network Zone is the PMS, the Access Control Platform, the Physical Access Control Server, the 2FA, the Privileged Access Management, and the Payment Solution Application.

Table 4-1 provides a listing of each of the components introduced in Figure 4-1 along with a description of its function in the reference design and the commercial technology implemented in the reference design.

Table 4‑1 Components, Functions, Technologies

Component

Function

Technology Implemented

PMS

facilitates the reservations process, checks customers in and out, tracks charges, and reconciles billing

Solidres

Note: This component was not provided by collaborator. It was purchased for use in this reference design.

Network Protection Device

network protection appliance that works in concert with firewalls; provides additional layer of protection against cyber attacks

CryptoniteNXT

Secure Zone 2.9.1

Access Control

Platform

secures connection and control mechanism to enterprise devices from authorized users and authorized devices; also provides security perimeter monitoring, auditing, and logging activity

TDi ConsoleWorks

5.2-0u1

Privileged Access Management

provides real-time incident monitoring and detection, privilege escalation management, and reporting functions for the IT enterprise

Remediant

SecureONE 18.06.3-ce

Wireless Protection and Visibility Platform

protects the hotel guest portion of the Wi-Fi by limiting guest access to only the internet and preventing hotel guest access to hotel back-end systems. Many hotel guest Wi-Fi systems are provided by service providers as stand-alone networks. An integrated Wi-Fi was included in this PMS reference design to demonstrate control of lateral movement of hotel guests, allowing the integrated Wi-Fi to support the installation of IoT devices in smart rooms or other systems requiring Wi-Fi connectivity.

Forescout

CounterACT 8.1

Payment Solution

Application

provides the token vault and tokenization along with multifactor authentication

StrongKey Tellaro Appliance (formerly known as StrongAuth KeyAppliance (SAKA)

Physical Access

Control Server

physical access control system, including door locks, room-key encoding, and management

Häfele Dialock 2.0

Firewall

provides exterior protection and segments the enterprise

pfSense

4.2 Use Cases Supported by the Property Management System Reference Design

We designed and built the PMS reference design to support the following hotel use cases.

4.2.1 Use Case 1: PMS Accepts Reservation

In Use Case 1, the PMS accepts a reservation, reconciles the bill, and closes out the reservation while never exposing any data to unauthorized access. Further, the reservation data is editable in a secure manner. In this PMS reference design, all reservations are manually entered directly into the PMS and not supplied by an external CRS.

4.2.2 Use Case 2: Authorized User Access

In Use Case 2, only authorized users can connect to their authorized devices. They are not able to gain access to devices that might enable them to escalate their privileges within the PMS reference design or conduct any unauthorized lateral movements.

The access control platform in the PMS reference design allows users to connect only to the systems for which they are authorized based on their role as a hotel guest, hotel staff, or system administrator. The action of inputting or modifying a reservation requires an authorized hotel staff user to authenticate to gain access to the PMS.

4.2.3 Use Case 3: Secure Credit Card Transaction

In Use Case 3, a credit card transaction is securely conducted. The hotel guest credit card transaction is tokenized before introduction to the PMS.

Credit card data is consumed only by the payment solution application (PSA) and is immediately tokenized. The PSA function to validate the guest credit card data with a third-party payment processor is not included in the PMS reference design. The validated credit card data token is sent from the PSA to the PMS. The token is used again at checkout when the bill is paid, with only the token sent from the PMS to the PSA.

4.2.4 Use Case 4: Secure Interaction of Ancillary Hotel System with PMS

In Use Case 4, the PMS securely interacts with a physical access control system, specifically a door lock and room-key encoder.

The physical access control server is a door lock/room-key system that requires connectivity to the PMS. To encode a room key at check-in, an authorized staffer accesses the PMS to identify the assigned guest room number and provides only the room number to the physical access control server (PACS) to encode a unique room key. In this process, the authorized hotel staff user authenticates to the PACS and simply inputs a room number. No guest PII is moved from the PMS to the PACS during key creation.

4.3 Process Flows

The following process flows show the sequence of events taking place for various hospitality functions in the enterprise.

4.3.1 Authorized Employee Access

Figure 4-2 shows the process flow for an authorized hotel staff user connecting to only the systems for which they are authorized. The hotel staff user will be challenged by the access control platform and will be required to present whatever credentials are required by policy; further, they will be granted only minimal access based upon their role. The process flow in Figure 4-2 is described below.

  1. From a device or terminal, an authorized hotel staff user attempts to log in via the access control platform. All login attempts are directed to the access control platform and logged.

  2. The hotel staff user who presents valid authentication credentials is granted access to only the system(s) they are allowed based upon their role.

  3. The network protection device monitors their activity and maintain logs via the privileged access management system.

  4. Any suspicious behavior is noted, logged, and acted on according to policy.

  5. Logs are collected by the privileged access management solution.

Figure 4‑2 Staff Process Flow

The process flow diagram for staff process flow. This is a visual representation of the steps described in section 4.3.1.

4.3.2 Secure Credit Card Transaction

Figure 4-3 shows the process flow for a credit card transaction. The reference design adheres to guidance from the Secure Payments Framework [B2]. The Secure Payments Framework is based on the concept that raw payment card data is not stored, processed, or transmitted by any hotel system within the control of the hotel company. The PMS reference design replaces raw payment card data with tokens. These tokens are useless to malicious actors. This approach is also aligned with PCI-DSS best practices.

The technology used in this build can sup-port HTNG’s Secure Payment Framework [B2]:

  • Encrypt cardholder data regardless of where transaction occurs (card present/card not present)

  • Distribute Terminal Keys as part of its management of the Derived Unique Key Per Transaction (DUKPT)

  • In one device address all the precursor processes as well as the secure storage and processing of credit card data end-to-end

The transaction is protected by the payment solution application via tokenization. The token alone is ineffective as only the payment solution application can decrypt it and associate a credit card with charges. This transaction flow assumes that the payment card data was ingested via an on-property customer-facing card reader, on-property POS, a kiosk, the property website, or was collected from a third-party entity. That payment card data is tokenized at the edge of the PMS environment via the tokenization appliance before it hits the PMS.

The process of Figure 4-3 is described below.

  1. The payment solution application collects the credit card information.

  2. The payment solution application secures credit card information via a secure vault.

  3. The payment solution application validates with a third-party payment processor.

  4. The payment solution application issues a token.

  5. Charges/bill are reconciled via the token from the PMS through the payment solution application back to the third-party payment processor when the guest checks out.

Figure 4‑3 Secure Credit Card Process Flow

The process flow diagram for secure credit card transactions. This is a visual representation of the steps described in section 4.3.2.

4.3.3 Secure Interaction of Ancillary Hotel System (with PMS)

Figure 4-4 shows the process flow for the secure interaction of an ancillary system with the PMS. The following demonstrates how a door lock/room-key system is used in this example implementation.

  1. An authorized hotel staff user connects to the PMS.

  2. The physical access server validates the room-key request against a reservation in the PMS.

  3. The room key is created and delivered.

  4. All activity is logged and sent to the privileged access management system.

Figure 4‑4 Secure Interaction of Ancillary System with PMS Process Flow

The process flow diagram for creating a room key. This is a visual representation of the steps described in section 4.3.3.

4.3.4 Hotel Guest Internet Access via Hotel Guest Wi-Fi

Figure 4-5 shows the process flow for a guest accessing the internet via the hotel’s guest Wi-Fi, showing how the:

  1. Hotel guest attempts to connect to the internet via the guest Wi-Fi

  2. Hotel guest is challenged

  3. Hotel guest responds with temporary credentials they have been provided, corresponding to their reservation

  4. Wireless protection and visibility platform validates with the PMS, and the hotel guest is provided internet access

  5. Hotel guest is provided only access to the internet (is forbidden to move laterally) and any external-facing enterprise hospitality systems; all activity, including surfing and web activity, is logged and sent to the privileged access management system

Figure 4‑5 Guest Internet Access Via Guest Wi-Fi Process Flow

The process flow diagram for a guest accessing the wireless network. This is a visual representation of the steps described in section 4.5.4.

5 Security Characteristic Analysis

The purpose of the security characteristic evaluation is to understand the extent to which the project meets its objective of demonstrating improved cybersecurity of a PMS.

5.1 Analysis Assumptions and Limitations

The security characteristic analysis has the following limitations:

  • The analysis is not a comprehensive test of individual security components, nor is it a red-team exercise involving adversarial emulation.

  • The analysis cannot identify all weaknesses.

  • The analysis does not include the lab infrastructure on which the project is built. The lab infrastructure undergoes regular patching and is in compliance with information security requirements per Federal law, including externally hosted systems that support NIST.

5.2 Analysis of the Reference Design’s Support for Cybersecurity Framework Subcategories

The NIST Cybersecurity Framework Subcategories are a basis for organizing our analysis and allow us to systematically consider how well the reference design supports its intended security characteristics in terms of the specific Subcategories of the Cybersecurity Framework. This analysis enables an understanding of how the example implementation achieved the goals of the design when compared against a standardized framework.

The Cybersecurity Framework includes Functions, Categories, and Subcategories that define the capabilities and processes needed to implement a cybersecurity program. In Table A-1, the NCCoE has identified the Subcategories that are desirable to implement when deploying the example implementation.

This section identifies the security benefits provided by each component of the example implementation and how those components support specific cybersecurity activities as specified in terms of Cybersecurity Framework Subcategories.

5.2.1 ID.AM-1: Physical devices and systems within the organization are inventoried

The network protection device, the CryptoniteNXT Secure Zone 2.9.1, has the capability to inventory devices and systems that are part of or attached to the PMS reference design and update the inventory in near real time.

5.2.2 ID.AM-2: Software platforms and applications within the organization are inventoried

The network protection device, the CryptoniteNXT Secure Zone 2.9.1, has the capability to inventory platforms and applications that are part of or attached to the PMS reference design and update the inventory in near real time.

5.2.3 PR.AC-1: Identities and credentials are issued, managed, verified, revoked, audited, proofed and bound to credentials, and asserted in interactions for authorized devices, users, and processes

The access control platform, TDi ConsoleWorks 5.2-0u1, manages credentials and identities.

5.2.4 PR.AC-6: Identities are proofed and bound to credentials and asserted in interactions

The access control platform, TDi ConsoleWorks 5.2-0u1, challenges and verifies all credentials presented in the PMS reference design. The credential could be tied to a user, a system, an application, or a trusted third-party entity.

5.2.5 PR.AC-3: Remote access is managed

Through a combination of the TDi ConsoleWorks 5.2-0u1 access control platform and the Forescout CounterACT 8.1 wireless protection and visibility platform, all enterprise remote access activity is monitored, logged, and managed.

5.2.6 PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties

The access control platform, TDi ConsoleWorks 5.2-0u1, and network protection device, CryptoniteNXT Secure Zone 2.9.1, work in combination to limit access in the least allowable fashion to only those authorized entities, users, systems, transactions, and platforms. Connections that are authorized are given the least level of privilege as feasible.

5.2.7 PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multifactor) commensurate with the risk of the transaction (e.g., individuals’ security and privacy risks and other organizational risks)

Authentication that is commensurate with the risk of the transaction is an intrinsic part of the example implementation. Transactions/users/systems/applications are authenticated based upon the level of risk. Based upon configured policies, the access control platform, TDi ConsoleWorks 5.2-0u1, determines what level of authentication is required for a particular request as determined by the risk level associated.

5.2.8 PR.DS-1: Data at rest is protected

The payment solution appliance, the StrongKey Key Appliance, tokenizes credit card data within the StrongKey vault to protect data at rest. Only tokens are transmitted through the PMS reference design, which protects the data in transit.

5.2.9 PR.DS-2: Data in transit is protected

The payment solution appliance, the StrongKey Key Appliance, tokenizes credit card data within the StrongKey vault to protect data at rest. Only tokens are transmitted through the PMS reference design, which protects the data in transit.

5.2.10 PR.IP-3: Configuration change control processes are in place

The network protection device, CryptoniteNXT Secure Zone 2.9.1, has the capability to control, log, and manage changes and updates to devices and systems in the PMS reference design.

5.2.11 PR.PT-4: Communications and control networks are protected

The network protection device, CryptoniteNXT Secure Zone 2.9.1, monitors and protects the PMS reference design network and the devices connected to it.

5.2.12 DE.CM-1: The network is monitored to detect potential cybersecurity events

The reference designs support monitoring network activity. Event log information is reported and correlated by the privileged access management tool, Remediant SecureONE 18.06.3-ce.

5.2.13 DE.CM-3: Personnel activity is monitored to detect potential cybersecurity events

The reference design support monitoring personnel activity. Event log information is reported and correlated by the privileged access management tool, Remediant SecureONE 18.06.3-ce.

5.2.14 DE.CM-7: Monitoring for unauthorized personnel, connections, devices, and software is performed

The reference design support monitoring network and personnel activity. Event log information is reported and correlated by the privileged access management tool, Remediant SecureONE 18.06.3-ce. This also includes connections and attempted connections by unauthorized devices, users, and systems.

5.2.15 DE.DP-4: Event detection information is communicated

The privileged access management tool, Remediant SecureONE 18.06.3-ce, logs all incidents and can be configured to report out as required by the enterprise.

5.3 Zero Trust

Zero trust is a cybersecurity strategy that focuses on moving network defenses from wide, static network perimeters to focusing more narrowly on dynamic and risk-based access control to enterprise resources, regardless of where they are located.

Zero trust provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised.

5.3.1 Zero Trust Tenets

This project is also designed to show a PMS reference design with an architecture that adheres to tenets of zero trust. Conventional network security has focused on perimeter defenses. Once inside the network perimeter, users are “trusted” and often given broad access to many corporate resources. But malicious actors can come from inside or outside the network, and several high-profile cyber attacks in recent years have undermined the case for the perimeter-based model. Moreover, the perimeter is becoming less relevant due to several factors, including the growth of cloud computing, mobility, and changes in the modern workforce.

A zero trust architecture is designed and deployed with adherence to the zero trust tenets. Figure 5-1 identifies zero trust tenets.

Figure 5‑1 Tenets of Zero Trust

Tenets of Zero Trust chart

These tenets are the ideal goal, though it must be acknowledged that not all tenets may be fully implemented in their purest form for a given strategy. This publication’s strategy to secure a property management system does connect with each of the zero trust tenets. Table 5-1 shows zero trust tenets associated with components in the PMS reference design and Cybersecurity Framework Subcategories.

Table 5‑1 Zero Trust Tenets/Components/Cybersecurity Framework Subcategories

Zero Trust Tenet

PMS Reference Design Component

Cybersecurity Framework Subcategories

All data sources and computing services are considered resources.

CryptoniteNXT Secure Zone 2.9.1

ID.AM-1 Physical devices and systems within the organization are inventoried.

ID.AM-2 Software platforms and applications within the organization are inventoried.

All communication is secured regardless of network location; network location does not imply trust.

CryptoniteNXT Secure Zone 2.9.1

StrongKey’s vault

PR.AC-5 Network integrity is protected.

PR.DS-1 Data at rest is protected.

PR.DS-2 Data in transit is protected.

PR.PT-4 Communications and control networks are protected.

Access to individual enterprise resources is granted on a per-session basis; trust in the requester is evaluated before the access is granted.

TDi ConsoleWorks 5.2-0u1

PR.AC-1 Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users, and processes.

PR.PT-3 The principle of least functionality is incorporated by configuring systems to provide only essential capabilities.

Access to resources is determined by dynamic policy, including the observable state of client identity, application, and the requesting asset, and may include other behavioral attributes.

TDi ConsoleWorks 5.2-0u1

PR.AC-4 Access permissions and authentications are managed, incorporating the principles of least privilege and separation of duties.

PR.AC-6 Identities are proofed and bound to credentials and asserted in interactions.

DE.CM-3 Personnel activity is monitored to detect potential cybersecurity events.

The enterprise ensures that all owned and associated devices are in the most secure state possible and monitors devices to ensure that they remain in the most secure state possible.

No component was included in the PMS reference design to ensure that devices are in the most secure state.

PR.IP-1 A baseline configuration of information technology/industrial control systems is created and maintained incorporating security principles (e.g., concept of least functionality).

All resources’ authentication and authorization are dynamic and strictly enforced before access is allowed; this is a constant cycle of access, scanning and assessing threats, adapting, and continually reevaluating trust in ongoing communications.

Remediant SecureONE 18.06.3-ce

CryptoniteNXT Secure Zone 2.9.1

Forescout CounterACT 8.1

PR.AC-1 Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users, and processes.

PR.AC-3 Remote access is managed.

PR.AC-4 Access permissions and authentications are managed, incorporating the principles of least privilege and separation of duties.

PR.DS-5 Protections against data leaks are implemented.

PR.IP-3 Configuration change control processes are in place.

DE.CM-7 Monitoring for unauthorized personnel, connections, devices, and software is performed.

The enterprise collects as much information as possible about the current state of the network infrastructure and communications and uses it to improve its security posture.

Remediant

SecureONE 18.06.3-ce

DE.AE-2 Detected events are analyzed to understand attack targets and methods.

DE.CM-1 The network is monitored to detect potential cybersecurity events.

DE.DP-4 Event detection information is communicated.

5.3.2 Components of Zero Trust

A zero trust architecture is an enterprise cybersecurity architecture that is based on zero trust principles and designed to prevent data breaches and limit internal lateral movement.

Figure 5-2 illustrates at a high level the components that compose a typical ZTA implementation.

Figure 5‑2 Components of Zero Trust

Components of Zero Trust Functional Components

Table 5-2 maps PMS reference design components (originally identified in Table 4-1) to components of ZTA as described in NIST SP 800-207, Zero Trust Architecture.

Table 5‑2 Zero Trust Component and PMS Reference Design Component Mapping

PMS Reference Design Component

Zero Trust Component

pfSense Firewall

Endpoint Security

TDi ConsoleWorks

Identity and Access Management (IDAM)

Remediant SecureOne

Security Analytics

Data encryption at rest (in StrongKey StrongAuth KeyAppliance and Solidres PMS) and in transit

Data Security

CryptoniteNXT Administration Control Center (ACC)

Policy Engine

Domain users, system administrators with access permission to the CryptoniteNXT administrator workstation

Policy Administrators

Any device within the CryptoniteNXT Secure Zone, including PMS and other security components

Policy Enforcement Points

Users (hotel guests, hotel staff, and system administrators)

Subjects

Workstation

Asset

Solidres PMS

Enterprise Resource

Data in Solidres PMS

Enterprise Resource

StrongKey StrongAuth KeyAppliance vault

Enterprise Resource

Credit card data in StrongKey StrongAuth KeyAppliance vault

Enterprise Resource

6 Privacy Characteristic Analysis

The purpose of a privacy characteristic evaluation is to understand the extent to which a project meets its objective of demonstrating improved privacy protection for a PMS.

6.1 Analysis Assumptions and Limitations

For this project, the privacy characteristic evaluation has the following limitations:

  • The analysis is not a comprehensive test of individual privacy components, nor does it include completion of a privacy risk assessment methodology.

  • The analysis cannot identify all weaknesses.

6.2 Privacy Protections of the Reference Design

The NIST Privacy Framework Core Subcategories are a basis to identify privacy characteristics that are supported by our PMS reference design. The PMS reference design architecture was designed before the NIST Privacy Framework [B12] was developed. This section is included to draw attention to the Privacy Framework and to highlight that protecting an individual’s privacy could become a core value for PMS reference designs through more thorough use of the Privacy Framework.

See the Privacy Framework Mapping, Table B-1, in Appendix B for the technical privacy characteristics identified as being satisfied by this PMS reference design.

7 Functional Evaluation

7.1 Test Cases

This section includes the test cases necessary to conduct the functional evaluation of the PMS example implementation. Refer to Section 4 for descriptions of the tested example implementation.

Each test case consists of multiple fields that collectively identify the goal of the test, the specifics required to implement the test, and how to assess the results of the test. Table 7-1 describes each field in the test case.

Table 7‑1 Test Case Fields

Test Case Field

Description

requirement tested

identifies the requirement to be tested and guides the definition of the remainder of the test case fields; specifies the capability to be evaluated

description

describes the objective of the test case

associated Cybersecurity Framework Subcategories

lists the Cybersecurity Framework Subcategories addressed by the test case

sub test cases

In some cases, one or more tests may be part of a larger use case or functionality.

preconditions

identifies the starting state of the test case. Preconditions indicate various starting state items, such as a specific capability configuration required or specific protocol and content.

procedure

lists the step-by-step actions required to implement the test case; a procedure may consist of a single sequence of steps or multiple sequences of steps (with delineation) to indicate variations in the test procedure

expected results

lists the expected results for each variation in the test procedure

actual results

records the observed results

disposition

indicates if the test passed or failed

7.1.1 PMS Use Case Requirements

Table 7-2 identifies the PMS functional analysis requirements that are addressed in the associated requirements and test cases and mapped to the build components.

Table 7‑2 Functional Analysis Requirements

Capability Requirement (CR) ID

Parent Requirement

Subrequirement

Test Case

Component

CR 1

guest reservation

PMS-04

property management system

CR 1.a

room key provisioned

PMS-05

physical access control server

CR 2

authorized hotel staff user can log in

PMS-01

access control platform

CR 2.a

cannot move laterally unless authorized to do so

PMS-03a, PMS-03b

access control platform

CR 2.b

have access only to data they are authorized to access

PMS-03b, PMS-03c

network protection device

CR 2.c

users with partial/compromised credentials are blocked

PMS-02

access control platform

CR 3

secure credit card transaction

PMS-07a

payment solution appliance

CR 3.a

Credit card data was tokenized.

PMS-07a

payment solution appliance

CR 3.b

Eavesdropper cannot see credit card data.

PMS-07b

payment solution appliance

CR 4

Wi-Fi hotel guest connectivity/login

PMS-06a

wireless protection and visibility platform

CR 4.a

Hotel guest cannot access enterprise systems.

PMS-06b

wireless protection and visibility platform

CR 5

Authorized device can connect/ unauthorized device cannot connect.

PMS-08, PMS-09

privileged access management

7.1.2 Test Case PMS-01 (Authorized Hotel Staff User Can Log In)

Table 7-3 contains test case requirements, an associated test case, and descriptions of the test scenario for an authorized user logging in to the system(s) for which they are authorized.

Table 7‑3 Authorized User Can Log In

Test Case Field

Description

requirement tested

(CR 2) system login capability for authorized users

description

Verify that a new authorized hotel staff user is provided credentials and can log in to enterprise systems for which they are authorized.

associated Cybersecurity Framework Subcategories

PR.AC-1, PR.AC-4, PR.PT-3

sub test cases

N/A

preconditions

PMS and room-key systems up and running

procedure

Log in to end user workstation/front desk, open TDi in browser, authenticate, open connection to host in console.

expected results

Hotel staff user can log in to the PMS with their issued credentials.

actual results

Hotel staff user can log in to PMS through TDi console. (Other tested machines include front desktop, management workstation.)

disposition

pass

7.1.3 Test Case PMS-02 (PMS Authentication)

Table 7-4 contains test case requirements, associated test case, and descriptions of the test scenario for validating the PMS authentication mechanism and validating that the mechanism protects against compromised accounts/credentials.

Table 7‑4 PMS Authentication

Test Case Field

Description

requirement tested

(CR 2.c) hotel staff users blocked with partial/compromised credentials

description

Validate that authentication to the PMS works as planned, e.g., multifactor authentication, biometric.

associated Cybersecurity Framework Subcategories

DE.AE-2, DE.CM-1, DE.CM-7

sub test cases

If a hotel staff user has only a partial credential or a compromised credential, they cannot access the PMS.

preconditions

PMS configured and running properly

procedure

Log in to end user workstation/front desk, open TDi in browser, authenticate, open connection to Solidresʼs admin console. Trigger password policy by trying to log in Solidresʼs admin side 10 times.

expected results

Solidres admin console can be accessed successfully. Locked account cannot be accessed.

actual results

Solidres admin console can be accessed successfully. (Multifactor is enabled and can be used if the user provisions a tokenization device.) Enabled brute force plug-in in PMS that blocks IP for one day when attempting to log in past 10 attempts. The account was locked and could not be accessed after locking.

disposition

pass

7.1.4 Test Case PMS-03 (Authorized Users Can Access Only Systems and Data They Are Authorized for Test Cases)

The following three test cases validate users being granted access only to that for which they are authorized.

7.1.4.1 Test Case PMS-03a (Hotel Staff Users Cannot Move Laterally from the PMS Unless Authorized to Do So)

Table 7-5 contains test case requirements, associated test case, and descriptions of the test scenario for preventing lateral movement.

Table 7‑5 No Unauthorized Lateral Movement

Test Case Field

Description

requirement tested

(CR 2.a) cannot move laterally unless authorized to do so

description

Verify that an authorized hotel staff user cannot go outside their boundary.

associated Cybersecurity Framework Subcategories

PR.AC-5, PR.PT-3, DE.CM-3

sub test cases

If they are authorized to access only the PMS, they cannot move laterally to another enterprise system from the PMS.

preconditions

PMS configured and running properly

procedure

attempted to connect to another system with an account that was authorized only for the PMS

expected results

access denied

actual results

access denied

disposition

pass

7.1.4.2 Test Case PMS-03b (Prevent Unauthorized Function)

Table 7-6 contains test case requirements, associated test case, and descriptions of the test scenario for preventing a hotel staff user from performing a function for which they are not authorized.

Table 7‑6 Prevent Unauthorized Function

Test Case Field

Description

requirement tested

(CR 2.a, CR 2.b) cannot move laterally unless authorized to do so; have access only to data for which they are authorized

description

Verify that an authorized hotel staff user cannot go outside their boundary.

associated Cybersecurity Framework Subcategories

PR.PT-3, DE.CM-3

sub test cases

The user cannot perform a function for which they are not authorized, e.g., create a master room key.

preconditions

PMS configured and running properly; Häfele back-end server configured and running properly

procedure

Front desk user created with no write or delete access. Verify the access controls of the Häfele back-end server.

expected results

Häfele permissions do not allow user to create a master room key for all of the created rooms in the back-end server.

actual results

Master key could not be created when the lowest level of privilege was given. The user was not able to add an authorization to create or save MIFARE credentials.

disposition

pass

7.1.4.3 Test Case PMS-03c (Only Authorized Data)

Table 7-7 contains test case requirements, associated test case, and descriptions of the test scenario for ensuring that hotel staff users have access only to data for which they are authorized.

Table 7‑7 Only Authorized Data

Test Case Field

Description

requirement tested

(CR 2.b) have access only to data for which they are authorized

description

Verify that an authorized hotel staff user cannot go outside their boundary.

associated Cybersecurity Framework Subcategories

PR.AC-5, PR.DS-2, PR.DS-5, PR.PT-3, DE.CM-3

sub test cases

Verify that the hotel staff user has access to only the data set(s) for which they are authorized; further, that they can only download data they are authorized to download, and edit data that they are authorized to edit.

preconditions

PMS configured and running properly

procedure

created a hotel staff user account that was giving the permission of a “site sponsor.” This user account could see only site-specific information, not including guest reservations. After logging in to the account, it was verified that the specified permissions were valid and that the account could not navigate to sensitive data.

expected results

Solidres Access Control List (ACL) controls are functioning, and registered guests or sponsors should not be able to access or view sensitive customer data.

actual results

ACL manages view of permissions of the logged-in users. Users could only view data they were authorized to view within the Solidres PMS.

disposition

pass

7.1.5 Test Case PMS-04 (Guest Reservation Editable)

Table 7-8 contains test case requirements, associated test case, and descriptions of the test scenario for entering a reservation and editing the reservation.

Table 7‑8 Guest Reservation Editable

Test Case Field

Description

requirement tested

(CR 1) creating a guest reservation and having the ability of only an authorized user to edit the reservation

description

Enter a guest reservation into the PMS. Verify that it is in the PMS and that it is retrievable and editable.

associated Cybersecurity Framework Subcategories

N/A

sub test cases

N/A

preconditions

PMS up and running properly

procedure

Navigate to Solidres guest registration from guest machine, and book a room.

expected results

reservation record in the PMS

actual results

The test registration is bookable/retrievable from web interface of Solidres.

disposition

pass

7.1.6 Test Case PMS-05 (Room-Key Provisioning)

Table 7-9 contains test case requirements, associated test case, and descriptions of the test scenario for provisioning a room key.

Table 7‑9 Provisioning Room Key

Test Case Field

Description

requirement tested

(CR 1) room key provisioned

description

From the reservation in the PMS, verify that a room key is provisioned for the hotel guest.

associated Cybersecurity Framework Subcategories

N/A

sub test cases

Verify the processing of provisioning, writing, reading.

preconditions

Rooms are defined in Häfele, and PMS is running.

procedure

Provision a key through the PMS in conjunction with Häfeleʼs back-end server. The provision process includes assigning a key in the PMS, writing a key card with the Häfele back-end server, and making sure that the assigned key-card room number and guest-registered room number are the same.

expected results

Provisioned room key works.

actual results

Room keys were provisioned.

disposition

pass

7.1.7 Test Case PMS-06 (Provisioning Guest Wi-Fi Access)

The following two test cases will validate provisioning hotel guest Wi-Fi access and that guests cannot access the restricted enterprise from the Wi-Fi.

7.1.7.1 Test Case PMS-06a (Guests’ Limited Wi-Fi Access)

Table 7-10 contains test case requirements, associated test case, and descriptions of the test scenario for preventing lateral movement.

Table 7‑10 Guests’ Limited Wi-Fi Access

Test Case Field

Description

requirement tested

(CR 4) Wi-Fi hotel guest connectivity/login

description

Only registered hotel guests will be granted limited Wi-Fi access.

associated Cybersecurity Framework Subcategories

PR.AC-3, PR.IP-3, PR.PT-3, PR.PT-4, DE.CM-3

sub test cases

Verify that the hotel guest can access only authorized resources via the Wi-Fi, e.g., the internet and guest-facing resources such as activities reservations and room charges.

preconditions

PMS up and running properly; guest Wi-Fi up, running, and connected; hotel guest has provisioned Wi-Fi login

procedure

Attempt to connect a device to the guest Wi-Fi.

When the login screen appears, enter the password created for the hotel guest as part of the reservation process to complete the login. Open a browser, and verify internet sites are accessible.

expected results

Guest successfully logs in to Wi-Fi with issued login.

actual results

entered the Wi-Fi key and gained access to the internet

disposition

pass

7.1.7.2 Test Case PMS-06b (Prevent Unauthorized Guest Lateral Movement via Wi-Fi)

Table 7-11 contains test case requirements, associated test case, and descriptions of the test scenario for preventing a guest from accessing any restricted back-end systems.

Table 7‑11 Prevent Unauthorized Guest Lateral Movement via Wi-Fi

Test Case Field

Description

requirement tested

(CR 4.a) Hotel guest cannot access enterprise systems.

description

Only registered hotel guests are granted limited Wi-Fi access.

associated Cybersecurity Framework Subcategories

PR.AC-3, PR.PT-4, DE.CM-3

sub test cases

Verify that the hotel guest via the Wi-Fi cannot jump to any enterprise systems (e.g., PMS).

preconditions

PMS up and running properly; guest Wi-Fi up, running, and connected; hotel guest has provisioned Wi-Fi login

procedure

Once the hotel guest Wi-Fi is operating and internet access has been established, attempt to ping the IP addresses of the protected hotel systems.

expected results

Hotel guest cannot access unauthorized resources when logged in to the guest Wi-Fi.

actual results

Hotel guest Wi-Fi range is blocked via NGINX ACL implementation, which works with CounterACT protections.

disposition

pass

7.1.8 Test Case PMS-07 (Secure Credit Card Transaction)

The following two test cases validate secure credit card transactions.

7.1.8.1 Test Case PMS-07a (Tokenized Credit Card Data)

Table 7-12 contains test case requirements, associated test case, and descriptions of the test scenario for tokenizing credit card data for a credit card transaction.

Table 7‑12 Tokenized Credit Card Data

Test Case Field

Description

requirement tested

(CR 3.a) Credit card data was tokenized.

description

Conduct a credit card transaction, and verify that the credit card data was tokenized and that the transaction went through.

associated Cybersecurity Framework Subcategories

N/A

sub test cases

Validate that credit card data was tokenized; validate that additional charges can be recorded using the token; validate that the token can be reconciled for payment; validate that the token encrypts and/or otherwise obfuscates credit card data; validate that a “captured” or copied or exfiltrated token is worthless.

preconditions

PMS is up and running properly.

procedure

Log on to hotel staff user workstation/front desk, open TDi in browser, authenticate, open connection to Solidres PMS, navigate to reservations, click the test reservation, validate credit card information was tokenized. Open terminal in TDi Virtual Network Computing (VNC) session, authenticate to MySQL Server, view table entries for reservation, validate credit card information was tokenized (database, PMS, over the wire).

expected results

valid credit card transaction. The credit card information can be seen when accessing the guest reservation in the PMS.

actual results

Tokenized credit card information is stored in Solidres and is reading for processing through the offline plug-in. PII for credit card charges is tokenized. Data in database is stored as a token. (The stripe plug-in required a credit card for charges, and the offline plug-in simulates the “on-site payment” solution that charges the cards after the fact or forwards them to a third party securely.)

disposition

pass

7.1.8.2 Test Case PMS-07b (Verify that Credit Card Data Is Hidden)

Table 7-13 contains test case requirements, associated test case, and descriptions of the test scenario for verifying that credit card data is hidden.

Table 7‑13 Verify that Credit Card Data Is Hidden

Test Case Field

Description

requirement tested

(CR 3.b) Eavesdropper cannot see credit card data.

description

Conduct a credit card transaction, and verify that the credit card data was tokenized and that the transaction went through.

associated Cybersecurity Framework Subcategories

PR.AC-5, PR.DS-2, PR.DS-5

sub test cases

Verify that an eavesdropper cannot see any credit card data.

preconditions

PMS is up and running properly.

procedure

Verify that a credit card transaction cannot be determined from captured Wireshark traffic.

expected results

No credit card data is visible to an eavesdropper.

actual results

Wireshark shows Transport Layer Security encrypted traffic where payment information is tokenized, and user is submitting reservation through guest system. Wireshark was run on the host machine that also housed the PMS server.

disposition

pass

7.1.9 Test Case PMS-08 (Authorized Device Provisioning)

Table 7-14 contains test case requirements, associated test case, and descriptions of the test scenario for allowing an authorized device to connect to the enterprise.

Table 7‑14 Authorized Device Provisioning

Test Case Field

Description

requirement tested

(CR 5) Authorized device can connect/unauthorized device cannot connect.

description

Verify that an authorized device can be provisioned and added/connected to the enterprise.

associated Cybersecurity Framework Subcategories

ID.AM-1, ID.AM-2, PR.AC-1, PR.IP-3

sub test cases

N/A

preconditions

Various technology is up and running; security mechanisms are in place.

procedure

Connect an authorized device with valid credentials.

expected results

Device will connect to the enterprise.

actual results

Authorized device could connect.

disposition

pass

7.1.10 Test Case PMS-09 (Prevent Unauthorized Device from Connecting)

Table 7-15 contains test case requirements, associated test case, and descriptions of the test scenario for preventing an authorized device form connecting to the enterprise.

Table 7‑15 Prevent Unauthorized Device from Connecting

Test Case Field

Description

requirement tested

(CR 5) Authorized device can connect/unauthorized device cannot connect.

description

Verify that an unknown/unauthorized system that appears on the enterprise cannot access the PMS or establish a connection to any enterprise system.

associated Cybersecurity Framework Subcategories

PR.AC-5, PR.IP-3, DE.CM-1, DE.CM-7

sub test cases

N/A

preconditions

Cryptonite rules are configured to block unverified accounts.

procedure

Add a machine to the secure enclave Virtual Local Area Network (VLAN) (simulates connecting to the network). From the connected machine, try to navigate to the PMS.

expected results

Unverified machine is unable to navigate to PMS.

actual results

Device was not allowed to connect.

disposition

pass

8 Future Build Considerations

The NCCoE is open to building future projects or drafting publications in the hospitality sector that not only push to secure a property management system but also reduce cybersecurity and privacy risk for any of the networked technologies being leveraged by the sector.

Exploration of how to mitigate risks could include focus on the use of personal mobile devices as room keys or as controllers of hotel-owned smart devices in a room. The NCCoE has a growing library of publications focused on mobile device security that may prove relevant to the hospitality sector. https://www.nccoe.nist.gov/projects/building-blocks/mobile-device-security

NIST has evolving focus on many areas aimed at reducing cybersecurity and privacy risk, so opportunities exist to frame adoption of more cybersecurity to reduce the risks from the expansion of the use of Internet of Things devices in the hospitality sector.

NIST’s Cybersecurity for the Internet of Things program supports the development and application of standards, guidelines, and related tools to improve the cybersecurity of connected devices and the environments in which they are deployed. https://www.nist.gov/programs-projects/nist-cybersecurity-iot-program

Additionally, future efforts at the NCCoE might dive deeper to highlight the use of geo-velocity, geo-location, and rate limiting for connections as risk checks for authentication and analytics.