The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that all companies that process, store or transmit credit card information maintain a secure environment: Essentially any merchant that has a Merchant ID (MID).
PCI applies to all organizations or merchants, regardless of size or number of transactions, that accepts, transmits or stores any cardholder data. Said another way, if any customer of that organization ever pays the merchant directly using a credit card or debit card, then the PCI DSS requirements apply.
GET A QUOTE. REQUEST A FREE EVALUATION.
| PCI REQUIREMENT | NETWRIX SOLUTION |
| 7. Restrict access to cardholder data by business need-to-know | |
| 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. | Auditing functionality to monitor all security-related changes in Active Directory, Group Policy, Exchange, file servers, SQL Servers, virtualization environments. Audited use of high-privileged system accounts. |
| 7.2 Establish a mechanism for systems with multiple users that restricts access based on a user´s need to know and is set to “deny all” unless specifically allowed. | Monitoring of file and folders and their permissions, Active Directory and Group Policy objects, SQL Server security for early detection of unauthorized changes to security access settings (e.g. granting of new permissions). |
| 8. Assign a unique ID to each person with computer access | |
| 8.1 Assign all users with a unique user name before allowing them to access system components or cardholder data. | Complete auditing of user logons to analyze violations and prevent usage of the same ID by multiple persons (e.g. from different computers). |
| 8.5.1 Control addition, deletion, and modification of user IDs, credentials and other identifier objects. | Full auditing of user account creations, deletions, password resets, and modifications to all user account attributes: in Active Directory and SQL Server. |
| 8.5.2 Verify user identity before performing password resets. | Web-based challenge-response system based on verification question/answer pairs selected by users upon enrollment, with full control over the number of required verification answers. The same data can be used by help desk personnel to assist with password resets on the phone. |
| 8.5.3 Set first-time passwords to a unique value for each user and change immediately after the first use. | Auditing of all newly created user accounts and their initial attributes (including “must change at next logon”) to prevent violations. |
| 8.5.4 Immediately revoke access for any terminated users. | Auditing of disabled accounts, automated de-provisioning of inactive user accounts. |
| 8.5.5 Remove or disable inactive user accounts at least every 90 days. | Automated disabling and removal with full reporting. |
| 8.5.6 Enable accounts used by vendors for remote maintenance only during the time period needed. | Auditing of account creation, enabling, disabling, and deletion, with time stamps to analyze their lifetime. |
| 8.5.7 Communicate password procedures and policies to all users who have access to cardholder data. | Automatic customizable reminders for expiring passwords, redirection to password requirements document if user enters “weak” password during reset. |
| 8.5.8 Do not use group, shared, or generic accounts and passwords. | Full auditing of account use (find all actions done under a shared account and help eliminate its usage) and delegated access with account checkout/check-in concept. |
| 8.5.9 Change user passwords at least every 90 days. | Audits changes to password policy settings in Active Directory, automatically reminds users about impending password expirations, provides easy way to change passwords to minimize the number of help desk calls. |
| 8.5.10 – 8.5.12 Password complexity requirements (Require a minimum password length of at least seven characters, Use passwords containing both numeric and alphabetic characters, Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used). | Audits changes to password policies in Active Directory, implements selfservice password reset functionality to help users with forgotten passwords without involvement of help desk personnel. |
| 8.5.13 Limit repeated access attempts by locking out the user ID after not more than six attempts. | Complements the built-in AD mechanism with extensive account lockout troubleshooting capabilities to resolve false positives and prevent user frustration and system downtime. Auditing of account unlock and password reset operations to monitor unauthorized access. |
| 8.5.14 Set the lockout duration to thirty minutes or until administrator enables the user ID. | Auditing of account lockout policy changes to prevent non-compliant policy changes. |
| 8.5.16 Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users. | Auditing of changes to database logins and roles, SQL server security settings. |
| 10. Track and monitor all access to network resources and cardholder data | |
| 10.1 Establish a process for linking all access to system components (especially those done with administrative privileges such as root) to each individual user. | Full features auditing and reporting of all administrative activity within Active Directory, Group Policy, file servers, virtualization environments, SQL Server, etc. Detection of who changed what, when, and where. |
| 10.2 Implement automated audit trails to reconstruct the required events. | Complete audit trail processing capabilities for servers and workstations, both user-initiated and administrative activity. |
| 10.3 Record at least the following audit trail entries for all system components for each event: User identification, Type of event, Date and time, Success or failure indication, Origination of event, Identity or name of affected data, system component, or resource. | Full information of every change: who changed what, when, where, in Active Directory, File Server, virtual machines, SQL Servers. |
| 10.5 Secure audit trails so they cannot be altered. | Securable file-based storage with optional SQL Server storage. Fullfeatured role based access to all reports. Centralized collection, archiving, and consolidation of event logs to secure file-based storage. |
| 10.6 Review logs for all system components at least daily. | Full-featured web-based reporting functionality with predefined reports and ability to create custom reports on any type of collected data. Out-ofthe box reports scheduled daily and sent via e-mail for review. |
| 10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis. | Unlimited storage capabilities with efficient storage use to store up to 8 years of past audit trails and history of changes to system components and security settings. Full-featured web-based reporting for immediate access to all required data. |