Townsend Security Data Privacy Blog
Here is an excerpt from section 8.3: (emphasis added)
8.3 Secure all individual non-console administrative access and all remote access to the cardholder data environment (CDE) using multi-factor authentication.
I recently was able to sit down with Patrick Townsend, Founder & CEO of Townsend Security, and talk with him about PCI DSS 3.2, what it means for IBM i users, and what IBM i users can do to meet the latest version of PCI DSS.
Thanks for taking some time to sit down with me, Patrick. Can you recap the new PCI-DSS version 3.2 multi-factor authentication requirement? This new requirement seems to be generating a lot of concern.
Well, I think the biggest change in PCI DSS 3.2 is the requirement for multi-factor authentication for all administrators in the cardholder data environment (CDE). Prior to 3.2, remote users like contractors and third party administrators, had to use multi-factor authentication to login to the network. This update extends the requirement of multi-factor authentication for ALL local, non-console users. We are seeing businesses deploy multi-factor authentication at the following levels:
Yeah, sounds like this is going to be a big challenge. What does this mean for your IBM i customers?
There are definitely some aspects of this PCI-DSS update that will be a bigger challenge on the IBM i compared to Windows or Linux. First, we tend to run more applications on the IBM i. In a Windows or Linux environment you might have one application per server. On the IBM i platform, it is not uncommon to run dozens of applications. What this means is, you have more users who have administrative privileges to authenticate – on average there can be 60 or more who can sometimes be a challenge to identify! When merchants and processors look at their IBM i platforms, they will be surprised at the number of administrators they will discover.
Additionally, the IBM i typically has many network services exposed (FTP, ODBC, Operations Navigator, etc). The challenge of identifying all the entry points is greater for an IBM i customer.
You say it is harder to identify an administrative user, why is that?
On the IBM i platform, there are some really easy and some really difficult administrative users to identify. For example, it is really easy to find users with QSECOFR (similar to a Windows Administrator or Linux Root User) privileges. But it starts to get a little more difficult when you need to identify users, for example, who have all object (*ALLOBJ) authority. These users have almost the equivalent authority of QSECOFR. Finding, identifying, and properly inventorying users as administrators can be a challenge.
Additionally, with a user profile, there is the notion of a group profile. It is possible for a standard user, who may not be an administrator, to have an administrative group profile. To make it even more complex, there are supplemental groups that can also adopt elevated authority. Just pause for a minute and think of the complex nature of user profiles and how people implement them on the IBM i platform. And don’t forget, you may have users on your system who are not highly privileged directly through their user profile, but may be performing administrative tasks related to the CDE. Identifying everyone with administrative access is a big challenge.
Townsend Security has a multi-factor authentication solution for the IBM i. How are you helping customers deal with identifying administrators?
From the beginning, we realized this would be a problem and we have taken some additional steps, specifically related to PCI DSS 3.2 to help IBM i customers identify administrators. We made it possible to build a list of all users who have administrative access and then require them to use multi-factor authentication when logging on. We have done a lot to help the IBM i security administrator identify highly privileged users and enroll them into a two factor authentication solution, and then periodically monitor/update/audit the list.
What are some of the other multi-factor authentication challenges that IBM i customers face?
Some of them are pretty obvious. If you don’t have a multi-factor authentication solution in place, there is the effort of evaluating and deploying something on the IBM i server. You’ll find users who may already have a multi-factor authentication solution in place for their Windows or Linux environments, but haven’t extended it to their IBM i. Even if they aren’t processing credit card numbers on the IBM i, if it is in the CDE, it still falls within the scope of PCI DSS.
Aside from deploying a solution, there is going to be administrative work involved. For example, managing the new software, developing new procedures, and putting governance around multi-factor authentication. Further, if you adopt a hardware-based solution with key FOBs, you have to have processes in place to distribute and replace them, as well as manage the back-end hardware. It has been really great seeing organizations move to mobile-based authentication solutions based on SMS text messages where there isn’t any hardware of FOBs to manage. Townsend Security’s Alliance Two Factor Authentication went that route.
Let’s get back to PCI DSS. As they have done in the past, they announced the updated requirements, but businesses still have a period of time to get compliant. When does PCI DSS 3.2 actually go into effect?
The PCI SSC always gives merchants and processors time to implement new requirements. The actual deadline to meet compliance is February 1, 2018. However, what we are finding is that most merchants are moving rapidly to adopt the requirements now. When an organization has an upcoming audit or Self Assessment Questionnaire (SAQ) scheduled, they generally will want to meet the compliance requirements for PCI DSS 3.2. It never is a good idea to wait until the last minute to try and deploy new technology in order to meet compliance.
You mentioned earlier that you have a multi-factor authentication solution. Tell me a little bit about it.
Sure. Alliance Two Factor Authentication is a mature, cost-effective solution that delivers PINs to your mobile device (or voice phone), rather than through an expensive key FOB system. IBM i customers can significantly improve the security of their IBM i systems through implementation of proven two factor authentication. Our solution is based on a non-hardware, non-disruptive approach. Additionally, we audit every successful or failed authentication attempt and log it in the security audit journal (QAUDJRN). One thing that IBM i customers might also be interested in, is in some cases, we can even extend their existing multi-factor authentication solution to the IBM i with Alliance Two Factor Authentication. Then they can benefit from the auditing and services that we supply for the IBM i platform. Our goal was to create a solution that was very cost-effective, rapid to deploy, meets compliance regulations, and doesn’t tip over the IT budget.
Download a podcast of my complete conversation here and learn more about what PCI DSS 3.2 means for IBM i administrators, how to identify administrative users, challenges IBM I customers are facing, and how Townsend Security is helping organizations meet PCI DSS 3.2.
8.3 Secure all individual non-console administrative access and all remote access to the cardholder data environment (CDE) using multi-factor authentication.
I recently was able to sit down with Patrick Townsend, Founder & CEO of Townsend Security, and talk with him about PCI DSS 3.2, what it means for IBM i users, and what IBM i users can do to meet the latest version of PCI DSS.Thanks for taking some time to sit down with me, Patrick. Can you recap the new PCI-DSS version 3.2 multi-factor authentication requirement? This new requirement seems to be generating a lot of concern.
Well, I think the biggest change in PCI DSS 3.2 is the requirement for multi-factor authentication for all administrators in the cardholder data environment (CDE). Prior to 3.2, remote users like contractors and third party administrators, had to use multi-factor authentication to login to the network. This update extends the requirement of multi-factor authentication for ALL local, non-console users. We are seeing businesses deploy multi-factor authentication at the following levels:
- Network Level - When you first access the network
- System Level – When you access a server or any system with the CDE
- Application Level – Within your payment application
Yeah, sounds like this is going to be a big challenge. What does this mean for your IBM i customers?
There are definitely some aspects of this PCI-DSS update that will be a bigger challenge on the IBM i compared to Windows or Linux. First, we tend to run more applications on the IBM i. In a Windows or Linux environment you might have one application per server. On the IBM i platform, it is not uncommon to run dozens of applications. What this means is, you have more users who have administrative privileges to authenticate – on average there can be 60 or more who can sometimes be a challenge to identify! When merchants and processors look at their IBM i platforms, they will be surprised at the number of administrators they will discover.
Additionally, the IBM i typically has many network services exposed (FTP, ODBC, Operations Navigator, etc). The challenge of identifying all the entry points is greater for an IBM i customer.
You say it is harder to identify an administrative user, why is that?
On the IBM i platform, there are some really easy and some really difficult administrative users to identify. For example, it is really easy to find users with QSECOFR (similar to a Windows Administrator or Linux Root User) privileges. But it starts to get a little more difficult when you need to identify users, for example, who have all object (*ALLOBJ) authority. These users have almost the equivalent authority of QSECOFR. Finding, identifying, and properly inventorying users as administrators can be a challenge.
Additionally, with a user profile, there is the notion of a group profile. It is possible for a standard user, who may not be an administrator, to have an administrative group profile. To make it even more complex, there are supplemental groups that can also adopt elevated authority. Just pause for a minute and think of the complex nature of user profiles and how people implement them on the IBM i platform. And don’t forget, you may have users on your system who are not highly privileged directly through their user profile, but may be performing administrative tasks related to the CDE. Identifying everyone with administrative access is a big challenge.
Townsend Security has a multi-factor authentication solution for the IBM i. How are you helping customers deal with identifying administrators?
From the beginning, we realized this would be a problem and we have taken some additional steps, specifically related to PCI DSS 3.2 to help IBM i customers identify administrators. We made it possible to build a list of all users who have administrative access and then require them to use multi-factor authentication when logging on. We have done a lot to help the IBM i security administrator identify highly privileged users and enroll them into a two factor authentication solution, and then periodically monitor/update/audit the list.
What are some of the other multi-factor authentication challenges that IBM i customers face?
Some of them are pretty obvious. If you don’t have a multi-factor authentication solution in place, there is the effort of evaluating and deploying something on the IBM i server. You’ll find users who may already have a multi-factor authentication solution in place for their Windows or Linux environments, but haven’t extended it to their IBM i. Even if they aren’t processing credit card numbers on the IBM i, if it is in the CDE, it still falls within the scope of PCI DSS.
Aside from deploying a solution, there is going to be administrative work involved. For example, managing the new software, developing new procedures, and putting governance around multi-factor authentication. Further, if you adopt a hardware-based solution with key FOBs, you have to have processes in place to distribute and replace them, as well as manage the back-end hardware. It has been really great seeing organizations move to mobile-based authentication solutions based on SMS text messages where there isn’t any hardware of FOBs to manage. Townsend Security’s Alliance Two Factor Authentication went that route.
Let’s get back to PCI DSS. As they have done in the past, they announced the updated requirements, but businesses still have a period of time to get compliant. When does PCI DSS 3.2 actually go into effect?
The PCI SSC always gives merchants and processors time to implement new requirements. The actual deadline to meet compliance is February 1, 2018. However, what we are finding is that most merchants are moving rapidly to adopt the requirements now. When an organization has an upcoming audit or Self Assessment Questionnaire (SAQ) scheduled, they generally will want to meet the compliance requirements for PCI DSS 3.2. It never is a good idea to wait until the last minute to try and deploy new technology in order to meet compliance.
You mentioned earlier that you have a multi-factor authentication solution. Tell me a little bit about it.
Sure. Alliance Two Factor Authentication is a mature, cost-effective solution that delivers PINs to your mobile device (or voice phone), rather than through an expensive key FOB system. IBM i customers can significantly improve the security of their IBM i systems through implementation of proven two factor authentication. Our solution is based on a non-hardware, non-disruptive approach. Additionally, we audit every successful or failed authentication attempt and log it in the security audit journal (QAUDJRN). One thing that IBM i customers might also be interested in, is in some cases, we can even extend their existing multi-factor authentication solution to the IBM i with Alliance Two Factor Authentication. Then they can benefit from the auditing and services that we supply for the IBM i platform. Our goal was to create a solution that was very cost-effective, rapid to deploy, meets compliance regulations, and doesn’t tip over the IT budget.
Download a podcast of my complete conversation here and learn more about what PCI DSS 3.2 means for IBM i administrators, how to identify administrative users, challenges IBM I customers are facing, and how Townsend Security is helping organizations meet PCI DSS 3.2.
CloudAce high quality Two-Factor Authentication solutions safeguard your network from malicious attempts and provide extra protection for company’s most sensitive information.
ReplyDeleteTwo-Factor Authentication solutions