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
Most Recent Articles
- A beginner-friendly intro to the Correlator for effective cybersecurity detection
- Inotify in ASAB Library
- From State Machine to Stateless Microservice
- Entangled ways of product development in the area of cybersecurity #3 - LogMan.io
- Entangled ways of product development in the area of cybersecurity #2 - BitSwan
You Might Be Interested in Reading These Articles
Building a private cloud on AMD Ryzen and Linux Containers
At our company, we develop our own software products that we offer to our clients and often also run ourselves. So far our company has operated its IT infrastructure — about 30 virtual servers—on a public cloud, specifically on MS Azure.
Published on July 01, 2018
SeaCat Tutorial - Chapter 5: Using Parse.com with REST Integration (iOS)
As the market with Cloud Computing and Mobile devices is getting bigger, there is another specific option available. It's called (Mobile)Backend-As-A-Service (BAAS) and it is extremely useful in situations we want to subscribe a complex backend service (alongside the core backend solution, there is usually a lot of additional functionality and statistics) and primary focus on development of client part of mobile apps for instance.
Published on January 31, 2015
Engaged with ASAB
About microservices, coroutines, failures and enthusiasm. And most of all, about ASAB. ASAB is the first thing that probably every newcomer to TeskaLabs gets fond of.
Published on June 15, 2022