How Microsoft Dynamics RMS can help with PCI compliance
IMPORTANT! This document applies to Microsoft Dynamics RMS 2.0 Service Pack 3.
If you accept credit card payments in your store, you are required to comply with the Payment Card Industry (PCI) Data Security Standard. This standard has been adopted by most major card brands, including Visa, MasterCard, American Express, Diners Club, Discover Network, and JCB. It sets out twelve requirements that merchants must meet in order to protect cardholder information.
In this document, we'll discuss ways that Microsoft Dynamics Retail Management System (RMS) can help stores comply with the standard, and we'll set out some specific responsibilities that store owners must meet in order to make a Microsoft Dynamics RMS system compliant with the standard.
Note
This document is not intended to replace or stand in place of the PCI Data Security Standard and should not be exclusively relied upon to comply with the standard or with other requirements set out by your bank. Microsoft strongly recommends reviewing the full text of the PCI Data Security Standard, available at https://www.pcisecuritystandards.org/.
Microsoft also strongly recommends implementing Microsoft Dynamics RMS into a secure environment and according to the recommendations in this document. Keep in mind that the use of Microsoft Dynamics RMS alone is not enough to comply with the PCI Data Security Standard.
With integrated payment processing, Microsoft Dynamics RMS is considered a payment application. Credit card industry guidelines for the development of payment applications—such as the guidelines set out in Visa's Payment Application Best Practices publication—are intended to promote more secure payment applications and, in turn, facilitate merchant compliance with the PCI Data Security Standard. Payment applications that have been validated against these development standards minimize the potential for security breaches that lead to fraudulent card use.
Both Payment Application Best Practices and the PCI Data Security Standard were used as guidelines during the development and testing of Microsoft Dynamics RMS, and a PCI Security Standards Council Qualified Security Assessor audited the software prior to its release.
In order to help our users comply with the PCI Data Security Standard, and in order to pass the PCI audit, Microsoft implemented the following features and security measures in Microsoft Dynamics RMS:
•
Full magnetic stripe or CVV2 data is not retained. Microsoft Dynamics RMS does not store sensitive authentication data subsequent to authorization, PIN numbers and card validation codes are never stored, and account numbers are either masked, encrypted, or both. Beyond the time they have the customer's actual card in hand, store employees do not ever have access to customer card numbers.
•
Cardholder information that was stored by previous releases of Microsoft Dynamics RMS is securely deleted when the database is upgraded to the latest release.
•
Encryption keys can be replaced regularly, and old keys are not retained. For more information about encryption, see “General recommendations” below.
•
Microsoft Dynamics RMS allows you to create a unique user account (employee ID and password) for each employee of the store. An employee cannot use Microsoft Dynamics RMS without a user account, and these user accounts are subject to the password policy you have established in Microsoft Dynamics RMS. For more information about setting up password policy, see "General recommendations" below.
•
Microsoft Dynamics RMS maintains event logs that record each time an employee logs on to Microsoft Dynamics; cashier creation, deletion, and security rights changes; and transaction access, settlement, printing, and deletion from the store database. For more information about event logging, see “Monitoring employee activities using logs and reports” later in this document.
•
Microsoft Dynamics RMS was developed using industry best practices, with emphasis on information security throughout the development lifecycle, and according to Microsoft's rigorous internal security guidelines. Thorough testing of all security and configuration features was performed.
•
Microsoft does not support the use of wireless connections for Microsoft Dynamics RMS database communication. If you choose to use a wireless connection in spite of this restriction, see the information about increasing the security of wireless connections in "General recommendations" later in this document.
•
Microsoft Dynamics RMS and its component software were thoroughly tested for known security vulnerabilities. As new vulnerabilities are discovered, Microsoft is committed to responding promptly with security patches, upgrades, or other solutions.
•
Any security patches or other updates that become available for Microsoft Dynamics RMS will be offered for download rather than being provided via remote access to the store network. Updates will only be downloaded and installed at your request. Additionally, updates are available only via a password-protected Web site.
•
Microsoft Dynamics RMS can be implemented with confidence into a secure network environment. The program will not interfere with network address translation (NAT), port address translation (PAT), traffic filtering network devices, antivirus protection, patch or update installation, or the use of encryption.
•
Microsoft Dynamics RMS does not provide Internet access to stored cardholder data, and it does not require placement of the store database either on a Web server or in the "demilitarized zone" (DMZ) with the Web server.
•
Microsoft Dynamics RMS does not enable remote access.
•
Transmissions of cardholder data over public networks and the Internet are encrypted using Secure Sockets Layer (SSL) 128-bit safeguards.
•
Microsoft Dynamics RMS does not allow users to view card numbers or to send cardholder information via e-mail messages.
•
Web-based or remote administration, including non-console administration, is not supported by Microsoft Dynamics RMS.
How Microsoft handles sensitive data when addressing support requests
This section outlines the process that Microsoft follows when a Microsoft Dynamics RMS customer contacts us for support. This process is designed to ensure the security of sensitive information in the customer’s store database, including payment-related data such as employee passwords or credit card numbers. The store database is the only place that contains sensitive cardholder information.
The Microsoft Dynamics RMS team never collects sensitive data from the customer. If we require sensitive data in order to solve the problem, we go to the customer site. Data at the customer site is secured by the customer.
1.
The customer contacts Microsoft Technical Support.
When a customer contacts Microsoft Technical Support, the support engineer creates a report of the issue in Product Studio, the bug-tracking software we use for tracking customer issues.
2.
The product team attempts to reproduce the issue on test databases.
Using Microsoft test databases and, if needed, test credit-card accounts, members of the Microsoft Dynamics RMS product team attempt to reproduce the reported issue. Sensitive data is not collected from the customer.
3.
The product team attempts to reproduce the issue at the store.
If the issue cannot be reproduced on test databases, Microsoft personnel might travel to the customer’s location and attempt to reproduce the issue there. At the store, the database is subject to all of the customer’s security measures. Microsoft personnel will not bring customer databases back to Microsoft.
4.
A hotfix is released.
If the issue can be reproduced, a resolution is prepared and issued to the customer by means of a hotfix. Hotfixes are distributed via download from the Microsoft Web site, at the customer’s specific request. Microsoft employees never access the customer’s computers remotely.
In this section, we'll provide some general recommendations for complying with the PCI Data Security Standard.
Important! To ensure that you are fully compliant, read and implement the entire list of requirements in the PCI Data Security Standard. The standard includes very detailed and specific rules for merchants. It is available at https://www.pcisecuritystandards.org.
You should:
•
In Microsoft SQL Server, disable or prohibit the use of the Microsoft SQL Server "sa" account when accessing the store database. For more information, see SQL Server 2005 Security Best Practices. If you leave the account enabled, be sure to assign a complex password.
•
Direct cashiers to log on to Windows using an account that does not have administrator access. For more information, search for "user accounts" in Windows Help.
•
Control access to Microsoft Dynamics RMS and your store data by assigning a unique employee ID and password to each employee. Do not allow employees to share IDs or passwords. For more information, see "Managing cashier information" and "Changing an employee password" in Store Operations Online Help.
•
Use the preferred-acquirer solution for payment processing.
•
Use Store Operations Administrator to set up a password policy for your store. Require the use of passwords that meet these requirements:
Minimum password length
7 characters
Password complexity
Require complex passwords that use a mix of letters, numbers, and special characters
Maximum age of passwords
90 days
Password history/uniqueness
Do not allow new passwords to be identical to any of the last four (or more) passwords used by the employee
Account lockout
Lock user accounts after no more than six failed attempts, with the lockout period lasting at least 30 minutes
Periodically check the PCI Data Security Standard for the latest password requirements. For more information about implementing a password policy in Microsoft Dynamics RMS, see “Managing password policy” in Store Operations Administrator Online Help.
•
If you are using Microsoft Windows XP, turn off System Restore. The restore points saved by this feature are not PCI compliant. For more information, see Knowledge Base article 310405.
•
Perform regular audits and spot-checks of employee activities and program access, as described in “Monitoring employee activities using logs and reports” later in this document.
•
Periodically reset the encryption key for the store database. For more information, see “Setting the encryption key” in Store Operations Administrator Online Help.
•
If you choose to use wireless connections despite the fact that these connections are not supported for Microsoft Dynamics RMS database communications, make sure you are doing so in accordance with PCI requirements. For example, you should change the defaults on your wireless modem or router. These defaults might include (but are not limited to) the wired equivalent privacy (WEP) keys, default service set identifier (SSID), passwords, SNMP community strings, or other settings. Also, disable SSID broadcasts and, when capable, enable WiFi protected access (WPA and WPA2) technology for encryption and authentication.
•
Orders downloaded from the Web to Microsoft Dynamics RMS may contain unencrypted credit card numbers. These orders (XML files) are directly imported into the Exchange Table in the Microsoft Dynamics RMS database. Make sure to delete these credit card numbers after the transactions have been settled. To be compliant with the Payment Card Industry (PCI) Data Security Standard, unencrypted credit card numbers cannot be stored.
•
Refrain from storing cardholder data on servers or computers that are connected to the Internet.
Note The PCI Data Security Standard recommends the use of a dedicated database computer. Microsoft facilitates this by allowing you to install an extra copy of Microsoft Dynamics RMS—at no additional charge—on a back-office computer that will not be used to process sales transactions.
In this section, we'll provide some specific recommendations for complying with each of the requirements of the PCI Data Security Standard.
Build and Maintain a Secure Network
1
Install and maintain a firewall configuration to protect cardholder data
In addition to hundreds of available security and policy settings, Microsoft Windows XP Service Pack 2, Windows Vista, and Windows Server 2003 include Windows Firewall, a built-in firewall that will help protect your store computers from viruses, computer worms, and unauthorized connections. For more information, search for "Windows Firewall" and "security policy" in Windows Help. In Windows Server 2003 Help, search for “Internet Connection Firewall”.
2
Do not use vendor-supplied defaults for system passwords and other security parameters
After logging in the first time, secure the default user account in Microsoft Dynamics RMS. You can create a new user account that has full administrative access to the program, log on using the new account, and then delete the default account. At a minimum, you should change the password for the default account. For more information, see "Managing cashier information" and "Changing an employee password" in Store Operations Online Help.
Protect Cardholder Data
3
Protect stored cardholder data
In addition to the masking and encryption in the store database, you can use the Encrypting File System (EFS) in Windows to encrypt the files and folders on your computers. For more information, search for "Encrypting File System" in Windows Help.
Encrypt transmission of cardholder data across open, public networks
As mentioned earlier, Microsoft Dynamics RMS encrypts all cardholder data and uses 128-bit-encrypted SSL transmissions. In addition, built-in services in Windows support Point-to-Point Tunneling Protocol (PPTP) and Internet Protocol security (IPSec). For more information, search for "point-to-point tunneling protocol", "IPSec", or "virtual private network" in Windows Help. For information about securing wireless connections, see the "General recommendations" above.
Encryption keys from previous releases of Microsoft Dynamics RMS are securely deleted when the database is upgraded to the most recent release. The current encryption key is not visible to employees, is itself stored in encrypted format, and cannot be distributed.
In addition, whenever you reset the encryption key—something that should be done at least once a year or in case of any security breach—the old encryption key is securely deleted and replaced by a new key. Only database administrators can reset the encryption key. For more information about resetting the encryption key, see “Setting the encryption key” in Store Operations Administrator Online Help.
Maintain a Vulnerability Management Program
5
Use and regularly update anti-virus software
Windows Firewall is a primary defense against viruses, worms, and the like. Additional security should be provided by your specific antivirus software. In Control Panel, use the Security Center to manage updates of antivirus software. For more information, search for "Windows Firewall", "antivirus software", or "Security Center" in Windows Help.
6
Develop and maintain secure systems and applications
Use Microsoft Update to receive the latest security patches and software updates for Microsoft software. For maximum protection, set your computer to receive updates automatically. For more information, search for "Windows Update" and "Microsoft Update" in Windows Help or on http://www.microsoft.com.
Microsoft Dynamics RMS users on service plans have access to Microsoft Dynamics RMS updates and service packs become available. For more information about service plans, contact your partner, or visit the Microsoft Dynamics RMS Web site at http://www.microsoft.com/msrms and then click Services & Support. The latest updates are also announced on the Using Microsoft Dynamics RMS site.
Implement Strong Access Control Measures
7
Restrict access to cardholder data by business need-to-know
In Control Panel, use User Accounts to manage user profiles and access. In Windows Explorer, set permissions on sensitive files and folders so that only specific users or groups of users have access. For more information, search for "user accounts", "creating user accounts", or "file and folder permissions" in Windows Help.
You can also set up security—employee by employee—for many of the features in Microsoft Dynamics RMS. For more information, see "Setting up security structure" in Store Operations Online Help.
8
Assign a unique ID to each person with computer access
See "General recommendations" earlier in this document.
You can use a screen saver that requires entry of a password to meet the idle terminal requirement of subsection 8.5.15. For more information, search for “screen saver” in Windows Help.
9
Restrict physical access to cardholder data
For some tips for making your physical location more secure, see these articles on www.microsoft.com:
Track and monitor all access to network resources and cardholder data
The Windows Firewall security log is a record of successful connections that go through the firewall and connections that are blocked (also known as "dropped packets"). The Event Viewer maintains logs about programs, security, and system events on your computer. Windows system clocks are routinely synchronized, either by a network time server or by an Internet time server. For more information about these features, search Windows Help for "security log", "Event Viewer", or "date and time", respectively.
With Microsoft Dynamics RMS reports, you can watch for unusual activity, such as unusual sales figures, high numbers of returns, and so on. For example, the Cashier Log report shows a summary of the activities performed by each cashier, while a daily Z report shows detailed information about the transactions that took place on a register. You can also view the Store Operations audit logs to obtain detailed information about employee access to sensitive information. For more information, see "Monitoring employee activities using logs and reports” later in this document.
Finally, to track actions taken by individuals who have administrative privileges for the database, you can enable C2 auditing. For more information, see “Enabling C2 auditing in Microsoft SQL Server” and “Reviewing C2 audit trace files” later in this document.
11
Regularly test security systems and processes
Windows Firewall and Windows Defender can help you protect your system and detect threats. Both tools are provided with Windows Vista. Windows Firewall is also available in Windows XP, and Internet Connection Firewall is provided in Windows Server 2003. You can download Windows Defender from the Microsoft Download Center.
Windows Live OneCare offers antivirus, spyware, and online ID protection, in addition to providing a firewall. For more information, see Windows Live OneCare.
Internet Protocol Security (IPSec) is a key line of defense against internal, private network, and external security attacks. For more information, search for "IPSec" in Windows Help.
As with Requirement 10, Microsoft Dynamics RMS provides a number of reports that will help you watch for unusual store activity. For more information, see "Generating reports" in Store Operations Online Help.
Maintain an Information Security Policy
12
Maintain a policy that addresses information security
As a supplement to the security policy that you develop to comply with this requirement, you can set up security—employee by employee—for many of the features in Microsoft Dynamics RMS. For more information, see "Setting up security structure" in Store Operations Online Help.
Monitoring employee activities using logs and reports
There are a number of tools that will help you monitor employee access to Microsoft Dynamics RMS and your store information.
Tool
Information provided
Cashier Log report
Times and dates of each cashier’s access to Store Operations POS.
Manager Login query
Times and dates of each employee’s access to Store Operations Manager
Operations Log query
Failed login attempts Cashier creation and deletion Changes to cashier user ID, rights, or security level Batch settlement and outcome Transaction or journal view from Store Operations Manager Journal printing from Store Operations Manager Transaction deletion by database administrator
Credit Card Transaction Detail query
Credit card transactions processed by each employee, with card expiration date and last four digits of card number
Debit Card Transaction Detail query
Debit card transactions processed by each employee, with card expiration date and last four digits of card number
Viewing the Cashier Log
1.
On the Reports menu in Store Operations Manager, point to Miscellaneous, and then click Cashier Log.
2.
In the From and To boxes, type the start and end dates for the date range you are interested in, and then click Change.
3.
Click OK to generate the report.
Viewing audit-log information using a database query
1.
Click here to download the auditing queries. Save the .zip file to a computer where Store Operations is installed.
2.
Open the .zip file and extract the queries to a folder on the computer.
3.
On the File menu in Store Operations Administrator, click Connect, specify database administrator credentials, select the store database, and then click OK.
4.
On the File menu, click Open, browse to the folder where you extracted the query files, and then double-click the query that you want to run.
Cashier Number: The login ID of the employee who logged in. Name: The employee who logged in. Register ID: The register where the login occurred. Logged In: The date and time the employee logged in. Logged Out: The date and time the employee logged out. Hours: The amount of time the employee was logged in. Rights: Whether the employee was logged in with manager rights or administrator rights.
Cashier ID: The internal database ID of the employee who performed the operation. Cashier Number: The login ID of the employee who performed the operation. Cashier Name: The employee who performed the operation. Operation ID: An internal number associated with the type of operation that was performed. Operation Performed: A description of the operation that was performed. Record ID: The code or ID of the database record associated with the operation, such as the number of the cashier whose record was modified. Additional Information: More details about the operation. Date and Time of Operation: The date and time at which the operation occurred.
Cashier Name: The employee who rang up the sale. Cashier Number: The login ID of the employee who rang up the sale. Description: The name of the tender type that was used. Transaction Number: The number of the transaction within the batch. Credit Card Number: The masked number of the credit card used in the transaction. Expiration Date: The expiration date of the credit card used in the transaction. Date and Time of Transaction: The date and time at which the transaction took place.
Cashier Name: The employee who rang up the sale. Cashier Number: The login ID of the employee who rang up the sale. Description: The name of the tender type that was used. Transaction Number: The number of the transaction within the batch. Debit Card Number: The masked number of the debit card used in the transaction. Expiration Date: The expiration date of the credit card used in the transaction. Date and Time of Transaction: The date and time at which the transaction took place.
Deleting audit logs
The PCI Data Security Standard recommends saving audit logs for at least one year. Older logs can be securely deleted periodically to save space in the store database and on the hard drive. For more information, see “Deleting audit logs” in Store Operations Administrator Online Help.
The reports and tools described in the preceding section provide most of the assessment trail specified by Requirement 10 of the PCI Data Security Standard. To monitor activities by database administrators, such as the times when an administrator has logged in or viewed the audit log table in the Microsoft Dynamics RMS database, you can enable SQL Server C2 auditing. With C2 auditing turned on, you can monitor actions taken by individuals who have administrative privileges on the database.
About C2 auditing
C2 refers to a security rating for computer software that was established by the U.S. National Computer Security Center (NCSC). It specifies that individuals must log on with a password, that an audit mechanism must be in place, and that access to audit data must be limited to authorized administrators. C2 auditing does not prevent system attacks, but it is a vital aid in identifying intruders and attacks in progress and diagnosing attack footprints.
Tools for enabling C2 auditing
Any of these SQL Server tools can be used to enable C2 auditing in SQL Server:
C2 Audit Mode data is saved in a log file in the Data directory for your database. If the audit log file reaches its size limit of 200 megabytes, SQL Server will create a new file, close the old file, and write all new audit records to the new file. This process will continue until the Data directory fills up or auditing is turned off.
•
C2 Audit Mode saves a large amount of event information, so the database log file can grow quickly. If the Data directory runs out of space, SQL Server will shut itself down. If auditing is set to start up automatically, you must free up disk space for the audit log before you can restart the instance of SQL Server. When deleting audit logs, keep in mind that the PCI Data Security Standard requires records to be maintained for at least one year.
To enable C2 auditing using SQL Server Management Studio Express
1.
On the Start menu, click All Programs, click Microsoft SQL Server 2005, and then click SQL Server Management Studio Express.
2.
In the Connect to Server dialog box, specify the following settings:
•
In the Server type box, “Database Engine”.
•
In the Server name box, server_name\instance_name
where: server_name equals the name of the computer where SQL Server is installed instance_name equals the name of the instance of SQL Server that Microsoft Dynamics RMS is using
Typically, Microsoft Dynamics RMS uses the default instance, so you can just type the server name.
•
In the Authentication box, Windows Authentication.
3.
Click Connect.
4.
Right-click the instance that you specified in step 2, and then click Properties.
5.
In the Server Properties window, click Security.
6.
Under Login auditing, select Both failed and successful logins.
7.
Under Options, select Enable C2 audit tracing.
8.
Click OK.
9.
Right-click the instance and click Stop, and then right-click the instance and click Start.
To enable C2 auditing by using the sqlcmd command-line utility
Note In the command lines that follow, be sure to substitute the correct instance name for “RMSINSTANCE” and the correct database name for “MSRMS”. For example, if you are using the default instance and a database named “MyStore,” you would type this for the first command line:
In the table that appears, confirm that the run_value for the c2 audit mode option is set to 1 (turned on).
To enable C2 auditing by using the osql command-line utility (SQL Server 2000)
Note In the command lines that follow, be sure to substitute the correct instance name for “RMSINSTANCE” and the correct database name for “MSRMS”. For example, if you are using the default instance and a database named “MyStore,” you would type this for the first command line:
The C2 auditing in SQL Server captures a lot of information for each audited event, including an account of all grant/revoke/deny access checks and a record of all points where the database owner decided to grant access. You can view this information by reviewing the audit trace files.
What to look for in the audit trace file
If you are using the other audit tools described earlier in this document to satisfy most PCI audit requirements, the events you will need to view in the C2 audit trace files are logins by database-administrator logins and views of the Microsoft Dynamics RMS audit log table. Both of these events will show up in the audit trace file as events in the Store Operations Administrator application. The following table shows the statement text to look for to locate these events.
To locate this type of event
Look for statements (TextData) that begin with this text
Logins by administrators
if (object_id(‘master.dbo.sp_MSSQLDM090_version’) is not null)…
Views of the audit log table
select * from AuditLog
Each event will show the SQL user who performed the action.
To review a trace audit file using SQL Server Management Studio Express
1.
In SQL Server Management Studio Express, connect to the SQL server and database instance.
2.
Right-click the instance, and then click Stop.
3.
On the File menu, point to Open, and then click File.
4.
Navigate to the folder where the Microsoft Dynamics RMS data and trace files are located.
5.
Use the dates within the file names to locate the trace (.trc) file you want, select it, and then click Open.
The trace file will open in SQL Profiler where you can view event details.
6.
When you are done reviewing the trace file, close it, and then right-click the instance and click Start.
To review a trace audit file directly in SQL Profiler (SQL Server 2000)
1.
On the Start menu, click All Programs, click Microsoft SQL Server 2000, and then click Profiler.
2.
On the File menu, click Open, and then click Trace File.
3.
Navigate to the folder where the Microsoft Dynamics RMS data and trace files are located.
4.
Use the dates within the file names to locate the trace (.trc) file you want, select it, and then click Open.
Note You will not be able to open the log file to which SQL Server is logging activity. If you need to access data in the current audit log, you will need to stop the SQL server, view the log, and then restart the server.
Note
