SecureAuth, Remote Access and PCI DSS Compliance
By Garret Grajek, CISSP
COO, MultiFactor Corp.
Not only has PCI become a requirement by the payment card industry, but it has become and example to all organizations of how practical security can be implemented and business continuity maintained. For many years the concern over the cost of implementing solutions securely has outweighed concern over the impact of failed security. Over the last few years, growing headline breaches have created an atmosphere of awareness of the damages a breach can cause to an organizations financial structure and reputation.
The key PCI DSS requirements for an authentication solution that proposes to aid in compliance are:
- Requirement 8: Assign a unique ID to each person with computer access
- Requirement 8.5 Ensure proper user authentication
Requirement 8: Assign a unique ID to each person with computer access
PCI DSS Requirement 8.1: Identify all users with a unique username before allowing them to access system components or cardholder data
SecureAuth for Cisco VPN authentication is designed for enterprises to easily meet the requirement of distributing individual user IDs to end-users. SecureAuth provides a methodology of user self-enrollment, to securely distribute PCI-compliant authentication credentials (X.509 credentials are PCI compliant, see PCI DSS Requirement 8.2).
PCI DSS Requirement 8.2: Employ authentication, in addition to unique identification for all users
SecureAuth for Cisco VPN creates a secure user credential which is mapped to an enterprise-mapped UserID. The SecureAuth credential is utilized by the Cisco VPN appliance to securely identify and authenticate the user. The UserID is in the SecureAuth credential presented to the Cisco VPN appliance upon attempted access by the end-user. (See Diagram #1)
Figure #1 – SecureAuth creates and utilizes a unique ID per user (click to enlarge)
PCI DSS Requirement 8.3: Implement two-factor authentication for remote access to the network by employees, administrators, and third parties
SecureAuth is a two-factor authentication solution that utilizes the SecureAuth X.509 credential and the enterprise-stored password.
SecureAuth for Cisco VPN authentication works in conjunction with the
Cisco appliance to authenticate a user with the securely delivered SecureAuth X.509 credentials. (The SecureAuth X.509 credential meets the 8.5 PCI DSS requirement for “individual certificate”) . The Cisco VPN is set to utilize “AAA + Certificate” authentication, thus enabling “true” 2-factor authentication: the user must have both the SecureAuth certificate and input the password associated with the user’s account. (See Figure #2)
Figure #2 – The Cisco VPN is set to utilize both “AAA + SecureAuth Certificate” authentication (click to enlarge)
SecureAuth differentiates itself in the marketplace by providing the easiest to deploy certificate solution to meet the 8.3 PCI DSS requirement.
PCI DSS Requirement 8.4: Encrypt all passwords during transmission and storage, on all system components
MultiFactor SecureAuth for Cisco VPN authentication does NOT have its own user credential and password datastore. MultiFactor utilizes the directory (AD, ADAM, LDAP) that the Cisco VPN is using natively. (See Figure #2)
This helps the enterprise meet PCI DSS Requirement #8.4. The enterprise does NOT have to create sync and encrypt a new set of data information.Figure #3 – SecureAuth utilizes the native user store the enterprise has connected to the Cisco VPN. (click to enlarge)
PCI DSS Requirement 8.5: Ensure proper user authentication and password management for non-consumer users and administrators, on all system components
The MultiFactor SecureAuth appliance is administered via a secure GUI. All administrators are required to authenticate via strong 2-factor SecureAuth authentication. (Certificate plus UserID/password) . (See Figure #4)
Figure #4 – SecureAuth Administrators must uniquely authenticate utilize secure 2-factor X.509 authentication. (click to enlarge)
PCI DSS Requirement 8.5.1: Control addition, deletion, and modification of user IDs, credentials, and other identifier objects
SecureAuth administration accounts are uniquely created and associated with individual accounts, therefore configuration modifications are associated with specific administrators, as outlined in PCI DSS requirement 8.5.1.
PCI DSS Requirement 8.5.2: Verify user identity before performing password resets
SecureAuth requires end-users to perform a 2-factor authentication, “certificate + password” before they are allowed to modify their passwords. The PCI DSS 8.5.2 requirement is met by forcing users to strongly authenticate before modification of their password.
PCI DSS Requirement 8.5.3: Set first-time passwords to a unique value for each user and change immediately after first use
SecureAuth works in conjunction with the Cisco ASA to reset passwords on first usage. The Cisco ASA sees the “must change password” attribute set in the data store, and gives end-usesr the appropriate screens to change their passwords.
PCI DSS Requirement 8.5.4: Immediately revoke access for any terminated users
MultiFactor SecureAuth is unique in X.509 authentication solutions by providing instant revocation. By removing any terminated individuals on the data store of record, SecureAuth facilitates one-button revocation (See Figure #3)
SecureAuth for Cisco VPN Authentication requires the end-user to have both a valid SecureAuth certificate and authenticate with a valid password. (See figure #2). If the user is removed from the data store, Cisco VPN, utilizing SecureAuth authentication, will not grant access to that terminated user.
PCI DSS Requirement 8.5.5: Remove inactive accounts at least every 90 days
An enterprise can set the SecureAuth credential to be valid for 90 days or less, thereby forcing users to re-authenticate every 90 days.
PCI DSS Requirement 8.5.6: Enable accounts used by vendors for remote maintenance only during the time period needed
MultiFactor SecureAuth has a configurable certificate length that can be set in accordance to security and resource requirements. Enterprises are asked, by PCI DSS requirement 8.5.6, to create credentials that are time-configurable. SecureAuth offers this feature.
PCI DSS Requirement 8.5.7: Communicate password procedures and policies to all users who have access to cardholder data admin
MultiFactor SecureAuth is a user self-enrollment product that “walks an end-user through” an easy process, to obtain a secure credential. Additionally, the product utilizes the enterprise datastore and thus the password policies around these IDs.
PCI DSS Requirement 8.5.8: Do not use group, shared or generic accounts and password
SecureAuth for Cisco VPN authentication makes this requirement obtainable for enterprises. Users share accounts because of the pain in distributing unique authentication to individuals. SecurAuth’s unique self-enrollment for X.509 credentials makes compliance to this requirement possible.
PCI DSS Requirement 8.5.9: Change user password at least every 90 days
SecureAuth is an effective tool in meeting PCI DSS Requirement 8.5.9. The requirement requires an enterprise to change the password every 90 days. SecureAuth requires the end-user to change his or her security credential every 90 days (Or whatever time the enterprise determines). The SecureAuth authentication credential can be set from 1 hour to 10 years. SecureAuth enables an enterprise to meet the requirement today, and adjust accordingly, should the requirement change. (Figure #5)
Figure #5 - Enterprises can select the length of the certificate for their end-users. (Click to enlarge)
PCI DSS Requirement 8.5.10: Require a minimum password length of at least seven characters
SecureAuth utilizes the enterprise’s Datastore (See Figure #3); therefore, whatever configuration the enterprise sets on its data store, it will ultimately be enforced by the SecureAuth appliance during certificate enrollment. This same policy is also enforced by the Cisco VPN during “AAA + Certificate” Authentication (See Figure #2).
PCI DSS Requirement 8.5.11: Use passwords containing both numeric and alphabetic characters.
SecureAuth utilizes the enterprise’s Datastore (See Figure #3).; therefore, whatever configuration the enterprise sets on its data store, it will ultimately be enforced by the SecureAuth appliance during certificate enrollment. This same policy is also enforced by the Cisco VPN during “AAA + Certificate” Authentication (See Figure #2).
PCI DSS Requirement 8.5.12: 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.
SecureAuth utilizes the enterprise’s Datastore (See Figure #3). ); therefore, whatever configuration the enterprise sets on its data store, it will ultimately be enforced by the SecureAuth appliance during certificate enrollment (See Figure #2).
PCI DSS Requirement 8.5.13: Limit repeated access attempts by locking out the user ID after not more than six attempts
SecureAuth for Cisco VPN authentication has a lock-out feature for registration. The default for this configurable feature is (3) attempts.
PCI DSS Requirement 8.5.14: Set the lockout duration to thirty minutes or until administrator enables the user ID
In accordance with requirement 8.5.14, accounts can be locked out by configuring the data store from which SecureAuth is pulling data (See Figure #3).
PCI DSS Requirement 8.5.15: If a session has been idle for more than 15 minutes, require the user to re-enter the password to re-activate the terminal
The SecureAuth/Cisco VPN solution relies on the Cisco VPN settings for session duration and session idle enforcement. This setting is set in the Cisco VPN, to enforce session idle.
PCI DSS Requirement 8.5.16: Authenticate all access to any database containing cardholder data. This includes access applications, administrators, and all other users
SecureAuth does not have its own data store; therefore the effort that the enterprise puts into securing access to the “data store of record” can be used by SecureAuth; no additional work is needed, given that there is no additional data store. (See Figure #3)