I regularly get questions regarding firewalls and network layer security strategy overall. I wrote this article to share those answers with a larger audience.

Baseline understanding of hardware firewalls

I have spent over 50,000 hours of my life programming network layer security appliances. I do not use the term hardware firewall anymore because stateful packet inspection with ACL management is only a minor portion of what a network layer security appliance does. Just like I do not use the term antivirus anymore because it does not reflect what modern zero trust threat protection platforms need to do for endpoint security to be effective. The term firewall also does not convey the inclusion of mandatory features such as application control, IDS/IPS, DNS filtering, geoblocking, and a host of other necessary security features. Firewall itself has not been adequate for a very long time, and in the last two years every cybersecurity insurance application I have seen is requiring IPS at the network layer.

That point being established, there are those who think that network layer security appliances are no longer required. They are approaching netsec from an endpoint agent paradigm such as you see in the SASE market. I differ in opinion. SASE solutions are financially prohibitive and lack comparable features with what can be done with much more mature network layer security appliances in the hands of adequately skilled personnel. You can achieve incredible scale for significantly less money with a net sec hardware appliance. I would prefer to use an always on VPN agent backhauled to a real network layer security appliance over SASE agents.

Netsec appliances can secure network traffic on an agentless basis. That means security extended to devices that cannot have an agent installed such as phones, surveillance cameras, door controllers, wireless access points, and IoT sensors. There is no software agent to manage, patch, or verify that it is still working. It is a lot harder to defeat a hardware appliance that has a completely hardened control plane compared with defeating a software agent on an endpoint.

Challenges with brand/model selection

I start with efficacy and total cost of ownership. NSS Labs and other independent testing firms have tested network layer security appliances for years. Over the last ten years in the range of appliances which are not financial unobtanium for the SMB market, WatchGuard has consistently shone. An appliance that scores less than 98% in security efficacy fails the basic requirement of a net sec appliance. Then one must look at TCO which includes secure and proactive configuration management, updates, and monitoring.

Another very key factor is how the net sec appliance fits into one’s overall cybersecurity kill chain paradigm. Is there an opportunity to have a single manufacturer for wireless, netsec appliance, and endpoint? If so, do they offer a closed SOAR for little to no additional cost? Having converged visibility into what is going on in terms of threat intelligence is of significant value. That could eliminate the need to have another product or subscription and thereby reduce TCO. The totality of the positive impact on overall security posture absolutely must be evaluated rather than simply evaluating a netsec appliance alone.

Does the manufacturer offer training and certifications? Acquisition cost does not really bother me, but burden rate or TCO does. What kind of support is provided by the manufacturer? Does the manufacturer actually want partners in the SMB/MSP channel?

Is it possible to run the appliances without a cloud controller connection? Can stacked templates be used to efficiently manage secure configurations at scale? How easy is the configuration to audit in order to identify misconfigurations? How easy is it to export the configuration to a human readable format for third party audits, insurance attestations, or other compliance validations without allowing that external party access to the management interface?

Appliance sizing and model selection is largely an art form based upon experience. A person can call up internal sales at a netsec appliance manufacturer and get completely wrong answers about what device model should be used in what context. This is not the manufacturer’s fault. Appliance model selection and sizing is highly dependent on the design and architecture of the new underlying network, what the appliance will be expected to do, and the load demands put upon it based upon how it is programmed. Therefore the only valid source for appliance sizing is the engineering firm that will provide the long-term support for the device.

Challenges with implementation

The primary challenge with implementation is lack of experience of the implementer. I have personally done over 300 network rearchitecture projects. Because of that experience, I can go into a site with a secure, hardened configuration. Most people do not take that approach. They try to bring security hardening in after the implementation. A major failure in approach is when the business leadership is asked what kind of security they want. The result of that approach is that they are laden with fear about how they will not be able to access the websites they want to access and when. The uncertainty provokes fear which prevents the project from going anywhere and it is likely that the implementation will never occur.

In contrast, my approach is that I seek to understand the client. Having so much experience, I am able to quickly identify a baseline configuration template from our repertoire of configurations that best matches where we should start for that new client. We then customize the configuration and take it onsite for installation. Assets are then migrated over a period of hours, days, or weeks depending on the size of the environment. One cannot go in and just gut an existing network. A migration path of keeping the old assets on the old VLANs at initial implementation is required. Then those assets are moved one by one. This allows for change control, asset inventory development, and a general good cyberhygiene for each of the migrated assets. I have used this approach hundreds of times with great success.

The network documentation is easy to build out with this granular non-nuclear approach. But I would never run an old and new netsec appliance in parallel. There must be a hard cutover to the new appliance. The accommodation of the old configuration is riding on a VLAN or few which we call the “old LANs”. Those are programmed into the new appliance for the purpose of cutover, and the “old LANs” are decommissioned when all assets on the old subnets are migrated. With this approach, any leftover assets that are hiding will be revealed. I have found assets up in a ceiling that no one knew about, but they were still chatting on the network. It goes without saying that this approach must be combined by delivering the new VLANs to the rest of the network. Generally, that means the implementation of capable switching equipment at the same time since I have yet to ever see an organization in 30 years have adequate switching equipment when their network layer security was insufficient.

Advances in netsec appliance technology

The most valuable advances in technology in netsec appliances in the last 16 years have been the addition of more security features, more horsepower for not very much more expense, better purpose‑built logging, analytics, dashboards, reporting, and search tools for historical traffic. Built-in SD‑WAN has been a huge benefit. In 2011, WatchGuard introduced a feature called autoblocking which eliminated DDoS attacks in virtually all cases. Something like that (properly employed) eliminates the need to pay for or manage an upstream provider such as the ISP to filter that traffic. Having to call the ISP in order to get something accomplished that you could have done yourself just made the TCO go higher. This is another reason I will never understand the desire by some businesses to hire the ISP to manage their edge and wireless security. The ISP cannot provide the kind of service that a full security MSP can, and the ISP will never manage the internal network security. What kind of threat intelligence exists if visibility into the security control plane is spread out across different providers?

I am not enamored with cloud managed netsec appliances. The netsec appliance creates the network. What if WAN DNS is down? If the internet connection must exist in order to manage the entirety of the netsec appliance because it has no full local management option, I consider that a hazard. One must carefully consider all BCDR scenarios when choosing to use cloud-only or cloud-primary management.