How IBM i Answers PCI DSS Requirements for Strong Access Controls
The Payment Card Industry (PCI) Data Security Standard (DSS) requirements for strong access controls can be met by using a combination of native IBM i security best practices and third-party solutions. Unlike some of the other PCI DSS requirements which can be vague and hard to understand, never mind comply with, the PCI DSS strong access control requirements are quite clear.
This post is part of an ongoing series describing how an IBM i partition can meet PCI DSS requirements, with each post covering one set of requirements. This week, let’s look at the PCI DSS requirements to Implement Strong Access Control Measures, which includes requirement 7 to “Restrict access to cardholder data by business need- to-know” and requirement 8 to “Identify and authenticate access to systems components.”
Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 7 is very clear in what is it expects you to do. You must restrict access of your cardholder’s data to only those who need to know for a specific business reason (requirement 7.1). For all others, you must deny them access to the data (requirement 7.2).
With IBM i native security, you can easily restrict who has access to a specific file, with object level authorties. So, denying access to users who have no business in a specific file is easy to accomplish. The trickier situation is when you have a file that contains some cardholder data that the user needs to access, such as their credit card number and expiration date.
Take it one step further
Although not required in this specific point, you can further protect your sensitive data by having a way to track who is accessing a specific file and being able to report over any changes to the data. It doesn’t help to know that someone accessed the customer credit card records last month, after the records were breached. You want to know when it is happening. By putting in place a third-party solution with real time alerting, you can really protect your sensitive data.
Requirement 8: Identify and authenticate access to system components
Requirement 8 is also clear in its expectations. You must have a unique user ID for each user (requirement 8.1). You must employ at least one authentication method for access, including passwords/passphrases, smart devices, or biometric access (requirement 8.2). Users are also prohibited from using group, shared, or generic IDs when accessing the system (requirement 8.5). In addition, you must use multi-factor authentication for remote and non-console administrative users (Requirement 8.3). Please note that the need for multi-factor authentication is currently considered a best practice, but it will become a requirement after January 31, 2018. Passwords need to be encrypted while stored and in transition (requirement 8.2).
This is another situation where native IBM i security will help you to comply. It is common practice to require a user ID and password for signing on to IBM i, so this shouldn’t be an issue for anyone. Passwords on IBM i are encrypted natively, which means you don’t have to worry about this at all. Since IBM i never stores passwords as text, there is no way to retrieve a password from the system. While IBM i password security level 1 technically will meet this requirement, password level 2 or 3 is ideal as they use SHA-1 for encryption, satisfying requirement 8.2.
Where compliance with this requirement gets tricky is when you have users with elevated privileges such as QSECOFR. There are legitimate reasons to have QSECOFR authority; the problem is if you share security officer profile among users, than you have no way to track which user performed which tasks (and this practice is prohibited by requirement 8.5). To achieve separate QSECOFR access for critical users, you should provide a profile with QSECOFR authority for each user who needs elevated authorities and restrict access to the generic QSECOFR profile. This way you can track which user used QSECOFR authority and create an audit trail of what they did with it. It’s important that the user not be signed in all the time with this profile, as this puts you at risk. Users should be given the lowest authority they need to perform their day to day activities and they should have elevated authorities only when needed.
Finally, requirement 8.7 specifies that user access to any database containing cardholder data must be limited to “programmatic” access only. Users can only use pre-written applications for credit card data access. They must also be restricted from IBM i and remote functions that provide direct or query access, such as ODBC, SQL, FTP, QUERY, and DFU. Only database administrators can have direct and query access to credit card databases (also specified in requirement 8.7). In IBM I, you can use exit point processing to restrict remote access to credit card databases via SQL, FTP, QUERY, etc. IBM i also allows you to restrict users from command line access to direct and query commands and utilities.
How can SEA help you meet these requirements?
When paired with native IBM i security controls, SEA’s solutions can help ensure that you are in compliance with PCI DSS requirements. To comply with the specific requirements discussed in this article ,we suggest the following SEA solutions.
- iSecurity Authority on Demand can grant alternative security authority level or add additional security rights on request. The solution can report on QAUDJRN data and capture the user’s screen while temporary authority is granted.
- iSecurity Firewall can be used to determine if a user can access servers or exit points, specify what actions a user may perform in an exit point (for direct and query access restrictions), and provide additional security when accessing credit card databases.
- iSecurity AP-Journal provides a timeline report of all changes relating to application data, reduces unauthorized activity, and enables users to meet regulatory requirements. iSecurity AP-Journal also issues real-time alerts informing managers of any changes in application databases and/or unapproved access to critical data. In addition, iSecurity AP-Journal provides users the ability to retain critical security information, independent of the journal receiver lifecycle, with its advanced filtering that enables saving only important information.
Use this post as a starting point for determining your PCI DSS requirements needs, and take advantage of PCI DSS tools from other resources, including access to Qualified Security Assessors (QSAs) for assessing PCI DSS compliance and Self-Assessment Questionnaires (SAQs) for assessing your own PCI DSS compliance. SEA also offers the iSecurity Compliance Evaluator that can help you evaluate the state of your PCI DSS preparation. Please feel free to contact us at SEA for any questions or help with your PCI DSS needs.
