If you’ve ever been involved with administering firewalls, you may agree that one of the most tedious tasks facing firewall engineers is locking down firewall rulesets after a new firewall or firewall interface has been deployed on the network. In a utopian world, organizations would have a list of well-documented and approved network connections that are needed for their information systems to properly function. The firewall engineer would then take this list, translate it into firewall access control lists or rulesets, and complete the job by denying and logging any traffic that is not explicitly approved by the organization. In the real world, however, this principle is seldom put into practice for various reasons, including:
- Deploying a firewall with a “deny-all-by-default” policy could potentially stop legitimate traffic and therefore cause serious business disruption
- Information system owners do not always know the communication requirements of information systems for which they are responsible and, as a result, request for a large number of ports and protocols to be opened to prevent their information systems from failing
This leaves firewall engineers with no choice but to deploy new firewalls using an “allow-all-by-default” approach to reduce the likelihood of disrupting business operations. The problem with this approach is that firewalls which are deployed in this manner are rarely fixed; the amount of effort that it takes to lock down a firewall’s rulesets after it has been deployed to production and has been processing live traffic for a while is immeasurable.
Some would argue that the process to lock down a firewall is a fairly straightforward one: you collect the firewall’s access logs, analyze the logs line by line, determine if the traffic should be allowed or denied, and then write appropriate rulesets that will either allow or deny such traffic. Easy enough, right? Well, yes, for non-critical firewalls or firewalls that protect a small number of information systems (less than 5, maybe?) But the complexity increases with the number of information systems that are behind the firewall: the more information systems behind the firewall, the more complex it is to lock the firewall down. Add to this, there are business processes that only occur quarterly or even bi-annually, which means that if the information systems that support such processes are behind the firewall in question, then the firewall engineer would need to collect and analyze at least three to six months’ worth of firewall access logs to account for the rulesets that would support these critical business processes.
Let's revert to the firewall lockdown process described above. The first step in the process would require the firewall engineer to retrieve the firewall logs from the organization’s centralized logging server. Depending on the volume of traffic processed by the firewall, three to six months’ worth of logs could easily translate into gigabytes or even terabytes of data. Downloading this data from the centralized logging server should not be a problem since most commercial centralized logging products are designed to export large volumes of logs in CSV format. But engineers will most likely face the first challenge when attempting to open large CSV files on their computers. Most engineers will default to using Microsoft Excel to analyze CSV files since the software is readily available in most organizations’ end-user computing devices. But if the CSV file is too large, the engineer’s computer might crash before Excel can open the file. Even if the engineer has a super-powerful computer with enough memory and system resources to open the file, Microsoft Excel is only able to handle ~1 million rows of data. In addition, its auto-filter feature is hard-wired to display 1000 unique items in a column. This adds a significant burden as the engineer would now need to figure out how to do some complex filtering to begin analyzing the data (and we haven’t even gotten to the second step of the process: analyzing the data).
With Gigasheet, we can easily alleviate the pain of opening large, multi-million row spreadsheets by leveraging the power, elasticity, and scalability of the cloud to enable analysis of spreadsheets containing billions of cells of data. Simply download your CSV file from your organization's centralized logging server, save it to your hard drive or upload it to your organization’s approved cloud storage solution, open it with Gigasheet, and begin analyzing your data without unnecessary delays or complexities.
Stay tuned for my next blog where we will show you how you can use Gigasheet to more easily and effectively analyze firewall log data.
Continue Reading: Firewall Lockdown Part 2 - The Nightmare Continues
The ease of a spreadsheet with the power of a database, at cloud scale.
