Scary stories to tell in the network

With Halloween right around the corner, here’s a real-world firewall politics horror story. (For effect, feel free to imagine it with a scary, hoarse warning voice… or Morgan Freeman if you prefer..)

As a Sales Engineer, I spend many days demonstrating our products, talking to security engineers, compliance officers, DevOps managers, and RSSIs about firewall and network security. Sometimes the stories of the people in the trenches are incredible and sometimes downright scary. Here is a recent story from a customer who will keep every firewall engineer awake at night.

Scenario:
The company had recently adopted a “zero trust”And had invested a lot of time to get closer to this goal. Over the past year, they have focused on clean up their firewall policies by writing rules specific to the needs of the business – nothing more – just the specific IP addresses and networks that needed access. They were making progress when one of their engineers made a horrible discovery, a dreadful “All – All – All – Accept”Rule buried in the middle of politics.

They struggled to understand why this rule existed. They eventually found out that a junior network engineer, just trying to get something to work, had created this rule. This one rule bypassed any progress they had made towards their goal of zero trust and put the network at enormous risk.

Obviously, the rule had to be removed. But this rule had been in policy – undetected – for at least 6 months and certainly allowed critical traffic for the business. In fact, newspaper traffic indicated that this was an extremely busy rule. Of course, this probably allowed more than just business-critical traffic, but also malicious traffic. They needed to fix this problem quickly.

First, they had meetings with people on the network and figured out what some of the traffic might be, thinking about critical applications and traffic that those who knew the network knew they could use this rule for. But eventually, they decided they just needed to bite the bullet, drop the ruler, and see who was screaming.

Thus, they informed the managers of all business units of this error. Embarrassingly, they said that there was going to be a “hotline” with the operators on standby, and that ultimately people had to test all the critical functions to make sure their products, their applications, everything. what they needed had access to do their jobs and allow their customers / partners / suppliers / to do business with them would only go down until they could put things in place. Yes things did go, and yes they were set up to try and create new rules to fix the issues, but what a nightmare.

Maybe you don’t have a nightmare scenario like I described above, but FireMon can still make it easier for you by helping you clean up your firewall policies. Here are some ways FireMon could prevent the above scenario. And, if you ever discover a scary too permissive rule in your policy, be sure to look at number 6 below for a painless solution to the problem.

1) Alerts and Compliance Reports:
We would have informed the team immediately if a rule was too permissive like this. You can basically “set the dial” on how you want permissive rules, such as “Rules allowing access to over 60,000 destinations” or “Rules with sources larger than a / 16 network”.

2) Change alert:
This rule would be listed in our normalized view – regardless of the firewall vendor – and clearly seen that it was added. So he couldn’t be a “snack-in”. Some engineers and managers automatically receive policy change reports by email every time a change is made, or even a 30-day snapshot of anything that has changed.

3) With our automation tool, FireMon Strategy Planner, in place – that would have stopped the risky rule in its tracks – before it was even pushed. Using our ‘pre-change analysis’, the rule would have been identified and reported before being passed to production to allow even a bundle of traffic to pass through it. That’s why compliance officers like that we not only recommend rules for authoring as needed, but like in a sandboxed environment, we run our compliance algorithms before we can automatically apply the rules. Some customers get Policy Planner JUST for these features and use our APIs to access them.

4) Plus, with change alerts, the team will know for sure who made what changes and when. So in this case, since this was a junior engineer, a manager or leader could have quickly filtered / sorted the changes that this user had made over the past week, or at least monthly, in order to see what kind of changes this user had made. It’s also something the compliance team could have looked at, or even the user.

5) From a documentation standpoint, FireMon may be the only source of truth for things like “who requested this, who owns the app, when was this rule last revised times, etc. So by filtering and sorting the rules with the rule documentation, this would also have been identified faster.

6) I saved the best for last. If you have a rule that is too permissive, for example if your predecessors had a different and more open / flexible rule-making policy than you, we have an easy way to clean up those rules. Using Traffic flow analysis our tool will look at each IP address that crosses the rule, breaking any / all / all into specific streams. You can export these feeds and create specific rules based on them.

The post office Scary stories to tell in the network appeared first on FireMon.

*** This is a Syndicated Security Bloggers Network blog by FireMon written by FireMon. Read the original post on: https://www.firemon.com/scary-stories-to-tell-in-the-network/


Source link

Leave a Reply

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