This post/rant is a long time coming. Although it seems recently I’ve been running into the problem more and more often. I get a request from a customer to allowlist a new SaaS application that someone has purchased.
The first struggle is usually getting any kind of documentation from the vendor as to what is needed for the software to run. It’s amazing how many vendors don’t have a simple network/firewall requirements document for their application. Assuming they have one, the fun is still to come.
So you finally have the document and start to review it. And there it is! Right in the first list of domains that need to be allowed unrestricted… *.s3.amazonaws.com. Or maybe it’s not that bad, maybe it’s *.digitalocean.com. Unfortunately, both are real-world examples I’ve seen just this year. Really though, I shouldn’t complain; at least with domains, I don’t have to allowlist wide swaths of shared IP address space. I’ve also recently seen SaaS requirements that include allowing all traffic to 3.0.0.0/8.
I think the root of the problem is two fold. First, no one is documenting their architecture well enough to create these documents. Secondly, developers have become used to microservice sprawl. During development they just make it work with whatever IP or DNS entries the cloud provider creates. It works in their testing where they have unfettered access to everything. By the time the application is put into production, there is a spiderweb of dependencies that may even span multiple cloud providers. What I would like to propose is that developers work to understand DNS and use it to simplify.
Instead of l1d81ka.azureservices.net and myapp.s3.amazonaws.com, create CNAMES! These aliases are easy to setup and allow for some semblance of self-documentation if they’re named reasonably. Imagine a world where fancyappname.ai has CNAMEs like webfrontend.fancyappname.ai, microservice1.fancyappname.ai, logserv.fancyappname.ai, etc. This would be great for us in security because then we only have to worry about allowlisting a specific set of FQDNs. We won’t care what the IP addresses are and as such the SaaS vendor can flex their application to other IPs or clouds as needed without disruption.
Now that I’m dreaming, let’s take it another step. I have seen a select few SaaS vendors (outside of the big guys like Microsoft) providing either a REST API or a extended dynamic list service that is constantly updated with their FQDNs or IP addresses. This can then be used as an object in most firewalls. The nice part about this is that the SaaS vendor can add or subtract things as needed without a scramble by customers.
Final Thoughts
The bottom line for me is that developers and SaaS vendors need to start thinking about the security implications of their application architecture. While most are securing their applications now, they’re not thinking about the security concerns of their customers. Perhaps they should consider having security professionals setup secure firewalled environments or even a ZTNA agent on the developers’ network(s) so they know the headache. Unfortunately, I see more and more that developers are treated as “special” and have a lot of security controls removed because “they have to have it that way”. Security must become second nature.
