Category Archives: mobile

Guest Post: A Trojan Horse In Every Pocket

“A hacker wiPhone with keyshing to break into a specific company may decide that compromising an unprotected mobile device is far easier than dealing with corporate firewalls”

After years of experience, and learning from the high profile mistakes of others, businesses are fully aware of the importance of security on desktop and laptop computers.  Anti-virus software and encryption tools are standard issue, and user rights management also forms a key part of any corporate security setup.

But this is now only one aspect of securing a business against digital threats. The rapid growth of powerful mobile devices has opened a whole new front in the war against hackers, viruses and mischief makers.

Now in addition to locking down a desktop and laptop computers, business owners must consider the danger posed by mobile devices, and those that don’t risk exposing their company to financial or reputational loss.

A trojan horse in every pocket

Smartphones and tablets can be hugely beneficial to businesses, but an unsecured device offers another route to confidential information for hackers.

There are already numerous mobile viruses in circulation. Typically these are untargeted, they’re used to gather private information or send premium rate texts for the financial benefit of those controlling the software. But a dedicated coder could easily create a virus with a much narrower focus, one designed with the express purpose of penetrating a company.

There’s already been one very high profile example of this kind of attack on desktop systems. Stuxnet was a virus designed to damage to a very particular type of industrial equipment used by the Iranian nuclear programme.

This was a sophisticated, state-sponsored effort, but it’s not restricted to those with government backing. A group known as ‘Winnti’ have been using malware attacks to steal online gaming credentials, security certificates and source code in order to profit from trading virtual currency and stolen data.

And just this month a new virus was discovered that is thought to have been targeted at UK companies, silently infecting thousands of machines.

A hacker wishing to break into a specific company may decide that compromising an unprotected mobile device is far easier than trying to deal with corporate firewalls. It could be all they need to capture confidential information or gain access to internal systems.

What can be done?

At this year’s Mobile World Congress event all the major security firms were in attendance, and while they were jockeying for attention for their own software solutions they did all agree on one thing: users need educating.

“On PC everybody is aware they need protection”, says Stefan Wesche of Norton Antivirus, “on mobile most people are not aware, and that’s where we should start, telling them about the problem.”

We’re all accustomed to the need for good passwords and up-to-date anti-virus on our computers, but the concept of anti-virus on a smartphone is still alien to many people.

Businesses need to start by ensuring their security guidelines cover the use of mobile devices, and that all employees are aware of the risks.

They also need to examine the inherent security features of the various mobile platforms; one reason BlackBerry was so popular for corporations was thanks to the excellent security it offered as a standard feature. At present, Google’s Android mobile OS has the largest number of viruses partly because there are very few limits to what users and developers can do with their devices. That offers many advantages, but also allows malware to piggy-back on pirated software or sneak in through the official app store.

A robust mobile security policy is particularly vital with the growth of ‘Bring Your Own Device’ (BYOD), where employees are permitted to use personal equipment. This can be a money saver, but a smartphone which is being used to download apps and games at home, perhaps being used by children, and then taken to work for business emails and calls should be a big area of concern for IT managers.

Author Bio: Matt Powell is the editor for the broadband, smartphone and tablet consumer information site Broadband Genie.

Mastercard Best Practices for Mobile POS Acceptance

Mastercard has released “Mastercard Best Practices for Mobile Point of Sale Acceptance”.

If you’re a POS solution developer, you’ll be interested in this document as it provides guidance on how to develop your solution, and if you’re a merchant, it provides you with guidance on the kinds of features your intended mobile POS implementation should support.

Solution developers are strongly advised to adhere to the P2PE (point to point encryption) standard – a message that comes as no surprise given the cross-brand endorsement of the P2PE standard. Read the P2PE FAQ for more information about the standard.

Download the Mastercard PDF document here.

 

Which Applications Are Eligible for PA DSS?

A FAQ, which is neatly addressed in the PCI SSC guidance note available from here.

In summary:

If you can answer “yes” to any of the following questions, then your application is not eligible for validation under PA DSS (but may still be required to operate in a PCI DSS compliant fashion)

  1. Is this a beta version of the application?
  2. Does the application handle cardholder data, but the application itself does not facilitate authorization or settlement?
  3. Does the application facilitate authorization or settlement, but has no access to cardholder data or sensitive authentication data?
  4. Does the application require source code customization or significant configuration by the customer (as opposed to being sold and installed “off the shelf”) such that the changes impact one or more PA-DSS requirements?
  5. Is the application a back-office system that stores cardholder data but does not facilitate authorization or settlement of credit card transactions? For example Reporting and CRM, or Rewards or fraud scoring
  6. Is the application developed in-house and only used by the company that developed the application?
  7. Is the application developed and sold to a single customer for the sole use of that customer?
  8. Does the application function as a shared library (such as a DLL) that must be implemented with another software component in order to function, but that is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software components?
  9. Does the application depend on other software in order to meet one or more PA-DSS requirements, but is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software?
  10. Is the application a single module that is not submitted as part of a suite, and that does not facilitate authorization or settlement on its own?
  11. Is the application offered only as software as a service (SAAS) that is not sold, distributed, or licensed to third parties?
  12. Is the application an operating system, database or platform; even one that may store, process, or transmit cardholder data?
  13. Does the application operate on any consumer electronic handheld device (e.g., smart phone, tablet or PDA) that is not solely dedicated to payment acceptance for transaction processing?

Point 13 above is expanded upon in the SSC document “Mobile Payment Acceptance FAQ“, where the different categories of mobile payment acceptance applications are detailed.