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
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
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.
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‑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‑2 Functional Analysis Requirements
Table 7‑3 Authorized User Can Log In
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 |
|
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
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.
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.
The hotel staff user who presents valid authentication credentials is granted access to only the system(s) they are allowed based upon their role.
The network protection device monitors their activity and maintain logs via the privileged access management system.
Any suspicious behavior is noted, logged, and acted on according to policy.
Logs are collected by the privileged access management solution.
Figure 4‑2 Staff Process Flow
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.
The payment solution application collects the credit card information.
The payment solution application secures credit card information via a secure vault.
The payment solution application validates with a third-party payment processor.
The payment solution application issues a token.
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
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.
An authorized hotel staff user connects to the PMS.
The physical access server validates the room-key request against a reservation in the PMS.
The room key is created and delivered.
All activity is logged and sent to the privileged access management system.
Figure 4‑4 Secure Interaction of Ancillary System with PMS Process Flow
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:
Hotel guest attempts to connect to the internet via the guest Wi-Fi
Hotel guest is challenged
Hotel guest responds with temporary credentials they have been provided, corresponding to their reservation
Wireless protection and visibility platform validates with the PMS, and the hotel guest is provided internet access
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
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
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
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.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.