What is back end security and why is it a prerequisite?
As we know security over the internet is far more important now than ever before. While making a mobile app, building a website, or doing any business online, it’s important to follow security protocols in order to avoid major data breaches. A report on cyber-attack statistics from 2015 showed that most hackers (almost 60%) attack targets with the intent of accumulating data and making money. That same report showed that around 72% of known attacks occurred in what is known as the “backend.” This definitely highlights how important is backend security.
What is the Backend?
Well now we know that backend security is important, but what exactly makes the “backend?” To make it simple, the backend is the part of a website, web application, or you can say mobile application that is behind the scenes. Opposite to is the “frontend” of an application which is everything that the user interacts with. This can include design features in the application or website , links, images,transactions, content, and others.
The backend is often used for data storage or communication. It mainly consists of an application, a server and a database. If your mobile app does some business like selling products, then your customers will be dealing with the mobile app itself (not the backend applications). Browsing through your selection of products like clothes or electronic items and making purchases all technically occur on the frontend side within the mobile application. The information about the order of the user , their personal details ,their account, are all stored in the backend. This is, of course, to ensure that all their their information is all in one convenient location.
The backend is like the repository of everything that makes your web presence and mobile apps run smoothly. In many cases, all the information in the backend is stored on even cloud-based servers or even remotely . This may lead to certain vulnerabilities, especially when the information of your clients or employees is at risk.
For vast enterprises, backend systems means a much broader scope of information. Due to this, the backend consists of “Enterprise Resource Planning” (ERP) software that integrates all sorts of information ranging from manufacturing product planning, payment information,marketing to shipping, and inventory management. Clearly, the data stored in the backend can be expansive and extremely sensitive
What is the need of Backend Security??
In present businesses are more vulnerable to cyber-attacks than ever before. You do not need look further than large scale attacks recently like the one on dating website such as Ashley Madison, to discover why backend security is so important. That very attack made the account information of around thirty seven million users available to the general public and to the hackers. Other entities have also been the victims of cyber-attacks including , LastPass,password manager and even the online auction site, eBay.
These are not isolated incidents either. An estimated 556 million people become victims of cybercrime to some degree every year. While not all 556 million are victims of backend vulnerabilities, this really highlights the need for better security.
To keep data thieves away from your databases and servers is, perhaps, the most vital step you can take keeping in account the security and privacy of your sensitive corporate information, your customers, and your employees . Without the sufficient backend infrastructure and security, you could be at immediate risk of incurring a devastating cyber-attack.
Many businesses are beginning to use intra-company apps to better manage their workflow. On top of that, employees are connecting to office networks from variety of locations from a variety of different devices. Information that is inputted makes its way to backend databases and servers, meaning that a single cyber-attack could compromise unaccountable aspects of your business.
How to Boost Your Security
It is totally without no question that backend security is vital to the success and health of any enterprise. A security software that integrates within your current ERP or SAP system is the best way to ensure both continued functionality and proper security. Whether your mobile app is for your employee base or clientele , it is important to keep backend cyber-attacks at bay.
Goals of latest backend security system
Apart from security practices themselves, today’s typical engineering patterns and application architecture have changed significantly. Also, the level of detail modern developer is willing to get into is unlike 15 years ago — developer expects most of the things to be neatly solved by existing frameworks and software
When thinking of backend/database security, we generally want:
access control with very strong compartmentation: authentication, granular CRUD authorization per table/user,
leakage prevention at rest / in use / in motion.
authenticity and integrity of all data.
When thinking about modern practices, we might add:
1. Risk model should consider baseline to be ‘everything will be broken’ threat model:
everything is in the cloud and the cloud itself should have very limited trust,
the database, middleware, API providers and front-end talk over the open internet,
they don’t have a centralised source of trust,
they don’t share verifiable physical factors,
they can be compromised without awareness of other talking parties.
2. Security instrumentation should easily blend into data representation:
Easy management and entity mapping.
3. Security functions should include as little cryptographic detail as possible to isolate error and minimise adoption friction.
Also, we want to sacrifice as little database-specific benefits as possible:
Indexing protected data and searching over it,
Using protected data in SQL statements,
Control protection with flexible granularity — from cell to table.
Solutions to some challenges
Unfortunately, no all-encompassing solutions for aforementioned problems exist. However, for each of the problems and goals of backend security design, there are numerous components and techniques we might use.
We can divide new protection solutions into few classes:
Encryption: searching, indexing, encrypted query databases,
Encryption: Searching / Indexing
Searching is a subset of controlling read access cryptographically: how to allow processes with certain features / keys to read the data without compromising it to potential attackers, yet preserving ability to execute various queries on top of it.
SSE, Searchable Symmetric Encryption
A promising approach to symmetrically encrypt text, then challenge the database with specially crafted queries. Works with sequential scanning and indexing but is rather limited and is a bit theoretical. There is an implementation to try out and build on, anyway:
PEKS, Public Key Encryption Scheme
Public Key Encryption Keyword Search scheme relies on data owner to generate a number of trust tokens, which are used within ‘verification’ process, which allows the server to verify whether chosen keyword is available or not within encrypted data. Although slow and theoretical currently, possible security of this scheme is very interesting.
Homomorphic encryption is a method of performing calculations on encrypted information without decrypting it first. There are fully and partially homomorphic encryption schemes, which provide different sets of operations on protected data. Apart from searching, there are many use-cases (like using the data to perform certain calculations), in which homomorphic encryption is extremely useful.
Although looking as a part of the future, there are no practically usable systems till today:
Lattice-based encryption has also attracted attention from theoreticians who talk about its “flexibility for realising powerful tools like fully homomorphic encryption”. The latest speed reports for fully homomorphic encryption are — let me use precise technical terminology here since I’m a big fan of careful benchmarking — ludicrously slow, but without ideal lattices, they would be utterly ludicrously slow.
Minimal exposure search index
There are more practical approaches, though. You can manually define a list of tokens you’d like to search over, encrypt or hash them, and search accordingly. You can decouple search IDs and tokens from actual data before encrypting/hashing them, thus making sure that known ciphertext attack won’t be useful.
Encrypted query databases : CryptDB
CryptDB is a system that provides practical and provable confidentiality in the face of these attacks for applications backed by SQL databases. A scientific research led by MIT, CryptDB carefully balances various encryption techniques with risks and requires requesting the party to craft a special encrypted query to execute it over protected data. Although looking quite well and being adopted by many parties, there already are known vulnerabilities (https://cs.brown.edu/~seny/pubs/edb.pdf) and weaknesses, which already led to ‘how to use CryptDB securely’ guidelines. Although the dispute is yet to be solved, in most cases we can consider CryptDB practically applicable to backend data security problems.
What would you do if you can’t control trust of a large database and/or application cluster? You offload critical procedures to a small service, running in a well-controlled environment (and, perhaps, powered by hardware separate from constantly-loaded database cluster).
There’s an easy classic way to offload trust — to a dedicated piece of hardware, performing all cryptographic operations and managing keys. There are cases where such solution might feel efficient, yet, typical HSM performance is not helpful when processing a lot of data.
HSMs are available for all mainstream commercial databases, and, with some level of effort, are easy to integrate into modern open-source ones.
Integrated security instrumentation
A lot of older database protection techniques rely on a database running in the safe and secure environment: e.g. trusting the system you run your code on. This is a place for traditional security instrumentation: Host IDS (like Samhain), Mandatory Access Control (like SELinux) and others.
Most existing database encryption techniques enforce only read control, preventing the risk of data exposure, by requiring a key to access encrypted data. Some of them verify the authenticity of protected records, thus providing tampering protection, but we are not aware of any schemes with write control (apart from the ones we’ve developed ourselves, but later on this). Apart from read control, the rest is enforced by typical ACL/grant techniques, which rely on trusting that database behaviour is not compromised by an attacker.
Inside previously discussed threat model, we want as little trust put into backend as possible. This means enforcing access control via non-database techniques, like encryption, and making sure that except for legitimate consumers, data ‘in process’ is decrypted as little as possible (if decrypted at all).
There are many techniques for protecting data stored within database / application backend. Intuitively it feels that by combining a few tools here and there we might achieve some decent level of security. Practically, we need to understand threat model, how to limit attack surface and protect it really well. It is a part of application/infrastructure design, not a ‘feature’, nor a ‘service’.