IP-whitelisting for DB access, does solution fit best practices?

Question

All the data we have on our customers sits in our data-lake, which is hosted by one of our suppliers. Currently the security is such that a limited number of users has (limited) access to the database each with their user-name and password. In addition there is IP whitelisting, so authorized users can only log in to the db if they are coming from one of two IP addresses originating in our office.

Our company no longer uses VPN. As a consequence we only access this DB from the office not when working from home or from one of our suppliers.

The simplest/cheapest way to allow working from outside the office would be to ask the supplier to whitelist the range of IP addresses used by Symantec (= software security product that routes traffic through its proxies), because when we log in to our network from the outside we get one of these addresses. But the upshot would be that every Symantec customer could potentially log into our DB, provided they somehow got hold of a user-name password combination. Someone intent on breaking in would only need to:

1. Guess the user names (a combination of first-name and last-name)
2. Get Symantec or ask someone our guest WiFi password and sit on our lawn using our wifi
3. Somehow get the password

Only step 3 is really hard.

If we got an extra server with a static (public) IP address and only allowed logging into the DB for users coming from this server, we would have an extra layer of security. Am i correct in thinking this would be a good way of securing our data while making working from outside the office possible?

How do i convince management that whitelisting the entire Symantec IP range is dangerous, because it is dangerous, right? Have there been breaches of this kind?

I'd really like to know what the best practices are for such cases and why.

Related question: Why would DB with URL access be less secured than without such access?

Answer 1

VPN

Although your whole company no longer uses a VPN; you can still use a VPN. You can provision a VPN that is only used for this scenario:

• Create a VPN server (plenty out there to choose from)
• Connect the destination database server to that VPN as a client
• Configure each company user to that VPN as a client
• Each company user connects to the VPN when they want to access the database
• It's now within your power to add further security features if you like. For example, with some VPN products you can require Duo Mobile 2FA.

In this situation, a VPN does three things:

• Passage: makes the connection through firewalls and proxies end to end. This is what you needed the most.
• Encryption: provides encrypted encapsulation
• Auditing: logging of when clients connect to the VPN to approximate access.

---

Web Application Firewall

You aren't completely clear about how you View the "data-lake". Perhaps the user has a tool on their desktop; but if it's a web-application that is hosted by your provider, then I would recommend something like CloudFlare Access. With that you can login using your enterprise SSO.

---

With more context and information I may think of other solutions

Answer 2

1. IP Whitelisting
I've seen IP whitelisting being used but only for specific IP addresses, from inside the office or customer's offices, never allowing an entire range. That simple solution you suggested is still better than nothing, but every time one more person gets closer to your systems, you can consider that person a possible threat for your system without being paranoid, especially if you don't know at all that person.

2. Usernames
Given the social data you can find online, from personal profiles to professional profiles (you will guess both of them I'm thinking of, or more), it shouldn't be difficult to come with a list of employees (not only one) and try different combinations of their first and last names. A simple way that comes to my mind is to deliver emails to those usernames and see which ones are delivered. In this way you can get an idea how the usernames are put together.

3. Passwords
Once you have the usernames, you don't have to guess somehow passwords. If you have other security vulnerabilities, maybe it's not that difficult to get a list of password hashes and start cracking them using some dedicated tool. Another method would be once you have a list of usernames you can try the most common passwords people use for all of them.

4. Guest Wifi
I will guess that also the password wifi is not something really random and it might be pretty easy to guess. If not, many people are inherently good and offer to help with this kind of data not knowing they're doing something wrong. Training the employees is always important.

5. Suggestions for convincing them
Management usually likes facts and data, not arguments. If you have the time, you can take the list of all the employees usernames and run a password cracking tool against them. Most probably, someone (or more) has a weak password. If you can compromise the system, someone more advanced or dedicated because of any reasons can do it as well. Also it helps if you can tell them something like - this is a risk from my point of view that will cost us this much (not necessarily numbers, you can use terms like reputation, customer confidence, out of business etc.). But if they won't do it your way, don't be disappointed. There is always a trade off between security and what brings money.