Chances are, you aren’t using firewall best practices. Many organizations manage their firewall compliance requirements by turning on the firewall, using most of the default settings, and walking away. Unfortunately, setting up a robust firewall that can protect your company in today’s environment isn’t easy or straightforward.
There was a time when you could get away with checking off the basic items on the list and moving on, but not anymore. Firewall maintenance requires a good amount of thought, introspection, and attention to detail. Most organizations fall short in this area, and too many of them pay for it eventually. Here’s why.
The firewall is a device that sits at the perimeter of your network. Like a bouncer at a nightclub, it allows certain traffic in and certain traffic out. And like a bouncer, it needs to be picky about what gets through. Over time, changes will be made to your firewall’s rules, and you need to stay on top of them. Otherwise, you could find yourself in a situation like this one.
Related reading: How Will Coronavirus Impact Your Company’s Security?
A Firewall Attack in Real Time
I was involved in an instance where I needed to stop an active attack on an organization. The bad guys had gotten on the network, and they were actively running scripts on the network, because the organization’s firewall rules weren’t locked down. The bad guys were able to open up connections back to their country of origin and start exfiltrating data outbound from the organization across a port and destination of their choosing.
One of the server administrators just happened to be standing in front of the monitor and saw things happening on the screen that they weren’t doing. It was as if the system were possessed. It was literally just luck that they discovered it.
They contacted me to help provide some guidance to resolve the issue. We were able to lock down the system and fix the immediate issue quickly, and then implemented an entire security and compliance program so that they could manage their environment more effectively.
Thankfully, the data the bad actors had gotten access to wasn’t sensitive data — it was from a test system. But if the attack hadn’t been discovered when it was, I have no doubt that the organization’s most sensitive data would have been compromised. They dodged a bullet that day.
Are you trusting to chance that your firewall is properly configured to effectively protect your organization? Most of our clients need help improving their firewall maintenance. Chances are, your company has gaps, too.
Let’s go through best practices to keep your firewall rules properly pruned for better risk mitigation against attack. These tips are simply the things you need to do with your firewall rules to better protect against bad actors. We’re assuming that you’re properly configuring the firewall itself, and performing regular system maintenance and patching.
The Basic Process for Pruning your Firewall Rules
The process for reviewing your firewall rules is straightforward and simple, but it takes thoughtfulness and attention to detail. Here it is, in a nutshell:
- Document all of your firewall rules.
- Write justifications for each rule.
- Evaluate each rule based on the justification.
- Update your documentation.
- Review again in six months.
Of course, there’s more to it than that. Let’s get into the nitty gritty.
Document Your Firewall Rules
The first thing you need to do is document all of your firewall rules. With a firewall, each individual rule effectively says, “I’ll accept traffic going from here to there, and I’m going to accept it on X port.” When you go in and write a firewall rule, you need to be very specific. For example, allow TCP port X to be able to communicate from here to there.
Write your rules in a separate document, outside of the firewall. A lot of organizations fail to do this, because the rules are already in the firewall itself. Why double the documentation if you can just look at the source itself?
Let’s say it’s December 31, you’ve just signed your documentation and you’re compliant with PCI. Fast forward six months. PCI requires semi-annual reviews of the firewall rule set. When you do that, you pull up documentation from six months ago. This is a record of what the rules looked like six months ago, and it allows you to compare them to what the rules look like today. Without that historical record outside of the firewall, you have no firm idea what changed in the last six months.
Let’s say there are two new rules that show up in the firewall rule set. You can take a look at those two rules and say, “How did they get here? Did they get here through a justified change control process?” In the one case, yes it did. In the other case, it was an experiment that one of your vendors was doing to try to get something to work. They didn’t bother making the change through change control as they were supposed to, and they just manually made the change straight to the firewall, forgetting to remove it after testing.
Separate documentation lets you catch those things, because you can see every deviation and ensure you’ve got justification through change control. If it isn’t there, it raises a red flag and you know to investigate what happened, retrain internal personnel or vendors, and make improvements so it doesn’t happen in the future.
Some firewall manufacturers control and report on firewall changes in an unalterable internal log for such reporting. However, you have to have a keen eye for reviewing the capabilities to depend on that as a source of record. Generally it’s quicker to document offline, and it’s certainly safer in the short run. You can always make improvements to the process, later.
A Word About Change Control
Any changes to a firewall must be done through a change control process. Any deviations should be investigated and resolved. It’s rare to find bad guys getting hold of the firewall — usually it’s an internal breakdown of processes.
That may seem benign, but it’s actually quite scary. Over time, your rules are getting worse and worse, and you have less and less control over the firewall. If an attack does occur, you’ll have a much tougher time finding it. I have seen successful attacks on firewalls, and they do happen daily in the U.S.
Don’t Neglect Outbound Rules
The firewall controls both inbound and outbound traffic. A lot of people spend all their time on the inbound rules to the environment, but they spend very little time on the outbound rules.
Outbound rules are just as important as the inbound rules. They control all the traffic that leaves your environment. A lot of organizations default to a less restrictive policy — they allow anyone on the network to go wherever they want. That’s a mistake.
If an attacker gets onto the network — and there are a myriad of ways they can get there — now they’re sitting on your internal network, and your outbound firewall rules will let them do whatever they want, wherever they want. They can go to an open port to a foreign country and start exfiltrating data.
Consider the real outbound needs of your organization, and lock down the outbound ports as best you can.
What Are Rule Justifications and How Do You Write Them?
Besides recording what each rule currently is, it’s important to explain WHYyou have the firewall rule in place. When you justify a rule, you aren’t documenting what it’s doing — for example, allowing web traffic from the internet to come to the web server — you’re documenting why you have it. For example, allowing the web traffic to go to your externally facing web server that allows your clients to do X or Y.
The justification gives the business case for why the rule exists, not what is the rule doing.
Why do you need to write a justification for each rule? Your firewall may be four years old, but three and a half years ago, somebody was trying to get something to work right. They stuck a test rule in there, completely forgot that they put it in there, and it’s still there today. The justification will tell you immediately why it’s there, whether it should be there, and that you can remove the rule without concern.
Justification forces you to consider the question: Why do I have this rule? What is the purpose that this rule is supposed to be serving? It also forces you to review the rule itself and ask if it’s achieving the objective that you stated in the business purpose. Have you limited it appropriately, based on the description that you gave?
Evaluating the Rules and Justifications
You don’t want firewall rules that you don’t need. Do an audit of your firewall rules and justifications. If you find rules that don’t have justifiable reasons for being there, do some testing and validation, then you can eliminate them if they truly aren’t needed. Or, you may discover justification to add the rules to the listing, because they should have been there all along.
There are some things you want to look for as you’re reviewing the rules themselves:
- Am I controlling the traffic?
- Am I justifying the traffic?
- Am I setting the rules up appropriately?
That review process is kind of an iterative process. Go through, do a review, poke some holes in it, ask some questions. Go back, document the rules again. Rinse and repeat.
One of the challenges of locking down your firewall rules is that you might get too restrictive and traffic isn’t flowing the way that’s needed to support the business. So it takes a bit of iteration to find the right balance. But once you get through that process, you’re a lot better off than when you started.
Should You “Allow All”?
One of the things I key in on when I’m helping direct a company is looking for any time a rule is set to “Allow All.” Allow All could be used to enable IP addresses from anywhere on the internet to travel inbound on all ports. It’s unlikely (but possible) that you really need to allow traffic from everywhere. There’s probably some lockdown that you can do on that particular firewall rule to tighten it up. The tighter the rules, the less traffic you’re letting through and thus the less opportunity for attackers to get into your systems.
There may be the opportunity to lock down by geographic locations, so if your organization serves exclusively U.S.-based companies and your clients have a presence in two other countries, you may be able to lock down access from certain countries that are deemed unnecessary.
Similarly, you could lock down the ports. If the rule is supposed to allow only secured web traffic, then you can lock it down to TCP 443 instead of having all ports open.
Should You “Deny All”?
Let’s say you have five rules in your firewall. When traffic tries to come in, the firewall will bounce it up against rule 1, 2, 3, 4, and 5. When it gets to the end of the fifth rule, if traffic still isn’t allowed to get through (based on the nature of the traffic against the defined rules), the final thing you want to happen is to deny everything else. The sixth rule is Deny All.
In other words, you want to fail the rule set closed, not fail it open. This means that if you don’t get justified traffic on one of the first five rules, then the request is denied. That’s what should be happening, because it’s choosing the safer of the two options.
With some of the hardware (or software-based firewalls), the Deny All function is written into the device itself automatically (and often in the background). So it’s important to look at your hardware and determine if you have an explicit or implicit Deny All rule. Then you can condition the rule set appropriately.
Don’t Forget About Unencrypted Ports
Certain protocols deliberately pass traffic unencrypted. Unencrypted (http) traffic typically travels on port 80 and encrypted (https) traffic typically travels on port 443. If you have a valid certification on a 443 connection (and the host is configured correctly), then your traffic is encrypted from end to end. Port 80 doesn’t require a certification and it doesn’t encrypt the traffic.
When you’re evaluating your rules, think about the use case for any traffic that’s on port 80. If you’re just serving your company website’s home page, or immediately redirecting port 80 traffic to port 443, that’s fine. But if you’re trying to serve sensitive information from a website back to the client’s browser — for example, a signup form or an online checkout — you want that traveling on port 443.
So part of the review process isn’t just looking at what ports are being used, but if they’re appropriate for the type of information that will be traveling on those ports. Certain ports are inherently insecure, so anything on port 80 should immediately draw your attention.
Make Firewall Pruning Manageable
Pruning firewall rules isn’t a quick task that you can just breeze through. It takes a good amount of thought, introspection, looking at the rules, and looking at the use cases within the organization to determine whether or not the firewall rules are appropriate.
Too many organizations don’t get down to the details, line by line. Many companies also struggle with managing the cyclical events that need to occur. TCT Portal was designed to make both of those challenges simpler and more manageable.
