Principal Security Consultant
Jeff Hall is a principal consultant in Optiv’s advisory services practice on the Payment Card Industry (PCI) compliance team. Jeff’s role is to provide post-sales support and consulting to Optiv’s clients as well as providing support and mentoring to other Optiv team members. He has more than 30 years of experience in project management, information security, information security strategic planning, software evaluation, selection and implementation, voice and data networking, systems analysis and design, information system audit, systems programming, and data center operations.
Why the “Internet of Things” Matters For PCI
The media and blogosphere have been all abuzz as of late regarding the Internet of Things (IoT). Most discussions revolve around how close we are to the IoT. But as my friend Anton Chuvakin points out, and as most IT personnel know, IoT is already here and has been for quite a while.
For all of you trying to be PCI compliant, here are some examples of IoT that could potentially impact your PCI compliance. This is not a complete list but some of the favorites I’ve encountered.
It’s a common misconception that card terminals are “dumb.” At the first PCI Community Meeting back in 2008, that idea started floating around due to a poor choice of words by one of the presenters. Up until that point, only merchants had assumed that the intelligence of their terminals was contained anywhere other than the terminal. But many people came out of the meeting believing that card terminals were not intelligent devices.
Unfortunately, terminals are far from dumb. Terminals are typically as sophisticated as smartphones and run embedded versions of Windows and Linux. They have software development kits (SDK) and application programming interfaces (API). I think most everyone would agree that these are far from “dumb” devices, yet most merchants do little to protect them.
There are two types of threats to terminals:
Physical Tampering - I’ve seen clients end up with USB drives inserted into their terminals to capture sensitive authentication data (SAD) at the terminal. The terminals were not locked down and were easily swapped out by people working as overnight cleaning or stocking crews. It is important that terminals be secured, that tamperproof tape be placed on seams and that management inspect the terminals at least daily to make sure they remain secure.
Logical Tampering – This type of tampering is much harder for the merchant to detect. In these instances, the software in the terminal has been compromised to capture SAD. We first saw this in 2012 with the Barnes & Noble breach where someone shipped terminals with tampered software to stores posing as the terminal supplier. BlackPOS and similar memory scraping attacks are also a form of logical tampering, taking advantage of data flows between terminals and POS registers.
Like card terminals, smartphones and tablets are mobile computers but are not treated as such. Mobile devices typically get left behind when it comes to patches and OS upgrades once the next model is released because vendors and cellular carriers do not want to waste time supporting older devices. Mobile devices typically do not have the firewalls, antivirus, anti-malware or similar security software installed as their PC brethren - though they are available. And despite guarantees from App Stores, malware still gets published and distributed from the major marketplaces.
This is why the Council has stated that mobile devices should never be used for the processing of payments unless approved by the merchant’s processor or acquiring bank. But that is the rub. Square, PayPal, Intuit and others get around the Council’s advice by not only creating the mobile payment application and the swipe device, but also by serving as the transaction processor thereby automatically approving the use of their own application.
Voice over IP (VoIP)
Something that business has adopted in a fury is VoIP. It allows for all sorts of cost savings by leveraging organizations’ existing data networks and avoiding traditional telephone services.
However VoIP carries with it a number of risks that are usually dismissed or never discussed when being implemented. The most insidious risk is that VoIP protocols are primarily stateless. That means your firewall cannot really protect you from an attack because once a call is set up, the conversation is handled over User Datagram Protocol (UDP), which is not a stateful protocol. We see that the VoIP network is not always isolated securely away from other data traffic. For a lot of organizations, their entire networks are at risk because streaming UDP traffic can be used to penetrate their networks.
Since firewalls have limited use in protecting a network, the worst thing an organization can do is connect their telephone system(s) via VoIP protocols to the telephone service provider because then you have little to no protection should the service provider be compromised. The sad thing about this is that most IT and even information security people have no idea that VoIP has this risk.
But it is not just IT people that treat VoIP call managers like a private branch exchange (PBX) of old. VoIP vendors also tend to treat their solutions like a PBX. Unlike the typical PBX that only connected to a data network for accessing the PBX management capability via telnet, today’s VoIP solutions do not function without the data network.
Most organizations also expect their VoIP solutions, like their PBX brethren, to get 10 to 15 years out of them before replacement. As a result, it is not unusual to find organizations with VoIP call managers running old, unsupported versions of Windows, CentOS or Red Hat.
To add insult to injury, most VoIP systems are not viewed as servers. They are still viewed like the PBX it replaced. As a result, antivirus, host intrusion detection, critical file monitoring, centralized logging and other security measures that any other server would have are typically not installed because of performance concerns or the vendor’s claims that such measures are not necessary or will void support. To quote a vendor from a few years back, “It’s just a phone system. Why would anyone want to hack it?” It is that opinion that gets people in trouble.
Inventory & Checkout Scanner Guns
Devices from Symbol (now Motorola), Datalogic and the like run on operating systems such as Windows CE, Windows Mobile, Windows Embedded and Linux Embedded. While these are stripped down versions of their desktop and server brethren, they are still images of those operating systems and are susceptible to attack. In addition, these devices operate wirelessly via Wi-Fi and Bluetooth, which is a potential entry point into your network and point-of-sale (POS) environment.
I have also encountered scanners scattered around stores for customers to confirm pricing of products. These scanners’ enclosures can mask the fact that these devices are just PDAs inside with bar code scanner and application software. It is not unusual for those PDAs to end up missing unless they are secured both physically and logically.
During one customer’s security review, we found that these PDAs were physically secured but not logically secured. We obtained the wireless network’s pre-shared key to get on the organization’s secure internal wireless. Once on that network, we had full access to part of the cardholder data environment.
These are all the rage in retail, particularly the grocery segment. They are essentially PC-based POS stations with scanner, scale, ATM functionality, etc. For customers, self-checkouts are viewed as a godsend. However, they also have an embedded operating system that is at risk and needs maintenance and patching. Yet time and time again, because the self-checkout is a different device, sometimes running a slightly different version of POS software, they tend to be forgotten or are not patched or updated as often because of the vendor.
HVAC, Elevators and Building Management
Other than facility managers and building maintenance staff, most people are oblivious to how much technology is relied upon to control heating, cooling and other building management activities. Integrated systems control heating, ventilation, air conditioning, elevators and lighting.
The problem? These systems can be using the same data networks your cardholder data environment (CDE) uses. Granted there are usually firewalls and ACLs that isolate them from the CDE, but not always. I have encountered data networks that are completely flat where everything is in scope including these building systems. These systems are likely not updated or patched very often nor are they replaced very often. As a result, they are ripe for being compromised.
Another issue with these systems is that they are typically monitored by outside, third parties.
If the third party is compromised, it is likely that your organization will be compromised. And since these systems are attached to your network, there is greater likelihood of an attack’s success and going undetected.
What to Do?
Your first step should be figuring out what embedded systems exist in your organization or connect to your organization’s network. You then need to identify the owners of those embedded systems.
Once identified, these owners need to be asked the following questions.
- What are the risks to these devices?
- How long have these devices been in service?
- When was the last update or patch you got for these devices?
- How are these devices connected to the network and where are they connected?
- Do these devices have access to the Internet?
- How are these devices managed and monitored?
- Do third parties have access to these devices?
The answers to these basic questions will likely result in a lot of other questions and concerns. However, without starting the conversation, you will have no idea as to the risks you may face from these often forgotten systems.