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.
Data encryption tool for GDPRMore information
You Might Be Interested in Reading These Articles
Connected vehicles that talk to each other, increase road safety, and rely on automation all seem like a plot from a sci-fi movie. When does the robot takeover come in? As outlandish as all of this might seem, we’re closer than ever to connected vehicles being the new normal on our roadways. In fact, by 2025, every car on the road is expected to be connected in some way, shape, or form.
Published on June 15, 2019
Can you imagine leaving your house without locking the main door while you are out? I guess not. Locking the door is a routine that we're doing automatically, so why there is so much noise about the latest update from WhatsApp that seems like the company has just reinvented communication encryption?
Published on April 07, 2016
TalkTalk, one of the largest providers of broadband and phone service in the UK, has recently admitted to being the victim of a large cyberattack. For those in the United States or in another country where TalkTalk’s influence isn’t as widespread, it could be considered on the same level as a Verizon or an AT&T data breach.
Published on November 10, 2015