Why Is Data Encryption Necessary even in Private Networks?
WhatsApp recently announced that they turned on end-to-end encryption for their messaging app, estimated to be used by 1 billion users. In this case, end-to-end encryption secures communication between endpoint devices, such as smartphones or the tablets.
Securing data transferred between different endpoints is important not only through public networks but also in private networks. The data has to be protected if it is business critical or if modification or interception leads to a security incident with a high business impact. Can you imagine if it is easy for cyber attackers to intercept your bank transfers, documents or information about the business strategy or customers, the traffic, modify the data, delete or even redirect it to another server?
Keeping the data secure means ensuring the principle of the CIA triad (Confidentiality, Availability and Integrity); an important concept in information security. Securing the communication by implementing HTTPS, for example, doesn’t ensure confidentiality if the HTTPS communication does not end at the application backend. There is a possibility that data will be modified during the transfer to the final destination, thus the CIA principle is not ensured.
Why is it important to encrypt data even in a private network?
All data transfers are done using a public or private network. The public network is the Internet or any local Internet Service Provider (ISP) network used by customers. Based on lots of research and studies done about the DROWN attacks or other HTTPS-related attacks, there are a lot of servers with wrong HTTPS configurations which endangers the transferred data.
The big problem is that encrypted data needs to be decrypted before being processed by the application logic. This decryption can be done in various devices such as firewalls, load balancers, SSL terminators, web application firewalls, and of course, application backends. The fact that a HTTPS session is terminated before the data arrives at the application backend poses a big issue. That means that if the data is decrypted before reaching the application backend logic, it can be intercepted.
There have been and always will be bad guys who want to hijack the network to get their hands on the data. There are also many other devices such as routers, firewalls, anti-spam filters in the network that can be tampered with or operated by hackers to manipulate communications.
Payload encryption helps when you encounter these issues or need an extra layer of security protection.
Let's imagine that you have an SSL Terminator in your DMZ. The HTTPS traffic is then terminated inside the DMZ at the SSL Terminator. If the data is not encrypted and only HTTPS is in place, the data is in readable form before being sent further inside the private network protected by a firewall. Operators of the firewall can intercept, change or manipulate the data.
It’s important to keep in mind that every device that works with unencrypted data can be manipulated.
Data being decrypted inside a private network
Allowing unencrypted communication even in private networks can incur severe consequences. It is hard to trust that all employees and contractors will know and do the right things when they have access to company servers and sensitive business information. They can intercept the data if the data are not encrypted. Thus, it is up to responsible people, the Application Business Owner, for example, to define the level of importance of the data and how they want to secure it.
If the data contains information about customers, payment transactions, company strategies or unpublished decisions, the impact is devastating.
To make it short:
- Encrypt the payload transmitted from the client
- Allow only the application backend to decrypt the data
How SeaCat supports encryption
SeaCat client, SDK, is embedded with a protected mobile application and encrypts transmitted data by the recipient’s certificate. In our solution, this is the application backend certificate. The payload is then transferred via a secure client connection to the SeaCat Gateway where the secure client connection is finally terminated. However, the transferred data is not yet decrypted until it is passed to the application backend.
SeaCat supports this approach to payload encryption, keeping data private until it reaches the application backend, and in doing so, guarantees data protection in both public and private networks.
Data encrypted inside a private network
If your mobile or IoT application is secured by SeaCat and monitored by our Network Security Center, you have payload encryption built-in. To get a true assessment of the architecture and security of your mobile application, please request a FREE Demo. Or, to learn more about TeskaLabs’ SeaCat Mobile Secure Gateway and how we can help you with the security of your mobility solutions, please visit www.teskalabs.com/products/seacat-mobile-secure-gateway.
Most Recent Articles
- TeskaLabs helps LINET with cyber security compliance for medical devices
- TeskaLabs and University hospital in Pilsen launches a pilot of zScanner - open source mobile app for medical photo documentation
- EV Charging Station security demonstrator
- Five Ways AI And Machine Learning Can Enhance Cybersecurity Strategy
- C-ITS ITS-S Security microservice
You Might Be Interested in Reading These Articles
It’s clear that POS systems are a source of important and valuable data, and have the power to either speed up the progress or to stop the development of a company, depending on whether or not they are used. POS data is a business asset. Despite this vital importance, such an asset is not afforded the protection it deserves.
Published on March 07, 2017
Researchers from the University of California, Riverside, and the U.S. Army Research Laboratory have found an off-path TCP vulnerability  that affects more than 80% of Android mobile devices. Unlike a Man-in-The-Middle attack, you don't need to be in the middle of the communication to get hacked - all attackers need to know is who you communicate with.
Published on October 11, 2016
The official source of OpenSSL software is the OpenSSL website. One can download OpenSSL source codes archives and compile them for a given platform. The compilation work can sometimes be quite tedious, especially for exotic platforms. We, at TeskaLabs, set up this page because we frequently compile OpenSSL for various platforms for our internal purposes and this may save some time to other developers.
Published on July 20, 2017