Securing Mobile Data Communications

Thursday, November 17, 2011

Steven Fox, CISSP, QSA

Bddcc5065237c686cb4d89dba8b276f2

Wireless communication is inherently insecure.

My consulting experience has confirmed that some organizations understand this fact when connecting to wireless networks with their laptops.

However, their awareness falters when connecting their mobile devices to the same networks.

According to a Echoworx study, 44% of the surveyed audience at London’s Infosecurity Europe 2011 conference transmitted sensitive information unencrypted to the Internet via their mobile devices.

OWASP cites spoofing attacks and surveillance as significant when using wireless communications with a mobile device. Wifi, 3G, GSM, CDMA & bluetooth; these are but a few transport protocols targeted to affect the confidentiality and integrity of the transmitted data.

The controls discussed in this installment are designed to make successful exploits more difficult and to obfuscate the data to the point that successful exploits will result in no return for the attacker.

SSL vs. TLS

SSL and TLS provide an end-to-end secure communication channel, but they support different encryption algorithms. For example, SSL does not support 3DES or AES encryption; algorithms required by applications that handle sensitive data such as user credentials, as well as personal or business-critical information.

Data classification and organizational requirements will influence which one is implemented on a device. All Federal information systems that transmit sensitive information, for example, require the use of TLS.

Encryption Algorithms

The selection of encryption algorithms to support a mobile device will be determined by data classification considerations and business requirements. Several vendors in the defense industry, for example, are developing FIPS 140-2 validated devices to support applications used by the DoD and NSA. Some private industry applications may require similar encryption levels, but most use cases can be accommodated with SSL or TLS.

OWASP recommends that strong encryption algorithms and key lengths be used to protect data in motion. It also recommends that only signed certificates be allowed and that they are associated with reputable certificate authorities.

Signed certificates allow you to verify the source and validity of an encryption certificate, countering unsigned certificates often employed by attackers to gain access to information.

Additionally, it is imperative that chain validation is implemented when chained SSL certificates are used. The encryption management system on the device should make it possible for the user to determine the validity of a certificate via the user interface.

Lastly, the device should employ mechanisms that mitigate the threat of man-in-middle attacks such as SSL strip. These attacks take advantage of SSL connections that do not verify the identity of the remote server.

This allows an attacker to intercept communications, determine the encryption key and decrypt the data in transit. Countermeasures employ various techniques to verify the communicating devices and the integrity of the encryption information.

The next installment of this series will explore user authentication/authorization and session management. McAfee’s solutions to this problem space will be detailed and mapped to OWASP recommendations.

Until then, be sure to follow us on @McAfeeBusiness for regular updates on McAfee happenings and news.

Cross-posted from the McAfee Security Connected blog

Possibly Related Articles:
6546
General
Information Security
OWASP Encryption SSL Wireless Digital Certificates TLS SSLstrip FIPS 140-2
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.