Bring Your Own Device And PCI Compliance

Bring your own device or BYOD is all the latest rage.  I believe that the reason for that exuberance is the consumerization of technology.  It is that exuberance through BYOD that has made everyone an “IT expert.”  Just ask any user of a smartphone or tablet and they will baffle you with vendor lingo regarding BYOD.  However, regardless of what these people think, there is a big difference from consumer use and enterprise use, the first of which is security.  In this post I am going to look at the minimum PCI DSS requirements BYOD will have to comply in order for your organization to maintain PCI compliance.

From a PCI perspective, requirement 12.3 is very relevant in the BYOD discussion.

“Develop usage policies for critical technologies (for example, remote-access technologies, wireless technologies, removable electronic media, laptops, tablets, personal data/digital assistants (PDAs), e-mail usage and Internet usage) and define proper use of these technologies. “

Under 12.3, there are eight sub-requirements that require:

• Explicit approval by authorized parties.  Just because you have a smartphone or tablet, does not imply you get an automatic pass to connect, you must be approved for that privilege.  In most organizations, that means you need to provide a business need to have such a privilege granted.  While access to email through a smartphone or tablet is one thing, access to cardholder data should be another and be granted very judiciously, if at all.
• Authentication for use of the technology.  If you think you are using a PIN, think again.  You still have to log onto any PCI in-scope system using a password that meets the PCI DSS requirements.  By the way, two-factor authentication is required to access cardholder data remotely, so BYOD does not get you a pass there either.
• A list of all such devices and personnel with access.  For organizations issuing BYOD, this is not a problem.  For organizations allowing any Apple iOS, Android or Windows device to connect is problematic.  While it can be done, you will need to document who was granted access, for what reason/purpose, and what they are using to obtain that access (i.e., make, model, etc.) even if your organization is not providing the devices.
• Labeling of devices to determine owner, contact information and purpose.   I take issue with identifying purpose of the device as that, in my opinion, could just make someone ever more curious as to what is on the device.  However, identifying the owner, giving their general business address and general voice and facsimile telephone numbers for their location is what I would recommend.
• Acceptable uses of the technology.   Email is one thing, doing something that involves cardholder data is another.  I think if companies think this through, there is probably little, if any, reason for BYOD to be even near the cardholder data environment (CDE).  However, if for some bizarre reason you can come up with a valid reason, then all requirements for remote access of cardholder data apply such as personal firewall, no way to disable the firewall, strong passwords, two-factor authentication, encrypted connection, etc.  And remember that these devices have keyboard loggers, so all data input is recorded so keep that fact in mind when designing your information security requirements for BYOD.
• Acceptable network locations for the technologies.  In the case of BYOD, this is anywhere outside of the organization’s network perimeter.
• List of company-approved products.  For those organizations issuing the BYOD, this is not a problem.  For those of you that allow anyone with anything to connect as long as it runs iOS, Android or Windows 8 RT/Pro, your list is going to say “Any iOS, Android or Windows 8 RT/Pro device.”
• Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity.  With BYOD, this can be problematic as most BYOD do not use traditional remote access connectivity and inactivity can all be in the eye of the beholder, so to speak.  As a result, inactivity timeouts can be difficult, if not impossible, to enforce in some instances.  As a result, you may have to be either creative or use a compensating control to comply with this requirement.

Going through the above, I think most organizations would see BYOD for what it is – a fad.  Do not get me wrong, BYOD has its uses in the corporate environment, but they are fairly limited and likely does not include cardholder data.

However, if you have come up with a business justification for processing, storing or transmitting cardholder data using BYOD, there are number of other requirements you are going to have to address.  I know there are other potential requirements that could be involved, but these are the most well known that will need to be complied with under the PCI DSS.

• Requirement 1.4 – Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization’s network.   While this can be accomplished by a number of security vendors, it is the enterprise management of those solutions that is currently lacking and the ability to globally enforce policies.
• Requirement 3.4 – Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs).  Most cell phones and tablets do not support device encryption.  As a result, how will you protect any cardholder information stored on the device?  Remember that these devices have keyboard loggers, so any cardholder data input on the device is collected and stored by the device whether you like it or not.  The bottom line is that you will have to restrict BYOD to only those devices that can support whole device encryption.
• Requirement 4.1 – Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.  You would not think that this would be a significant problem, but it can turn out to be very significant and I will speak about this later on.
• Requirement 8.3 – Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.  This capability is available, but if you are using any of the solutions that run on the BYOD, your users will likely have issues trying to connect and get their token value from that device.
• Requirement 8.5.10 – Require a minimum password length of at least seven characters.  This is likely a deal breaker for users.  Most like their PIN or swipe and will not want to give them up for a seven character, strong password.  In addition, some security solutions may create a situation where the phone cannot be answered without unlocking the device and, a seven character password may cause calls to be missed.
• Requirement 8.5.11 – Use passwords containing both numeric and alphabetic characters.  This can be problematic when some virtual keyboards require flipping between three or more screens to get to certain special characters.  With phones with physical keyboards, there may be limitations to the number of special characters available that could create problems with the password uniqueness requirement in 8.5.12.
• Requirement 8.5.13 – Limit repeated access attempts by locking out the user ID after not more than six attempts.  Some security systems may not be able to enforce this without wiping the device.
• Requirement 8.5.14 – Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.  I am not aware of a security solution currently available that can enforce this on a smartphone or tablet.  You will have to meet this with a compensating control.
• Requirement 8.5.15 – If a session has been idle for more than 15 minutes; require the user to re-authenticate to re-activate the terminal or session.  As with 8.5.14, I am not aware of a security solution that can enforce this on a smartphone or tablet.  You will have to meet this with a compensating control.
• Requirement 10.2 – Implement automated audit trails for all system components to reconstruct events.  This is not an issue with Android and may be an issue with Windows 8 RT, but is definitely an issue with Apple iOS.  There is no utility I am aware, outside of forensic utilities, which can meet this requirement in an Apple iOS environment.  In addition, I am not certain how you get this log data back for any sort of analysis without chewing up a tremendous amount of data bandwidth or device memory.  At the end of the day, this will also likely be satisfied by a compensating control, if you can actually come up with enough controls that go above and beyond the PCI requirements.
• Requirement 10.3 – Record audit trail entries for all system components for each event.  If meeting requirement 10.2 is a gymnastic event, then there is the configuration of the log data to ensure that all of the necessary log information is collected.  I am sure that under Android and Windows there is probably some way to ensure that the necessary log data is required.  But with Apple, iOS, Apple will have to be able to provide this capability.  And knowing how stubborn Apple can be about having their hand forced in these matters, getting access to configuration of log data let alone log data will likely be a battle.  Again this will also likely be satisfied by a compensating control, if you can actually come up with enough controls that go above and beyond the PCI requirements.
• Requirement 10.4 – Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.  For smartphones, they get their time synchronization from the carrier.  However, that time does not likely correlate to the time used by enterprise systems.  It will be close, but not necessarily the same thus complicating any forensic examination if one is required.  This can obviously dealt with in a compensating control.
• Requirement 10.5 – Secure audit trails so they cannot be altered.  Given that users have administrator access on their BYOD; this could be a problem that cannot be easily solved.  Yes, there are security solutions available that can lock down a device, but they can also lock them down so far that users can begin to wonder what the point of having the device is.  As a result, you will find you have a very fine line to tread in this area.

In the end, you start to understand why BYOD is a difficult thing to justify when you need to comply with all of the aforementioned PCI requirements.  But there are a few other considerations that you will still need to address.

The first situation that should concern any organization considering BYOD is the loss of that BYOD.  It is virtually guaranteed that BYOD will result in lost devices and you will need policies, standards and procedures to address that eventuality.  The way most organizations address this issue is providing a remote device wipe capability that can be invoked whenever a device is reported lost.  Not that such capability ensures that every lost device is wiped, but it is better than nothing, but not by much.  This is usually backed up by the bad password entry policy that wipes the device after six incorrectly entered passwords.  So even if the remote wipe does not destroy the data, the bad logon attempts will.

BYOD brings up an information ownership issue as, according to the latest statistics, 70% of all BYOD are owned by the employee, not the organization.  As a result, you are allowing the organization’s information to be processed or stored on a device not owned or necessarily even controlled by the organization.  While you can have an employee sign an agreement regarding the organization’s ownership of the information and the employee’s responsibilities for protecting that information, the issue of enforcement of such an agreement can be very problematic depending on platforms and other technology issues.  You can have a remote wipe capability, but that brings up the potential legal issue of can you also wipe an employee’s personal information such as contacts, music and pictures as well?  Just remember the old saying, “Possession is nine tenths of the law.”  When you finally get through court proceedings, does it really matter if you won when the data has already likely been disseminated?

Then there is the question about whether your applications actually capable of dealing with BYOD?  Most internally facing applications that employees desire access are not engineered for secure, remote access from BYOD.  As a result, a lot of organizations are turning to VPN technology to solve the remote access issue.  However, organizations using VPN are finding out that, while VPN clients are free for download to the BYOD, licensing for the BYOD VPN client is over and above the licensing the organization has already purchased for notebooks.  In addition, depending on the device, running the VPN client can make devices run very slow to the point of being worthless when connected.

When VPN is not a solution a lot of organizations are using remote desktop (RDP), Citrix virtual desktop or similar remote control environments to provide secure access to internal applications.  Having worked with a few of these in a smartphone and tablet environment, I can tell you their use is haphazard at best due primarily to screen size and lack of a mouse and a real keyboard.  In addition, we also find that some of these secure remote desktop solutions are not using secure communication methods.

In addition to VPN and remote control, a lot of organizations are implementing HTTPS for secure connectivity to their applications.  However, this creates all sorts of new security issues related to authentication and protecting the applications which are typically not engineered to be externally facing.  We are finding that in the rush to enable applications for HTTPS, there are numerous security vulnerabilities that are being introduced.  We also see vulnerabilities as well with applications developed specifically for mobile devices.  In the haste to get BYOD up and running, the security vulnerabilities are not corrected before the applications are put into use (a violation of PCI DSS requirement 6.6) which puts the applications and, potentially, the internal networks at significant risk of compromise.

And finally, data input from smartphone and tablets can be highly erroneous not just because of human typing errors but also because of auto-correction systems that are implemented on these devices.  Anyone considering significant data entry through BYOD is just asking for trouble as this erroneous data input could result in legal issues later on due to mis-spellings and mistakes in addresses and other information.

Most executives do not understand the security and privacy issues of BYOD because they have not encountered them and are not aware of them even when time is taken to educate them.  Unfortunately it usually takes an executive losing their BYOD to help management appreciate the issues with BYOD and to slow down the drive to integrate BYOD until their concerns regarding security and privacy are addressed.

As you can see, using BYOD is not as simple a process as your end users might think.  This is even truer when that BYOD will be part of your cardholder data environment (CDE).  There are a number of innovative solutions for BYOD that are secure, but those solutions are expensive and make the BYOD only a display device.  However, if you want to be able to sleep at night, I would highly recommend looking at those purpose built solutions.

Advertisement