SaaS – Stop IP Whitelisting


Well the title “Stop IP Whitelisting” is a bit much but hopefully it got your attention. But in this post, I’m going to talk and rant a bit about why we as a industry need to limit WHERE and HOW we leverage IP whitelisting.

Enterprise: Hey we love your SaaS product that’s hosted in the cloud. Could you enable 2FA or a federated login for us?

Vendor: We don’t support 2FA or federated login. But if you give us your IP’s, we can whitelist you.

Enterprise: Great! Here is our VPN egress IP’s that is literally the same for every employee!

I guarantee that this conversation has happened multiple times at every Enterprise and it is the reason for this post. IP Whitelisting is NOT a strong control and certainly not a second factor

Now having said that, there are places where IP Whitelisting is perfectly reasonable and can allow you to mitigate risk extremely quickly and its transparent to the devices underneath it. However IP Whitelisting is abused way too much when we deal with SaaS products and integrations. Here I’ll give you another example for integrations:

Vendor: Hey we need to call your API endpoint so we can send along client referrals for your product.

Enterprise: Ok.. but that API endpoint is not public facing right now. 

Leadership: Guys figure this out… this has to go live next week.

Vendor: Can you make it public facing and just whitelist our egress IP’s?

Enterprise: That works! Send them over!

This is probably the most common example in the industry. Integrations need to happen and the quickest route is IP whitelisting. Don’t do this… you just placed a huge amount of trust in this vendor. They could have hundreds of networks (and users) originating from that egress IP.

IP Whitelisting is a Weak control

When I say its a weak control, I don’t mean you can spoof IP’s to bypass whitelisting (unless they are enforcing it by HTTP headers so don’t do that). In fact, to complete a TCP handshake, its pretty much impossible to spoof IP’s because you won’t get the SYN-ACK response. You basically have to compromise ISP routers. What I mean is that IP whitelisting is too broad and you can only see the last “hop”. You don’t really know what is coming from that IP.

Enterprises today have SO many third party vendors. So much software. So many integrations and consultants. Why does this matter? Well sure there is a huge third-party risk management concern but what I’m saying is that our “internal” network is not really internal. People assume (often incorrectly) that the zones they are whitelisting are trusted because they aren’t sitting on the public internet. This is a very, very bad assumption. 

So when we perform IP whitelisting, we aren’t whitelisting a user or device or even sometimes a single network. When people say “Hey lets whitelist their X.X.X.X publicly routable IP”. How the hell do you know what systems/networks are behind that IP (i.e. NAT) ? Its certainly not a replacement for 2FA but instead should be used as a complementary control. 

If you have ever working on a Red Team or performed a Penetration test, there is a methodology you have likely heard called “Assumed Breach”. Its the idea that instead of wasting 90% of our time trying to get into your network (i.e. phishing, public facing RCE, etc.), we will “assume” that we are already on your network. And this comes from the realization that attackers will get access to your internal networks so let’s test your security posture from the inside. Remember, a successful attack is just a function of (Time x Resources). So as you can see, the internal network is not always “trusted” or “safe”. Attackers or nefarious employees can always take advantage of that.

So what is the solution?

Well in some cases, IP Whitelisting is perfectly reasonable. If the scope is small enough and you have another “layer” to granularly control traffic, IP Whitelisting can be great. 

And vendors and products are starting to support 2FA, federated logins and Mutual TLS (mTLS), which is awesome. So I think in some respects, this problem of “whitelisting” everything may solve itself as legacy products/vendors are pushed out of the market. Well maybe not solve but it will give you the technical means to enforce these controls. But again, may times people whitelist because they are lazy, don’t know any better or the implementation doesn’t support any better controls. So I’m probably being overly optimistic. 

Ultimately, the appropriate control is really going to depend on your threat model and data classification. If you are sending Card holder data between two companies and your “control” is whitelisting IP’s… just go ahead and call up Visa/Mastercard and tell them you have a massive PCI violation.

With integrations that support it, mTLS is really a great option. If you want to also use IP whitelisting as a complementary control, that’s great. Just remember that IP’s don’t represent a device, user or even a network. IP’s often represent entire companies. Do you really want to trust an entire company that you have limited visibility into? 


Leave a Reply

Your email address will not be published. Required fields are marked *