Whitepaper: Best Practices for Cybersecurity Firewall Rules Management by Advoqt

This deceivingly simple problem has been the root cause for many consulting engagements and continues to plague network security teams across the globe. Included in this article is information effectively address Firewall Rules Management (FRM) as part of Asset Management series and is a baseline to get FRM under control.

In 2019, as your enterprise experiences rapid growth, it is susceptible to network complexities and immature change management. This, in turn exposes the company to advanced external threats. This article provides an in-depth look into how you can effectively manage your network firewall.

Enterprise complexity and immature change management practices are a formidable combination for any security practitioner. Effectively managing Firewall Rules is emblematic of this challenge. Either because an organization has grown quickly or due to organizational turn-over, security professionals are often left to piece together why a decision was made, who made it, if those decisions are still relevant today, and the risk associated with the outcomes of that decision. In this document, we will guide you on how to take control of your Firewall Rules and lay the groundwork to eventually automate maintenance of this important Asset Management task.

Why do firewall rules need to be clean-up and maintained?

• Improper firewall configurations may lead to the possibility of unused or duplicated rules.
• Poor rule documentation from old firewall rules.
• Current network administrators fear of modifying undocumented old firewall rules.
• Old firewall rules that are not needed anymore.
• Creation of overly permissive rules

Challenges to analyzing firewall rules

1. Lack of documentation of IP address relationship with business applications:

Most companies will have an inventory of assets with server names and IP addresses, however when it comes to business applications, most companies are failing to have a relationship between servers and specific business applications. This situation leads to increased complexity when trying to identify who is responsible for traffic from a specific server. It’s recommended to have proper documentation of servers by each business application and the corresponding application owner and/or technical contact.

The best approach to this challenge is to assess the business, understand its operations and how technology integrates with it. Begin with extracting description information from domain controllers, vulnerability scanners, hypervisors, as well as get a list of authorized users so that you can identify the stakeholders of unknown servers.

2. Incomplete traffic logs

When dealing with firewall rules, one of the best ways to analyze if they are required is by looking at the firewall logs. In some cases, we can even look at the proxy or DNS logs to identify where, when, and how servers are communicating in your network. In some cases, the rules may not be logging traffic because the logs from the firewalls are incomplete due to a poor internal monitoring policy. This is very important to identify early into an analysis to avoid creating a false hypothesis of lack of traffic on the network. We want to make sure all network devices are collecting logs that can be used to determine if servers in the network are really active or not. Once this is happening, we need to allow our system to collect these logs for a period of time that would be safe, considering the type of business. Collecting logs for the past 30 days is ideal when performing an analysis, however some companies will keep unused rules for as long as 180 days to give room to those application that only communicate once every other month.

3. Lack of business data flow documentation

In some cases, both traffic and applications are correctly documented, however, only a few people in the company really understand how the application works. This leads to other issues, where the application owners can’t answer a simple question: “Does your application need internet access?”. The best approach here is to analyze the traffic of the applications for at least 45 days, to collect all destinations IP addresses, Countries, ISP, Reverse DNS, SSL Headers, and any information that might be useful for the business owner to identify if that communication makes sense or not. Also, consider that servers may look for application updates, security updates, etc.

When dealing with unknown traffic, one of the best indicators is to count the number of hosts in your network that would also connect to a given remote IP address. In most cases you will be able to identify cloud update services that are not really needed for your business application to work. In any case, a thorough analysis is necessary to determine if communication can be shut down or not.

What can you do to reduce the risk of unnecessary or weak firewall rules?

There are specific steps you should follow to keep your firewall rules as clean and secure as possible:

1. Do firewall cleanups once a month to determine if the rules are necessary or not, regardless of whether they are being used. Just because a rule is being used, it doesn’t mean it’s necessary.

2. Rules that contain “Any” in the SOURCE, DESTINATION or SERVICE fields should be replaced by more explicit rules.

3. Uncover and remove unused, duplicate or conflicting rules

4. Document rule changes and requestor information. This enhances firewall management and is important for regulatory compliance.

5. Analyze the traffic of the applications in detail to understand which ones are necessary and which ones are not, paying special attention to application that should be already decommissioned based on business decisions or business requirements:

a. In case of an expired rule, follow business procedures for determining whether or not access is still required before deleting it.

b. Contact the owner of the application to confirm if internet access for the application is necessary.

c. If the business owner of the application is not sure if internet access is necessary, the technical should be contacted to obtain the confirmation.

When performing a deep analysis, the challenge will be to organize the traffic by application owner. At Advoqt, we recommend the following data flow to generate this information:

This data flow allows us to visualize inputs with dashboards and prioritize the clean-up on the rules that are allowing the majority of the traffic or packet counts. Once we identify undocumented applications connecting to the internet, we apply the following workflow to remove unnecessary, undocumented, and/or permissive rules, as well as we document any other required rule that’s missing.

Advoqt recommends automated solutions to improve documentation on firewall rule provisioning. Although we often build custom solutions based on our client’s unique needs, below is the process we typically follow:

1. Build a web application that centralizes requests for new firewall rules and where requestors are mandated to supply the following information:

a. Personal Information (auto populated with user-authentication)

b. Details of the rule to be created

• IP addresses/Server names
• Ports/Application/Services
• Time-frame
• Related business application or responsible business unit

c. Explanation and/or documentation of why this rule is necessary

This application will also have the ability to see if the rule violates the corporate security policy. If the rule looks good, the request will go directly to the request management system and be assigned to the security officer to review and authorize the change. If the rule is not compliant with the corporate security policy, the requestor will have to follow business procedures to do an exception.

2. For already created rules, if there is an expiration date on the change, the program manager will contact the requestor (before the rule expires) via email to confirm if the rule is still needed. If the requestor confirms the need for the rule to keep working, the rule owner will use the above application to request for the rule to renew for the same period of time when it was created (days, months). If the rule is not needed, the rule is disabled and an alert is sent to the network team for the rule to be deleted.

Source: Firewall Rules Management Whitepaper by Advoqt, provides Consultation and Automation around Firewall Management and Cybersecurity Services.