A colleague invited my attention to this article. I was engaged by this headline :
“The best way to keep mobile apps safe is to secure the services they connect to.”
Perhaps. In any case, this is good treatise on the
security of client-server applications.
However, the quote seems to
suggest that the risk is that client mobile apps are being contaminated by
connecting to rogue services. In fact,
the risk to the enterprise is more likely that rogue or compromised apps on
mobile devices will leak sensitive data into the network. Even that risk ranks after the risk to the
user that rogue apps will incur charges; this is one way that rogue apps are
being monetized.
Therefore, the issue for the
enterprise is not protecting the client app from the server, or any server, but
protecting the application and its data on the server. The best way to do that is to ensure that the
server will only accept connections from known and trusted clients. Said another way, use crypto to authenticate
the code in the app to ensure that it is the code that you think that it is;
then use crypto to authenticate the client application and bind it to the
server end-to-end.
The owner (not necessarily the
user) of the mobile device must get the client app from trusted sources, e.g., iTunes,
the enterprise itself, and protect it from contamination or compromise from
other apps. (If the enterprise does not
yet know how to protect its servers, this discussion is premature.) Again, trusted apps from trusted sources via
trusted transport or packaging. (This
assumes that the enterprise has a sufficiently well-controlled development
process that it can produce application programs that do what, and only what,
it intends.)
To protect against any
unacceptable residual risk of a rogue application on the mobile device, one
should prefer a mobile device operating system, e.g., iOS, that provides good
process-to-process isolation. For highly
sensitive applications one should use a mobile device dedicated to that
application. Hardware is cheap. This is a cost of high security and must be
balanced against the risk or sensitivity of the application. (One should not use a shared device and then
whine about its operating system.)