PCI DSS Guidance for Mobile Security

PCI DSS Guidance for Mobile Security

May 07, 2013 2:00 pm

(Save to cal)

Online

Online Tech and guest Adam Goslin, COO, High Bit Security  review the challenges and details of the recent PCI mobile guidelines as they relate to PCI DSS (Payment Card Industry Data Security Standards) and PA DSS (Payment Application Data Security Standards) compliance.

Title: PCI DSS Guidance for Mobile Security
Description: In February, 2013, the PCI Security Standards Council released a document covering Mobile Payment Acceptance Security Guidelines.  High Bit Security COO, Adam Goslin, will review the highlights of the recent guidelines, detailing some of the clarity and pitfalls contained in the recent mobile guidance from the PCI SSC, including impacts to PCI-DSS and PA-DSS compliance.

 

 

 

View Slides


April Sage: Hi, everyone. Thanks for joining us for another Tuesday @ 2 webinar. This is April Sage at Online Tech.

We’re very happy to bring back Adam Goslin. Adam Goslin is Founder and Chief Operating Officer of High Bit Security, a company dedicated to security services. Adam also has first-hand experience guiding enterprises through the process of achieving PCI DSS Level 1 Compliance. We’re very lucky to have Adam bringing those two areas of expertise and to give us an idea of the unique challenges that maintaining PCI compliance meets in the mobile world. With no further ado, Adam, welcome back.

Adam Goslin: Thank you very much, April. First I’d like to thank Online Tech for having High Bit Security come along to share thoughts on some of the recent guidance provided by the PCI Council on the mobile payment application space.

As a general comment welcome to the wild, wild west of security - the mobile platform. The mobile arena is one that certainly has been exploding over the last couple of years and is sure to provide non-stop challenges to those organizations that are interested in making available mobile payment applications to support or supplement their existing communication profiles with their customers. With that said, let’s move right into it.

In February of this year, the PCI Council put out a Mobile Payment Acceptance Security Guidelines document. I’ve put the URL to the document in this presentation. One important note for the participants is that they haven’t exactly made this document easy to find. If you go to the documents portal on the website, it’s not immediately accessible. You have to end up finding it through a direct link. If you’re looking for the actual document, you’re going to want to take note of that URL.

I know that Online Tech will post this presentation to the site and certainly our contact information. If you need to get a copy of the document, you can contact us as well. The presentation should be up and available online within a couple of days so you should be able to get it.

One important note about this particular document and that is the Council is not accepting mobile applications for PA-DSS compliance. PA-DSS compliance is the payment application data security standard for those organizations that offer payment applications for sale to organizations who process card data. Those chunks of software have to go through PA-DSS compliance. The Council isn’t accepting any mobile platforms at present.

This guide is intended for merchants that are trying to implement a secure mobile payment acceptance solution. Of course, given their general stance, which is that they are not about to try to certify any of these mobile applications, effectively it puts the onus on the manufacturer-creator of the mobile application to ensure its security.

The inference, if you will, also means that the risk for making that mobile payment solution available to consumers, the risk falls squarely on the organization that distributes it. Certainly if you are an independent organization that is looking to provide a mobile application to your customers, it’s very important to keep in mind that stance. Offering that as one of the tools in the tool box basically puts your organization in the firing line of making sure that it’s secure.

They have given these guidelines as, I’ll call it an interim step. This interim step is one that will provide some good guidance to organizations that want to go down this path. The one other important piece of this is that, for instance, everyone’s seen the proliferation of the square devices, as an example. There’s several of those out there. Those devices do not encrypt the card data on swipe. Basically anyone that’s using those square devices is also taking on the liability for any interception of the card data while using that platform.

I’ve spoken with several qualified security assessors through VISA. They’ve indicated the input that they’ve received from their interaction with the Council is that mobile applications are not to be included in the scope.

For organizations that have, let’s call it, either their own or a hosting provider-based solution that they do mobile payment processing on and go through a PCI DSS Level 1 review at a qualified security assessor. Even under those circumstances, the organizations are including everything except for that mobile application. The infrastructure, the firewalls, the environment that the solution sits on, those are all included. WebFacing application and any web services that sit on a hosted solution those are included, but the mobile application is not. Just walk in eyes wide open as you dive head first into the mobile payment space, shall we say.


Adam: The mobile environment holds a number of challenges. The consumer devices, if you think about your own iPhone or Android device that you have, those devices aren’t held to the same security standard that a locked-down, tightened-up PCI compliance environment would have. Those mobile device applications have the capability … other applications that are on those devices have the capability to access any stored or in-transit card data, which is one of the biggest challenges, especially when you’re talking about the Android platform. The general security of the applications that exist on those devices has a wide range of variability. That’s one of the biggest challenges when you start talking about mobile payment applications.

There are a whole slew of manufacturers with devices, developers of operating systems, application designers, network carriers and the use of the various protocols to connect to all the various entities holds a lot of variability.

The mobile application developers are typically in an organization that folks developing the mobile app are typically getting it from the folks that are doing and know how to do well the web-based payment application solutions. That poses a different challenge in that those mobile application developers usually don’t have as high a level of awareness surrounding security and secure coding capabilities so that presents its own challenges.

When you start talking about the reality of the mobile environment and mobile security, 2012 saw a 163% increase in mobile malware with 95% of that being targeted to the Android platform. Let’s just take Android and iPhone as the two primary examples. In the Android arena, you’ve got the capability to load applications from uncontrolled application source. The variability of general security practices, secured coding techniques for those applications is much higher. With that variability comes opportunity for the cyber thieves, hackers of the world to go ahead and target the Android platform specifically.

The estimates, as of the end of 2012, were at that time that one-third of all Android devices were presently infected with some form of mobile malware. You take an environment where you’re trying to stand up a payment application with sensitive data, that holds potentially significant ramifications should something go wrong, and start dropping that onto a platform with this number of challenges and this level of infection, if you will, on the devices themselves. It poses a substantial challenge for the PCI Council to lay out guidelines for what they expect so that organizations can maintain their PCI compliance. This is the reason why the Council has effectively deferred their interest in qualifying the mobile platforms as a payment application platform for use that has the capability to be certified.

To continue talking about some of the mobile challenges, the bottom line is the secure card data is being processed on the same device that the consumer applications are running on. You’ve got your typical device. Sure, it may have a mobile application installed and loaded onto it, but it also has a whole slew of potentially other mobile software that may or may not be secure, probably not, running on the same device. The challenges around segregating the consumer and secure part of movement on the device itself, we talked about, malware on those devices.

The additional challenges, how do you do fraud monitoring on this mobile platform short of using the choke point of the receiving server for the transactions? That would be one area, but how do you monitor fraud from the mobile device itself? Those things all produce significant challenges for those that choose to enter the mobile space.


One of the key points that they had in the guidance document was they were encouraging mobile application developers to basically stay in touch with what’s going on in the mobile arena and the mobile platform, new developments, new security solutions, new threats. There’s a very strong urge to keep your finger on the pulse of what’s going on in that mobile space, even for organizations that are under what’s called a non-mobile standard PCI compliance. They, too, are required to keep their finger on the pulse of what’s going on in the security space, making sure they’re aware of what the various opportunities are for improving their security posture. The same guidance holds true in this mobile space. It’s quite frankly a lot more important because things are changing so rapidly in this mobile sector.


Adam: As far as documentation scenarios that the PCI Guidance covers, it covers a couple of different scenarios. One where the solution provider is responsible for the mobile app and all of the backend processing. In addition, the solution provider is also the device owner and provides those devices to a merchant. This guidance document really covers that where you have basically picked up both the software and the device from some type of a solution provider for use in your organization.


The second scenario, it’s where the software comes from one of those players and the device is being handled by the merchant itself. One of the things that they specifically called out, if you can imagine, given all of the areas, disclaimers and risks that were associated in the document, they did not cover BringYour Own Device or BYOD. It’s not included for the reason that it doesn’t afford the merchant the appropriate level of control required to ensure the security of that platform. One important note is that this includes the vast majority of mobile platforms and solutions. The read to take from this is that the risk is on the company themselves to ensure the security of this device and platform.


Adam: When we talk about the security risks in the mobile platform; and this is one thing that certainly the providers or writers of the software need to make sure that they understand; that is all the risk that are on a server or workstation-based solution, whether it’s a physically-hosted server, one at the corporate headquarters, a cloud server, or a local workstation solution; any risk that could be on those platforms may exist on a mobile platform as well.


The challenge is that mobile devices end up having more. They’ve got more communication protocols. You think about the cellular network Bluetooth capabilities, infrared, NFC. These are all additional communication protocols to the devices themselves. They also have removable media in the SIM and SD cards, embedded sensors within the devices where you’ve got tilt motion sensors, thermal sensors, pressure sensors, light sensors built into these devices. In fact, one of the interesting security stories that had come out was a hack that have been performed on mobile devices leveraging the accelerometers within the devices themselves. They’ve also got the capability for biometric readers. Bottom line is mobile, as the name indicates, it’s a portable platform. There comes along with it serious risk of that device being potentially altered and then replaced.

Going back to the scenarios that they based the document on where it was really more not meant for the broad-based consumers where you can go download from an app store, but really for merchants to be able to use on dedicated devices if with those devices were to be taken, altered, replaced. Then the risk there is that the merchant may not be aware that the device have had such alteration performed to it.


April: Hey, Adam?

Adam: Yes?

April: Can you give us an example of a biometric reader or tell us a little bit about what that does?

Adam: Yeah. Biometric readers; whether it’s facial recognition capabilities, retinal recognition, finger swiping devices; basically biometric elements for typical use for authentication included into the devices. The facial recognition probably being, at least on the mobile platform, being the most prevalent of those.

One of the interesting things about the document, April, is that it’s forward-looking, if you will. They’ve included some of their thoughts on where they see the potential for mobile devices to head. They’ve interspersed both real world today scenarios, risks and guidance, but also left the door open to things coming down the line. Certainly one of the bigger challenges, especially on the mobile platform, is the capability for secure authentication. They’re envisioning that biometric capabilities of mobile devices to be on the rise, and they called that out in the document.

April: That seems like this is an environment where you definitely need to stay ahead of the curve. Thanks.

We had one more quick question. Is the Bring Your Own Device synonymous with a Category 3 device?

Adam: Define what you mean. I’m sorry.

April: Maybe the question asker can elaborate a little bit more about Category 3 or whether you’re referring to Level 3. Let’s wait for some more details on that one, Adam, and we’ll stop interrupting you. Keep going.

Adam: No worries. I’m easy going.


Adam: Talking about security of the payment transaction. Certainly one of the challenges is the risk of interception of the payment data on entry to the device itself. One of the guidance elements in the document is that no PIN entry devices, no PIN directly to the device. They don’t want string-based usage for entering in the PIN for a debit transaction, as an example. If that is a requirement, they’re suggesting to do that through a PTS-approved PIN entry device or an encrypting PIN pad that would attach to the device itself.

They also give fair warning for shoulder surfing. If you’re putting the payment information into the device, make sure there’s nobody watching or observing your entry of the information.


Then if you’re using some type of an external device, such as a secure card reader, then making sure that it’s used, an intention has been approved by the solution provider in terms of its use. While we’re on the topic of external devices and secure card readers, as of the last check that I did of the list of devices that were out there for the mobile platform. At least we’ll call it mobile card readers. The ones that were on the list primarily operated … if you could imagine one of those gel wraps for an iPhone or an Android device, it was similar to one of those gel wraps that go around the entire phone. Then the encrypted card reader would sit up and on top of that.

I don't know if anybody’s recently been to their local Apple store where they’ve got that wrapper that goes around the … I think primarily they’re using mini iPads. It’s basically bullet encrypted card swiper that sits up on top of the device. The wrapper envelops the entire device. At last check there were no encrypted card readers that were small enough to just be similar to a Square device where you plug it in with the top port on the phone. Just be cautious when you’re looking at external swipe devices for your mobile platform. Like I said, at last check they didn’t have any small devices that would just plug into the top port.


The last of the interception on entry arena is enabling all of the appropriate, proper security functions from the mobile device, making sure that all your security updates, patches are all in place, and that you’re using that device in accordance with any solution provider documentation. That scenario where you have a solution provider basically giving you both the software and the devices themselves, certainly in terms of mitigating risk to you, is making sure that you’re leveraging those devices in accordance with their instructions. Just about the only thing that’s going to save your organization from a myriad of pain because if you’re not using it in accordance with their guidelines, that could be where you end up getting yourself into trouble.

We talked about prevention of a compromise while information is processed or stored. Certainly one of their guidelines is that only having trusted individuals have access to that, even the application and the associated environment, i.e. the mobile device itself. The security of that mobile device, we were talking earlier about the potential for that mobile device to be in some way, shape or form altered offline and then placed back into service. Certainly the security of that physical mobile device is important under the circumstances because you want to make sure that nobody has had the capability to change that, if you will.


Monitoring the physical security of that mobile device. If you have a storage location where you placed the mobile devices themselves, then you should treat the security of that storage location similar to the way that you would treat the security of a server that has card data on it. Again, you want to make sure that you’re monitoring the security of those physical devices, cameras and blocking access to obtaining the pieces of hardware. Those are all kind of become important elements of that physical security monster.


Then wherever the data passes through a network that’s under the merchant’s control, making sure that it’s been implemented as a secured network. Certainly, depending on the transmission method for the style of communication, that interaction with the payment application, making sure that you’ve taken steps to do so in a secure manner.


Adam: Next up is preventing the interception on transmission. Protecting the wireless transmissions per PCI DSS requirements. If you’re doing this on a wireless platform, things like making sure that you’re changing the wireless default encryption keys, passwords, SNMP community strings on the wireless device itself. Facilitating best practices through strong encryption and that account data is never stored on a server that is directly connected to the Internet.


In terms of the storage of that information, the recommendation is making a direct online submission of the hard data from the mobile platform. Then effectively, if you have a web-based API or web service that’s sitting on the web application. Similar to standard handling from a PCI perspective, you bring the data in through that, then bring it, either it’s passed directly back out to payment provider platform, or preferably directly through the payment provider platform. If you have to catch the data on that path, your best bet, don’t write to disc. Basically that’s the transaction and keep it moving along to the payment process. If you have to accept it within your environment, then just making sure that it gets stored to an internal server and not to a server that’s connected directly to the Internet.


In terms of the security of the mobile device itself, where the merchant either owns or is responsible for that mobile device, it’s their responsibility to take steps to establish and maintain the security of that device. For instance, preventing any unauthorized physical device access. We talked at some length about storage of these devices, where you store them, making sure that you treat that source location similar to an area where you would have stored credit card data. Prevent any unauthorized physical access directly to those devices.


In terms of preventing unauthorized logical access, making sure that you’ve got the logical access restricted to mobile authorized personnel for usage of the mobile device itself. Making sure that you’re always using logical device access protection methods, so whether it’s biometric, complex password, multi-factor authentication. Include that as part of your payment solution in addition to any of the built-in methods provided by the device or operating system manufacturer.


Bottom line, you want to make sure that whoever is using that particular software platform, that they’re truly authorized to do so. While granted most of these devices that we’re talking about have some form of either key pass codes, style entry to be able to get on to the devices, some of them will use kind of like a pattern matching style of access where you emulate the pattern that’s on the authentication screen. That’s great, but you want to layer in your own access to the physical application that’s on the device itself so that you’ve got some measure of assurance that if somebody has somehow known, seen, received the capability you’d get on the device, then they don’t just have direct access to the payment application itself.


If the vendor-provided authentication measures are present, then absolutely make sure that the device itself has some type of a password, PIN, pattern recognition embedded onto it. Certainly if all these devices have that capability, we strongly recommend that you employ both that level of physical access as well as logical access to the payment application itself.


Given these are mobile devices, they're going to be out, moving around, you want to make sure that you’re using some type of full disk encryption on that mobile device, if you have the capability to do so. That way, in the, we’ll call it a likely event, that one of your mobile devices end up coming up missing, then it’s not an unencrypted device that someone now got in their possession.


Adam: Next up is talking about protecting the mobile device from malware. Install and regularly update your latest and greatest anti-malware software. This is no different than the organizations that are under standard PCI compliance, rules and regs in terms of keeping your software up to date and patched. You want to make sure you do the same thing with your mobile anti-malware solution that you’ve got on the device itself.


Making sure that you’ve deployed security software products on these mobile devices that would ward off as many threats as possible. Specifically in the malware arena and on the mobile platform, strongly recommend that keep a good eye on what’s out there, what’s the latest and greatest, who’s got what software, what types of things are they catching, who are the new entrants to the marketplace? This is going to be an arena with a lot of turnover and change over time, probably developing at a rate that is far more significant than the rate that we’ve seen in, for instance, than traditional anti-malware software offerings.


Making sure that the merchant isn’t circumventing security measures on that mobile device. In other words, enabling any USB debugging or rooting the mobile device. Those would be things that you don’t want to see happen on your devices to open up any additional security risk.

Make sure that you’re only installing any trusted software necessary for business operations. Certainly the more software, the more applications that are on that mobile device, the more capability that you have for making sure that the market affiliate you have open up security threats and holes to the device itself and thereby the environment that is doing the payment processing on the device itself.


Talking about software on the mobile devices, certainly with any software that’s on those mobile devices, and really it goes beyond the mobile device itself. You want to make sure that the solution providers that either have software that needs to sit on your mobile device that you’re leveraging, and even any companies that are providing elements of the solution that supports the mobile platform. Making sure that both the mobile application that they are employing and they're either corporately hosted, hosting company hosted or file hosted solutions have been through some form of penetration testing by a third party security company. Because you want to make sure, it’s your responsibility to make sure, about the security of that mobile application and all of its supporting infrastructure. You certainly want to make sure that those organizations have taken their best efforts to ensure the security of those platforms.


You want to ask questions like who did the testing? What are the results of the testing? Did all of the issues that came up through that penetration testing engagement, were they all fixed, closed up and remediated? When was it last performed? Those are all good questions. For a company that has been down the path of performing penetration testing on their environment, those are questions that they should readily and easily be able to answer.


The merchant should also require the following activities of the solution provider. Making sure that solution provider is providing regular updates to the payment application. Having that the merchant … indicating to that merchant when updates are available and they're safely installed. Certainly the distribution of that update should be done in a secure manner.


The solution provider should have restrictions on that payment app, so it only is able to perform on a device that is configured appropriately, i.e. running the appropriate firmware operating system on the device itself. The solution provider should also supply documentation, the details, how do you go about updating these devices.


They should be in communication with that merchant, make them aware of any newly discovered vulnerabilities. I mean you want a partner, particularly in this space, with the speed of which things are on the move. You want a solution provider that is communicating with you openly and making you aware of various threats to card data, to your customers, to your environment. Make sure that you’ve got a good, open relationship with that solution provider so that they can go ahead and advise you when they found something that’s newly released or coming, as well as the fact that they're actually working on a fix for that particular issue that they’ve discovered.


Adam: We’ve talked about the mobile device and the state of security of that mobile device. You certainly want to employ some type of mobile scanning capability so that you can figure out are there unnecessary application privileges, any applications are storing, if their authentication capability’s in appropriately, whether those applications that have been installed on the device have any type of inappropriate access to that payment application itself, as well as the capability to detect man-in-the-middle attacks. In other words, attacks that may be resident on the device itself and catching data while it’s in transit on the device. Those are all things that you’re going to be wanting to look for in some type of a mobile scan capability on the device itself.

You also want to have some type of an indication of secure state. Maybe it is a certain symbol or it’s the word “secure” that’s all colored green, or whatever the employment of that indication is. Part of that solution should be able to identify if that device is in a secure state. If not, some method for either the lack of that indicator, or preferably an indicator that says it’s not in a secure state.


We talked about jail breaking or rooting the device that the payment application resides on. You certainly don’t want to be in that situation because effectively that bypasses inherent or built-in security that’s been built-in to the device itself by the manufacturers. Rooting or jail breaking it just makes it that much easier for things to go awry. The recommendation is to use new from the factory devices so that you can avoid devices where you’re not sure where’s this device been, what has it done, what does it have on it, how do I clear it, things on those lines. If you’re getting a brand new device straight from the manufacturer, then you need that capability to avoid the necessity of answering those questions or determining the security state of the device itself.


Any device functions that aren’t necessary, disable them on the device. You don’t need the phone capability. You don’t need the ability to take pictures. You don’t need Bluetooth. Turn all of those things off on the device itself. Anything you don’t need, shut it down. Basically it will limit the number of attack factors that could be used on that mobile device, the fewer communication channels that you have opened.


Having a program in place for identifying or detecting any loss or theft of the devices themselves. Recording the serial number, model number, operating system, firmware, payment acceptance version that resides on each of the devices. Logging their distribution, logging where those devices are that have been distributed to, who has ownership of that, some type of marketing on those devices with a unique indicator, something that you control. In other words, that’s a U/V pen or an embedded RFI tag on the devices themselves.


Making sure you have the capability to detect in a timely manner if the device have been lost or sold, as well as the capability to disable or securely wipe the device remotely. Those are all capabilities you’re going to want to have on your mobile platform that you use.



Secure disposal of all devices. No different than a standard PCI environment. Making sure that you’re disposing of those mobile devices in a secure manner, whether it is some type of an advanced disc wiping capability, physical destruction of the device, your call. Make sure that you have some mechanism in place for securely disposing of the old devices.

When we talk about the payment solution itself, the implementation of a secure solution, you want to make sure that you’ve done everything in your power to make that solution as secure as possible. Certainly the aspects of secure coding, being implemented into the payment application development, as well as just your system development life cycle, your change control capabilities, how you’re rolling out new patches. How did you make sure that those were secure as you rolled them out? Have you performed penetration testing on the mobile application platform itself? Any of the supporting capability for that mobile platform, those are all things that are going to play into the implementation of the secure solution.

You want to have policies and procedures in place for secure use, as well as training. Training the users on what they need to do, how they need to do, especially around usage of and security of the device itself is going to be important. You’d be surprised how many organizations will not have appropriately trained the users, and then they’ll have users that will be, unbeknownst to the organization, picking up the swipe devices to do entry of the card data into the device and basically opening up the organization to additional risk. Because the unencrypted card data is chatted from the insecure swipe device through a memory to the payment application itself. Training of those users is important.


A preference for online transactions. In other words, when you set up this mobile payment platform, make sure that it is performing those transactions live. There’s no capability for the device to store up transactions locally and then send them along later when it has a connection. If you don’t have a connection, you can’t use it basically is the recommendation there.


We talked about unauthorized use. You need to give the merchant the ability to manage access, change permission, revoke access to the software platform itself. Certainly keeping a good eye on the system logs and reports that come from the system. Those are things that you want to be able to do so you can sufficiently detect any abnormal activity that may be occurring on the mobile device.


Make sure that your logging is actually enabled. There may be systems capable of logging but the logging isn’t turned on. Make sure that your logging is enabled. Make sure you’re catching things like unauthorized access attempts, that’s people trying to escalate their privileges, any unauthorized updates to the device. These are all things that you’re going to want to know in terms of managing and maintaining the mobile platform, if you will.

Ensuring that the customers can validate that merchant in transaction. The cardholders should be able to confirm that the merchant is authorized. Keep in mind the scenario is one where it’s a service provider that’s providing the software to the merchant. The cardholder should have some capability to confirm that they're authorized to do so. Maybe that merchant receives some type of an ID card, maybe there’s a list on a website that they can point them to. The cardholder needs to be able to validate that that merchant’s authorized, as well as a mechanism to validate the receiver of the account information is abiding by PCI.

This is no different than standard PCI requirements where monitoring the payment processors to make sure that they’re managing and maintaining the PCI compliance. The same rule of thumb would apply in the mobile space. Whoever you are sending that account information to make sure that they’re abiding by the PCI-DSS requirements.

Then around secure receipts, making sure that the personal account numbers’ masked, the credit card numbers’ masked, they're not using insecure channels for sending the account number, those types of things. You want to make sure that you’re, for instance, not using e-mail to e-mail a card number to the person as a validation of their receipt. Even if you’ve got attached printers, get them the standard PCI, making sure you’ve got that masked.


Adam: In terms of the solution provider and selecting them, the documentation has a number of suggestions or recommendations. Making sure that the solution provider’s host-based payment-acceptance application is running in a PCI-DSS compliant environment. Their recommendation is make sure that it’s tested by a Qualified Security Assessor or QSA through Visa. In other words, there have been some form of third party validation by a QSA that that particular solution provider’s host-based payment solution meets the requirements of PCI compliance.

If the solution provider provides a mobile device, making sure that maintenance and support are also included. If you’re going to get the solution from a solution provider, then make sure that they're going to take care of any maintenance or support issues that occur. The merchant needs to be able to make sure they can actually contact that solution provider at any time. If there’s some type of problem and you’re working on a mobile platform, you want to make sure you can actually contact the company that produced the software that you’re leveraging.


Making sure that there’s good documentation and training in place, which we’ve already talked about. Onboarding process gives you some example policies and procedures for the merchants. In terms of the solution provider assisting the merchant down this path, making sure that they provide some sample policies and procedures so that those can be leveraged when the merchant is sending up their own internal policies, procedures, guidelines, training programs, those types of things.


The access control mechanisms, making sure that those are in place with the capability for the merchant to basically control them. Making sure that they offer and include logging. Making sure that … and this is an important one. The termination of the agreement includes provisions for secure transfer of any historical data back to the merchant, removal of any merchant data from the mobile devices. In other words, if you’re using someone’s solution and you opt to go with a different solution, you’ve got it in writing that they will basically clean up and cleanse all the information and data, give you a copy of your data. Then they take responsibility for removal of any of that information or sensitive data from the mobile devices themselves.


Then make sure that you’ve taken a good look through their warranty and any liability statements so that they are putting an undue burden on the merchant organization itself.


Adam: The last piece of this is the section on additional risks. I’d almost referred to this as the stuff that the council didn’t quite know where to put, but things that they wanted to raise as potential issues and things for companies getting into the mobile space to think about.


You look at the physical device. They made a note that with mobile devices, many of them when stolen will be inserted into some form of a metal bag to prevent communication. The effort there is to block remote wiping of the device. That’s certainly a challenge. It’s certainly something to think about when you’re talking about using this mobile platform. If somebody steals one of these devices, throws it into a bag and your mechanism for remote wiping the device is acknowledgment that you have a device that has in fact been stolen or inappropriately acquired, if your solution is to send a signal to the device to wipe it you may not have that capability. It’s something to keep in mind as you’re coming together your plan for your mobile platform.


Risks that they listed as indeterminable risks. Certainly unforeseen attack vectors. These devices are changing, morphing, getting new capabilities it seems like every week or month. Keeping your eye out for any new connections to that device, new modes of communication, new styles of communication. All of those are going to open up new attack vectors to the mobile platform.


Once you’ve got a static device and if you’re controlling the configuration setup of the mobile device, certainly the largest decision point will be at the point at which you opt to either upgrade the devices or change to new devices. Or even if you are retiring devices that no longer work and inserting new devices into the mix, that's the point at which you want to double check that you don’t have any new attack vectors that have been opened up in this device that you haven’t already considered.


They talk about the vulnerabilities markets. Basically, what is going on in the real security world out there is that hackers will benefit from selling what are called zero day vulnerabilities to other criminal enterprises. In other words, a zero day vulnerability is a vulnerability that exist that hasn’t been widely known or publicized but that the hackers happen to know about. When they find one of these, often what they’ll do is they’ve got little markets or sell them to other organizations they may know who actually will bring this on the Internet where they’ll sell these secrets back and forth. They can take the best advantage for a vulnerability that’s not yet widely known because they’ve got the capability to benefit from that. The Council’s just calling out the fact that these things exist and that poses a potential risk to the mobile platform.


Certainly this possibility of an intentionally inserted backdoor to the platform itself. If the manufacturer of the software or the manufacturer of the device had inserted some type of a backdoor to the device itself, that would certainly pose risk to the mobile platform, the device, and potentially the payment data.

Some of the miscellaneous elements that they have listed for under additional risks were the network connections that are inherent in the device itself. The fact that that device is going to be connected to a multitude of different networks using a variety of different protocols. Certainly making sure that you’re cognizant of the style of communication and where it’s connecting to are going to be important as you assess the security of that mobile device and mobile platform. Memory management issues may come into play, where there’s a possibility for generating outages or generating a state on the mobile device that a hacker could take advantage of because of the memory practices that the manufacturer or the operating system that exist on the device itself.

There’s also the variety of devices. Today, it seems like the variety has diminished somewhat, but there’s still a fair amount of variation of these devices that are out there. You’ve got different manufacturers, different model numbers. Everybody’s coming out with the latest and greatest at a phenomenally rapid pace. That arena doesn’t look to slow down any time soon.


Access control is one of the challenges for the mobile platform. It’s a little harder to grab hold of in terms of implementing any form of role-based access control or RBAC. If your access control approach for the mobile platform is one where you implement users into roles and you then thereby give them access to the device, that’s certainly a layer of challenge that the mobile arena isn’t quite ready for yet.


April: That is a lot of info. I'm going to throw a couple of questions your way here and we’ll be able to squeeze in a couple before 3:00. I just want to reassure everyone that if we aren’t able to get to all of the questions or if you come up with some after the fact, just shoot us a buzz or contact Adam at the e-mail address we have shown there. We’ll make sure your question answered.

Adam, one question is what in your mind is the most essential piece of mobile security to focus on? What would be your basic advice to pass along to employees who use iPhones?

Adam: The most important thing to focus on with the mobile platform. The one thing that I would say, I guess, it’s almost a different way on looking at it. That is that if you want to take the risk and you want to get into the mobile space, certainly there’s a lot of things we’ve been through a ton of things to consider. Certainly, with the newness of this market, getting good security testing that focuses on both the device itself, as well as, and almost more especially, the platform that’s being leveraged.

That’s probably the most important aspect of this, because the way that the application is written, the security of the application that you create; those are the elements that are really going to go a long way to ensuring the security of the information that’s traversing in. A good security test, not only that, but the area that a lot of the mobile payment application vendors tend to skirt, if you will, is the security of all the supporting elements for the mobile app. I mean, a mobile app is typically some type of local software that resides on the device itself. The vast majority of the time, it’s just window dressing front end for some type of a backend system that is doing something with the information.

Certainly looking at the overall solution and the security of it is going to be of paramount importance. The reason why is that that gives you the capability to almost look beyond which device is it on and how it’s configured, things along those lines. You’re looking at more of the security solution itself.

The second component that you were talking about, April, was that the iPhone for an employee?

April: Yeah. Is there a piece of advice that you would pass along to employees, if you have to focus on the first security policy, to communicate to your employees through using iPhones? Where would be the first place to start?

Adam: Well, in that instance, I would almost recommend to the employee of the organization using your iPhone, if at all possible, for those that are using it at work, let’s say, if they’re already on the cellular network and not connected to the corporate assets, if you will, keep it that way. For these organizations that want to have the bring your own device to work, the employees are going to have these devices. Have them utilize those devices for their Internet access, for their outbound communications, standard connectivity to a mail server via the mail application on the device itself, but leave the boundary line there.


I think the risk for organizations to allow those devices direct connectivity to corporate network increases the risk of the corporate network exponentially. When we’re just talking about the proliferation especially on the Android platform of the fact that, as of four months ago, we had clear one-third of the devices out there infected with malware. There are a few folks in the IT space that would knowingly allow those style of devices, those types of devices connectivity to corporate network. I’d say keep that line of segregation between inside and outside and make it clear. If you can keep it that way, fantastic. If not, you’ve got a whole list of other security concerns that need to be addressed.


April: Well thanks, Adam. We do have some other questions here that we need to send your way for follow up. With respect to everyone’s time, we’re going to go ahead and close out the webinar. Thanks so much for that download. It was a great overview. Thanks so much for everyone who attended today.


Very quickly, I just wanted to share that we have some exciting webinars coming up in June. We’ll be talking a lot about encryption and using encryption to mitigate risk. We’ll be taking a peek at best practices for encryption at the software level, as well as in the hardware and storage level.


Adam’s going to rejoin us in July to talk about just why is it so hard to secure a company. He’s going to be talking about not just the technical aspects but some of the administrative and physical aspects of what it takes to truly secure a company. We’ll send out those notifications to all of you, including a link to today’s webinar. Keep an eye out for that in the next day or two. Adam, thanks again. It was a pleasure having you. We’ll look forward to more information from you soon.

Adam: Awesome. Thank you very much, April. Appreciate it.

April: Have a great day, everyone.


Adam GoslinAdam Goslin, COO, High Bit Security, LLC

Adam has an IT career that spans more than 15 years, going on to found High Bit Security, a national security services provider, providing penetration testing solutions to clients who need to protect sensitive data in industries such as Healthcare, Credit Card, Financial, or companies that otherwise store Intellectual Property or Personally Identifiable Information. High Bit Security also provides security consulting services to our clients to assist them with their compliance objectives across PCI-DSS, PA-DSS, or simply wish to perform a security best practices audit of their organization. www.HighBitSecurity.com

 



Webinars    |    Online


Get started now. Exceptional service awaits.