Test of IT infrastructure – the firewall

First draft of my post: So you have to test (or check) a firewall in a new or existing it-infrastructure?



The beginning

This question is what the test approach should be and this can partly be clarified if you can answer the following questions:

Is it a test of the firewall product? Is so then plan a test as you would for any other software product based on requirements, design, risks, etc. Because basically a firewall is a server running a OS and a application with some management interface. This test approach is out of scope for this post.

Is the firewall a part of a for example an enterprise infrastructure? Is so then plan a test that explores the firewall customization to the it-infrastructure that it is a part of. This test is what is described in the rest of this post.

Now, as a basic assumption for the test approach I assume that the firewall product is reliable and stable is operation. I know “assumptions is the mother of all fuck-ups”, however this is a risk I take at this stage. It will be at the top of my list of risks.

Test basis

You need to clarify your test basis or what information needs to be available in order to test the firewall.

There should always be a design outline for the firewall in terms of a specification produced by a architect or design engineer containing information about installation and configuration of the firewall. In this specification there should be information about:

Purpose of the firewall; is it an internal firewall in the infrastructure or does it sit between the infrastructure and the Internet or business partners.

Where is the firewall located in the infrastructure and what are the interfaces; how many are there.

Physical setup; properties on NIC’s, connection to network switches, power supply, is it in a redundant setup (two or more firewalls working as one).

Configuration of the firewall; IP subnets, port numbers, vlans, access control lists, rules.

You need to be aware of how the configuration of rules are described. They must be uniquely identifiable since the design description of firewall rules and the way the are coded in the firewall are usually done in different ways. The design description is made for humans to understand, the code for the firewall to understand.

One very important thing to be aware of is that the firewall design description must be reviewed  – not be testers but somebody who know about designing it-infrastructure and firewalls. As a good tester you ask whether review has been performed and that the design description has been approved.

Installation test

This is the physical installation of the firewall hardware and installation of OS and applications. Also connections to network switches that connects to rest of the it-infrastructure.

Use check lists – this is usually a one time activity. But it needs to be correct otherwise the rest of the testing activities will show all kinds of problems.

Component test

Configuration specification review needs to be performed before the firewall rules is coded into the firewall application. The Configuration specification is what is included in the Change (ITIL expression) or work order for the technician and this is what will be coded.

Perform a code review line by line of the firewall configuration after coding has been completed by the technician. Usually it is possible to get at text file dump of the firewall configuration that can be compared directly to the configuration specification. Make sure that the technician has commented the code so you can identify the individual rules in the configuration.

Integrations test

A firewall allows data traffic from one device to another on the infrastructure or the firewall blocks the data traffic.

All firewall rules needs to be verified after coding. Some firewall rules can be verified simply be the use of two PC’s placed in dirrerent locations on the infrastructure. Other firewall rules can not easily be verified unless you run the applications the rules are intended for.

Just make sure that the test scope contains allowed data traffic as well as blocked data traffic.

Non-functional tests

In my opinion security testing, penetration testing, performance testing, etc. on the firewall alone does not make much sense unless you are testing the firewall as a product. These tests must be performed on the complete setup; infrastructure including firewall and applications used on the infrastructure. However a perfomance test of the firewall can make sense since all data traffic between the secured areas of the infrastructure will pass through the firewall rules. Therefore CPU, memory and NIC’s of the firewall can at times come under heavy load from data traffic.

Operation and maintenance

During operation and maintenance of the firewall rules maybe changed or new rules added. Also OS, firewall application, and management software will frequently be updated.

Changes in firewall rules should always undergo code reviews other than that a risk-based test approach can be applied for testing changes to the firewall in operation.