The opposite of “Default Permit” is “Default Deny” and it is a really good idea. It takes dedication, thought, and understanding to implement a “Default Deny” policy, which is why it is so seldom done. It’s not that much harder to do than “Default Permit” but you’ll sleep much better at night.
Source: The Six Dumbest Ideas in Computer Security
This was from 2005, and if your organization’s approach was always Default Deny, then it’s a great idea. The problem with Default Deny isn’t the idea, it’s switching away from Default Permit after decades of acclimation. One comment in the HackerNews discussion about this article says it adds “three more steps” to the conversation with IT to fix your app after the change. I would argue that it’s a whole lot more than that.
A friend of mine has trouble running a very important vendor application used in his department. It stopped working some time ago, so he opened a ticket with IT. It was so confusing to them that it got to a point that they allowed him to run Microsoft’s packet capture application on his machine. He followed their instructions, and captured what was going on. But, despite the capture, they were unable to get it working through the firewall.
Out of frustration, he sent the capture to me and asked me to take a look. Even though our laptops are really locked down, as a dev, I get admin on my machine, and I have MSDN, so I downloaded Microsoft’s tool, and looked over the capture. It was a complicated architecture, using a client/server implementation on the local machine. The front end was working over networking ports to talk to its back end, and the back end was using other ports to talk to the vendor’s servers.
I knew what to look for because I had just undergone a lot of pain with my own development workflow, because the company had started doing Default Deny, and it was messing with my development workflow in several ways. Not too long before, they dropped the bomb that EVERY network communication through the firewall required the Cisco Umbrella certificate (so that they can intercept and inspect all traffic, despite SSL). I had to figure this all out on my own, based on the behavior I was seeing, but I was able to figure out how to download that cert and include it in the chain to work with both bundle and HTTP calls in Rails, and psql for Postgres.
Then they locked out Postgres’ default port entirely. They reopened it for me at my request at first. Then six months later, they closed it again, and told me that I needed to formally request permissions for that, which was going to be a many-years-long process. I “just” rewrote the functions I needed in my Rails app to use HTTPS instead of using a direct database connection.
Anyway, I told my friend what ports IT needed to open, and how that he needed to explain to the vendor that they had to include the Umbrella cert in their chain on the back end, but he’s still having problems. Why am I being vague about the details here? It’s not because of confidentiality, though that would apply. No, it’s because my friend had been “working with IT” for over a year to get to this point, and this was two years ago, and I’ve simply forgotten a lot of the details.
“I said all of this to say” that saying it will take “3 extra rounds” is a bit of an understatement when IT starts doing “default deny,” at least in legacy manufacturing companies.