At Arctic Security, we enjoy hearing stories from our customers about their experience with our products and services. An increasingly common theme that has emerged from these dialogues is the topic of firewalls, and how Arctic EWS has revealed certain weaknesses in the firewall infrastructures of our customers.
There is often the assumption that if firewall infrastructure is present, then it has been designed and implemented correctly and everything is safe on that front – an illusion that normally doesn’t break until proven otherwise in a very concrete way. And while the evidence for addressing this almost always needs to come from the outside, many organizations don’t have a way of systematically gathering the external information that would help to expose these previously invisible issues.
So, once you do start to receive external information about your security issues, what kind of findings can you expect?
Your firewall rule management has exposed services
You might find that the process you have in place for firewall rule management is not working as it should, thereby unintentionally exposing services. One customer recently told us that in the first two months after they subscribed, their review of their firewall rules led to them eliminating 1,600 unnecessary or invalid rules. Even after shaking off years of accumulated crud, their work to prune more of their rules is still ongoing.
Your firewall rules aren’t blocking external access
In another case, a subscriber was puzzled as to why Arctic EWS notified them about one of their core services. To their best knowledge, the service was firewalled and only accessible via a handful of permitted hosts from their intranet. It turned out that the firewall was indeed properly configured internally. Still, the firewall rules didn’t block external access to the service from the internet. Unless you have a checklist item for verifying the rule from an external position, these kinds of mishaps can be tricky to catch. Once the mistake becomes part of everyday use, you are unlikely to notice it – unless a dedicated service like Arctic EWS reveals it.
Services you thought were blocked actually aren’t
You might find that firewall infrastructure set up by a certain vendor is not configured the way you thought it was. One of our subscribers was surprised by our results, when it turned out that services they had assumed were blocked were not. When the subscriber requested information from their firewall vendor, the vendor explained why those rules were present, but, unfortunately for the client, they had not shared that information with the security staff. This led to two different but co-existing opinions on what was allowed through the firewall. And, as more services get outsourced to third-party vendors, scenarios like this will become more frequent.
You haven’t vetted incoming firewall requests
Issues can arise when your security team doesn’t have sufficient resources to evaluate all of your incoming firewall rule requests thoroughly. In this situation, you can reduce your rule management overhead by splitting rules into different categories. One of our customers explained that this approach significantly reduces their workload since they manage high volumes of firewall rule change requests at their organization. You could also implement data policy-based pre-approved rules to manage them better, or, if a service is only using public data, the requester can go ahead and deploy a pre-approved rule. Otherwise, the rule change must go through a security checklist and review before adding it as a new rule.
You have forgotten to review expired rules
Even when you abandon certain rules or create exceptions for them for good purposes, you might forget to remove them when services expire, which can provide unexpected access points to your services from the internet. Over the course of the asset lifecycle, they may get reassigned and moved around. If you re-use or re-assign an IP address, especially in a large or virtual/cloud environment, it could still have the rule set for a previous device or virtual machine in place. And maybe the new device or virtual machine isn't supposed to host internet visitors.
You could therefore end up with a newly provisioned system with pre-existing rules still in place from a different time. In organizations where infrastructure is decentralized (i.e. with remote IT teams), the centralized security team can often lack the necessary access and visibility on the IT operations side. And yet, there is an expectation for the security team to contribute. But how is it supposed to review rules and provide guidance if it doesn’t have guidance itself?
So, what can you do to maintain visibility over your firewall infrastructure?
Firewalls are necessary, but the above examples show how poor visibility leads to unexpected situations and compromised security postures. So, in the face of such complex IT environments, what can you do to maintain visibility?
There are several answers to the question. You can often mitigate the reported issues with better rule management processes and external monitoring. It’s good practice to schedule meetings between the security and IT sides of your organization so that both sides stay up to date on the intentions and actions of the other. Some of our customers have improved their situation by simply improving collaboration. Communication is essential for decentralized organizations and can have an enormous impact on your security posture.
It is also prudent to have a system where all firewall rules related to a system are reviewed periodically. Otherwise, unless you do systematic external scanning, outdated rules can sneak in unnoticed. Without pruning firewall rules systematically, eventually more rules are added than removed, and the management of the rules becomes untenable simply due to mass. Maintaining a minimum set of rules is practical for operating efficiency in the long run.
Traditional approaches also include arranging scheduled penetration tests for your network, with network scanning being a part of the service. These scans can be comprehensive, although it can also be quite expensive to arrange them frequently. Annual or semi-annual scans are the norm. The downside is that a lot can happen between those reviews because very few IT environments stay static for such a long period.
Arctic EWS – an early warning service for your security issues
The practices outlined above are brilliant when they work. But it’s smart to have a safety net under you to catch inevitable mistakes. This is where Arctic Security shines – with our early warning service, Arctic EWS.
Arctic EWS monitors your network assets continuously and provides timely notifications as and when significant issues arise. We look out for common vulnerabilities and problems that should have been fixed long ago but were overlooked. You might be surprised by the sheer number of old vulnerabilities that still plague organizations even years after a fix has been available. Is your firewall exposing an internal system that was not correctly patched? Arctic EWS enables you to find out the answer to that question.
We continuously add new and notable vulnerabilities to our watch list as they get reported. For example, Arctic EWS promptly notified our subscribers when the Microsoft Exchange vulnerabilities became public in March of 2021. We sent warnings a few days before the widespread exploitation attempts for those vulnerabilities started, giving the recipient time to act. One of our customers had already migrated away from their onsite Exchange deployment. However, it was still connected to the internet. According to Microsoft’s best practices, it was customary to leave it there. Still, the new vulnerabilities suddenly turned that installation into an acute attack vector. Since it was unnecessary to offer that service publicly, they could restrict external access after being notified.
Even for those customers who perform periodic external scans, penetration tests, and so on, our reports have exposed issues that are new to them. But for all of our customers, receiving practical notifications has been a significant step towards more systematic vulnerability management.