POS or Point of Sale Solution PCI
Good example of PCI and POS. Canada and Vancouver in this instance.
Typical project RFP
Vancouver Civic Theatres and Vancouver Park Board seek a Point of Sale (POS) Solution, professional implementation services, and ongoing software maintenance & support services (with SLAs).
The selected POS Solution must meet the following Mandatory requirements: if any of the Mandatory requirements is not met, the City will not evaluate the Proposal.
MANDATORY requirements:
- the POS Solution must be PCI 4.0-compliant;
- use Moneris as the payment card processor with P2PE pin pad integration;
- integrate with TracRite Optimum Control;
- integrate with SAP (Finance and Inventory Management); and be in a production environment for at least 1 year with at least 3 government or large organizations.
- Vancouver Civic Theatres (VCT) provides its patrons with both mobile and in person food and beverage options prior to shows and during intermission at 4 locations with 44 POS Terminals. The POS system is integrated with P2PE pin pads. The current POS system is end of life and needs to be replaced.
- Vancouver Park Board (VPB) provides their clients with both mobile and in person food and beverage options at City Parks and Beaches and Pitch & Putts, in 15 locations with 27 POS Terminals. The POS system is not currently integrated with the accompanying pin pads for VPB and this is required. The City’s goal is to automate manual processes where possible with the POS Solution.
- The objective of the project is to replace the existing POS system (Point of Sale) in all locations, replace the existing pin pads with Moneris compliant pin pads to meet the City’s standard, and complete integrations with associated concessions applications including SAP, Moneris, TracRite Optimum Control, an inventory and recipe management application for VPB, and Momentus, an event management application for VCT, and either integrate with Tacit, the current mobile food ordering application, or have an option with the POS Solution for mobile food ordering.
- The managers within VCT and VPB will need access to reporting and analysis to allow them to:
- determine the total cost of inventory vs. sales
- identify where there may be opportunities to tailor food and beverages offerings for specific events and/or audiences
- identify how to optimize the City’s investment in the POS Solution
The City has invested many hours into creating the existing food and beverage menus/items/recipes: the successful proponent is expected to migrate the City’s data into a new POS platform and maintaining the data relationships, without losing or compromising any City data during the implementation of the POS solution.
Interested in PCI requirements? 68 page document will tell you
POS Vancouver COV PCI-DSS v4.0.1 Responsibility Matrix – Template
Excerpt (first two sections — 16 sections total)
1.1 Processes and mechanisms for installing and maintaining network security controls are defined
1.1.1 All security policies and operational procedures that are identified in Requirement 1 are:
•
Documented.
•
Kept up to date.
•
In use.
•
Known to all affected parties.
1.1.2 Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and unde
1.2 Network security controls (NSCs) are configured and maintained.
1.2.1 Configuration standards for NSC rulesets are:
•
Defined.
•
Implemented.
•
Maintained.
1.2.2 All changes to network connections and to configurations of NSCs are approved and managed in accordan
Requirement 6.5.1.
Applicability Notes
Changes to network connections include the addition, removal, or modification of a connection.
Changes to NSC configurations include those related to the component itself as well as those affecting how it pe
1.2.3 An accurate network diagram(s) is maintained that shows all connections between the CDE and other net
Applicability Notes
A current network diagram(s) or other technical or topological solution that identifies network connections and d
1.2.4 An accurate data-flow diagram(s) is maintained that meets the following:
•
Shows all account data flows across systems and networks.
•
Updated as needed upon changes to the environment.
Applicability Notes
A data-flow diagram(s) or other technical or topological solution that identifies flows of account data across syst
requirement.
1.2.5 All services, protocols and ports allowed are identified, approved, and have a defined business need.
1.2.6 Security features are defined and implemented for all services, protocols, and ports that are in use and co
1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effe
1.2.8 Configuration files for NSCs are:
•
Secured from unauthorized access.
•
Kept consistent with active network configurations.
Applicability Notes
Any file or setting used to configure or synchronize NSCs is considered to be a “configuration file.” This includes
settings, infrastructure as code, or other parameters that are backed up, archived, or stored remotely.
1.3 Network access to and from the cardholder data environment is restricted.
1.3.1 Inbound traffic to the CDE is restricted as follows:
•
To only traffic that is necessary,
•
All other traffic is specifically denied.
1.3.2 Outbound traffic from the CDE is restricted as follows:
•
To only traffic that is necessary.
•
All other traffic is specifically denied.1.3.3 NSCs are installed between all wireless networks and the CDE, regardless of whether the wireless networ
•
All wireless traffic from wireless networks into the CDE is denied by default.
•
Only wireless traffic with an authorized business purpose is allowed into the CDE.
1.4 Network connections between trusted and untrusted networks are controlled.
1.4.1 NSCs are implemented between trusted and untrusted networks.
1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted to:
•
Communications with system components that are authorized to provide publicly accessible services, proto
•
Stateful responses to communications initiated by system components in a trusted network.
•
All other traffic is denied.
Applicability Notes
The intent of this requirement is to address communication sessions between trusted and untrusted networks, r
This requirement does not limit the use of UDP or other connectionless network protocols if state is maintained
1.4.3 Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering th
1.4.4 System components that store cardholder data are not directly accessible from untrusted networks.
Applicability Notes
This requirement is not intended to apply to storage of account data in volatile memory but does apply where m
example, RAM disk). Account data can only be stored in volatile memory during the time necessary to support t
completion of the related payment card transaction).
1.4.5 The disclosure of internal IP addresses and routing information is limited to only authorized parties.
1.5 Risks to the CDE from computing devices that are able to connect to both untrusted networks a
1.5.1 Security controls are implemented on any computing devices, including company- and employee-owned d
(including the Internet) and the CDE as follows.
•
Specific configuration settings are defined to prevent threats being introduced into the entity’s network.
•
Security controls are actively running.
•
Security controls are not alterable by users of the computing devices unless specifically documented and a
limited period.
Applicability Notes
These security controls may be temporarily disabled only if there is legitimate technical need, as authorized by
controls need to be disabled for a specific purpose, it must be formally authorized. Additional security measures
which these security controls are not active.
This requirement applies to employee-owned and company-owned computing devices. Systems that cannot be
provide opportunities that malicious individuals may exploit.
Requirement 2: App
2.1 Processes and mechanisms for applying secure configurations to all system components are de
2.1.1 All security policies and operational procedures that are identified in Requirement 2 are:
•
Documented.
•
Kept up to date.
•
In use.
•
Known to all affected parties.
2.1.2 Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and unde
New requirement – effective immediately
2.2 System components are configured and managed securely.2.2.1 Configuration standards are developed, implemented, and maintained to:
•
Cover all system components.
•
Address all known security vulnerabilities.
•
Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.
•
Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.
•
Be applied when new systems are configured and verified as in place before or immediately after a system
2.2.2 Vendor default accounts are managed as follows:
•
If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6.
•
If the vendor default account(s) will not be used, the account is removed or disabled.
Applicability Notes
This applies to ALL vendor default accounts and passwords, including, but not limited to, those used by operatin
application and system accounts, point-of-sale (POS) terminals, payment applications, and Simple Network Mana
This requirement also applies where a system component is not installed within an entity’s environment, for exa
and are accessed via a cloud subscription service.
2.2.3 Primary functions requiring different security levels are managed as follows:
•
Only one primary function exists on a system component,
OR
•
Primary functions with differing security levels that exist on the same system component are isolated from
OR
•
Primary functions with differing security levels on the same system component are all secured to the level
2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionalit
2.2.5 If any insecure services, protocols, or daemons are present:
•
Business justification is documented.
•
Additional security features are documented and implemented that reduce the risk of using insecure servic
2.2.6 System security parameters are configured to prevent misuse.
2.2.7 All non-console administrative access is encrypted using strong cryptography.
Applicability Notes
This includes administrative access via browser-based interfaces and application programming interfaces (APIs)
2.3 Wireless environments are configured and managed securely.
2.3.1 For wireless environments connected to the CDE or transmitting account data, all wireless vendor default
secure, including but not limited to:
•
Default wireless encryption keys.
•
Passwords on wireless access points.
•
SNMP defaults,
•
Any other security-related wireless vendor defaults.
Applicability Notes
This includes, but is not limited to, default wireless encryption keys, passwords on wireless access points, SNMP
defaults.
2.3.2 For wireless environments connected to the CDE or transmitting account data, wireless encryption keys a
•
Whenever personnel with knowledge of the key leave the company or the role for which the knowledge wa
•
Whenever a key is suspected of or known to be compromised.
Requir
3.1 Processes and mechanisms for protecting stored account data are defined and understood.