Why App Transport Security can’t get here soon enough

(c)iStock.com/Prykhodov

What is completely transparent but protects you from prying eyes? Encryption, of course! “Completely transparent” may be a bit of an overstatement but, generally speaking, the way encryption operates is fairly painless for the average end user. However, with the January 1, 2017 deadline looming for requiring all App Store apps to utilize App Transport Security (a.k.a. ATS, Apple terminology for securing all app traffic using the TLS v1.2 protocol), encryption may get a little more challenging for many developers.

ATS: Good for security, good for privacy

In practice, the change is more procedural than technical: By default, ATS is enabled for apps linked against iOS 9 and newer SDKs, though developers could disable it or create exemptions for specific domains or types of traffic. The announcement made in June 2016 during the annual Apple WWDC does not change the behavior or implementation, but does create a new requirement for admission to the App Store. Previously, there was no penalty if an app developer chose to bypass security best practices. But when the new review procedures go into effect at the beginning of next year, apps that are submitted with ATS disabled will be rejected. Of course, developers can apply for exceptions but that process will almost certainly delay the approval process.

The policy is a security and privacy win for both consumers and enterprises because the new requirement will go a long way toward protecting data in transit. This is especially important considering mobile users are notorious for using whatever Wi-Fi hotspot is available to them (protected or otherwise) and since native mobile apps often lack the typical visual indicators present in web browsers to denote secure connectivity. As beneficial as ATS will be, it is unfortunately not a silver bullet. It’s important to note that the change affects only apps submitted for App Store review after January 1, 2017 and that apps without ATS submitted before the deadline will not be removed. For enterprises - especially those who rely on third party developers- it’s also important to remember that in-house apps are not subject to the same policies and code reviews as App Store apps and may, therefore, not conform to best practices.

ATS confusion exists

This is not to say that the mandate is a trivial change for developers. A cursory examination of developer forums reveals a great deal of reticence and confusion. Meanwhile, MobileIron partner, Appthority, recently published research suggesting that the overwhelming majority of apps disable ATS or permit insecure connections. These alarming statistics, combined with broader findings about the disappointing state of server-side security configurations (such as failing to address basic OWASP recommendations) echo the findings from the MobileIron 2Q2016 Mobile Security and Risk Review evincing a troubling-- and continued-- lack of basic security hygiene.

Organizations shouldn’t wait to assess the state of their mobile apps. There are several actions that can be taken to determine whether or not network traffic is adequately protected, as well as some compensating technologies for cases when it isn’t.

  • Any organization permitting access to enterprise data from mobile apps should audit how those apps protect data in transit. There are a number of sophisticated commercial tools available, but barrier to entry is surprisingly low because rudimentary “dynamic analysis” of network traffic can be performed with an iOS device, an Xcode utility called rvictl, Wireshark, and-- of course-- someone to use the app.
  • For apps that don’t natively encrypt network traffic, consider iOS Per-app VPN as an alternative. The beauty of Per-app VPN is that it offers a way to protect app traffic without any need to modify the underlying code.
  • Organizations investing in custom apps can’t afford not to invest in static analysis. The tools are mature, readily available, and are the best option for ensuring that apps are built in compliance with best practices as well as provide a hedge against risks that ATS can’t address (such as vulnerable 3rd party libraries).
  • The cost and complexity of deploying HTTPS and managing digital certificates is no longer a valid excuse: Internet-facing services handling sensitive data have a responsibility to protect it. Furthermore, much of the overhead associated with securing web services has all but disappeared thanks to the work of projects like Let’s Encrypt which offers free digital certificates and a new, automated certificate renewal protocol.

ATS is a great step forward, but it’s only one part of a larger whole in cyber security that remains our shared responsibility. Take advantage of this important advancement but don’t forget to do your part too.

Related Stories

Leave a comment

Alternatively

This will only be used to quickly provide signup information and will not allow us to post to your account or appear on your timeline.

thenortonsetup
30 Dec 2016, 10:27 a.m.

I’m not that much of a online reader to be honest but your sites really nice, keep
it up! I’ll go ahead and bookmark your site to come back down the road.
Many thanks

Reply