Q&A: Mobile App Developers Asked How SeaCat Will Protect Their Apps, Backend, and the Data. Here Are the Answers

As cyber threats now spread to smartphones and tablets, app developers have become more interested in learning about information security. They want to know its impact on the mobile landscape and what they can do to build a strong security layer to their mobile apps.

In the last few months, we’ve spent a great deal of time talking to many developers to understand their approach on how they deal with information security of mobile app and data. This Q&A is the result of those many interviews in which app developers sent us questions, requesting details about SeaCat Mobile Secure Gateway.

1. What type of encryption is being used?

SeaCat implement TLS 1.2 FIPS 140-2 (US Federal Information Processing Standard for security apps) approves the following ciphers (among other): AES GCM, RSA, SHA-384. SeaCat uses them.

SeaCat also uses Ephemeral elliptic-curve Diffie-Hellman, the latest key agreement protocol to establish Shared Secret and provide Perfect Forward Secrecy (recommended strategies in order to minimize cyber-thread window and prevent unnecessary data leakage.)

2. What are the layers of security that will be built into the mobile app?

SeaCat provides a solid implementation of a transportation layer (network path) security, backend isolation, and Man-in-the-Middle protection. It establishes a mutual trust between your mobile application backend and the active mobile application instance.

3. How will the app manage authentication to the back-end?

SeaCat is not enforcing any specific user-level authentication; it provides information about established trust link between the mobile app instance and backen. You can build user authorization on top of this link with a great deal of flexibility using common design patterns. Additionally you can, for example, integrate SeaCat with company’s Active Directory (AD) and by doing so, establish the link between mobile app instance and global user entry in the AD.

4. Based upon the solution, will my app performance be affected, and how?

The performance of mobile app will not be affected. In fact, it will increase. Please see the performance test: www.teskalabs.com/blog/performance.

5. What other tools will I need from your company to either incorporate or purchase to ensure the security of the app works?

None. Only SeaCat is needed.

6. How much development time/cost will be allocated to building in this security?

Typically 1 MAN-DAY per mobile application

7. What exactly will SeaCat be protecting and securing?

Mobile application security is often understood as a need to secure a mobile app against threats that happen on a mobile device. This understanding is only partially correct. Most attacks happen, up to 95%, at the backend side because hackers tend to attack at points with a high concentration of valuable data, which means the mobile application’s backend server(s). Malicious apps do steal data, and the mobile app itself should be protected from such threats. SeaCat's architecture supports this strategy as well.

SeaCat follows the same principle. It gives you a solid implementation of TLS/SSL procedures on the mobile application side, something mobile app developers should build into any mobile app. However, they often fail because implementing security measures is time-consuming and very tedious work beside being virtually invisible in terms of expected outcomes.

By leveraging the client-side TLS implementation, SeaCat provides very strong protection of the network path, excluding Man-in-the-Middle attacks or any eavesdropping activities. On the server side, SeaCat provides the isolation of the backend. This technique is powerful because it leaves only the endpoints of the SeaCat Gateway(s) visible from the Internet. Any other infrastructure of the mobile app backend is hidden in a restricted network and, therefore, inaccessible to direct attacks.

The SeaCat Gateway communicates only with white-listed mobile application instances (using a certificate whitelist) and promptly rejects requests from any other sources. For example, an automated scan, a very common first step in a cyber-attack, will not detect any signature of the backend systems. This particular feature gives you the same level of protection as VPNs. The big advantage over VPN is that you can deploy such mobile application into scenarios where VPN will not be feasible e.g. B2C where customers or end-users cannot be granted VPN access. In this case, your backend is secured from all zero-day types of attacks on your OS or application stack, all common SQL injections, XML injections, other injections-types of attacks, and buffer overflows that can be exploited from unconstrained Internet environment.

One big disadvantage of VPN is that it allows all mobile apps on a device, including malicious apps, to access the private network. These malware apps would then, through the VPN channel you have opened, exploit the data residing on servers in your private network. For this precise reason that Gartner’s Janessa Rivera proposes “new models of building security directly into applications; every app needs to be self-aware and self-protecting."

Photo credit valeriebb @flickr

About the Author

Ales Teska

TeskaLabs’ founder and CEO, Ales Teska, is a driven innovator who proactively builds things and comes up with solutions to solve practical IT problems.