When, for a vulnerability assessment, you need to report the security consideration about a firewall's configuration rule-set, after the audit on the rule-set you make a report about security concerns on the rule analyzed.

In this report, you need to write what is wrong in the rule-set and the security consideration about the configuration.

For example, if in the rules you have not find egress filtering you can say it's a problem because from your network is possible to do spoofing.

What sources do you use to add credibility and customer satisfaction to your work after an audit and a report of this kind ?

What reliable sources, best practice, etc .. do you use to arguments your consideration to show to your client that this consideration is not your own consideration by a widely accepted consideration in the security industry ?

  • 1
    Could you clarify this a bit? I'm really not sure exactly what the question is here.
    – Iszi
    Mar 25 '11 at 13:14
  • @lszi: added more info, is it ok now ?
    – boos
    Mar 25 '11 at 13:30
  • Very good, thanks. Was originally considering a close-vote, but now you get an up-vote. :-)
    – Iszi
    Mar 25 '11 at 14:18

You may consider employing the results of a third party firewall assessment tool to give you the extra persuasion muscle.

Nipper is relatively cheap and works: http://www.titania.co.uk/index.php?option=com_content&view=article&id=48&Itemid=59

Nipper [...] perform your own comprehensive security audit of your own network switches, routers and firewalls without requiring any specialist security expertise.

There are several other firewall assessment tools, but they get pricey quick.

Check out the benchmarks templates available here the Center for Internet Security. For example: http://www.cisecurity.org/tools2/cisco/CIS_Cisco_Firewall_Benchmark_v2.0.pdf
Lots of excellent information and copy ready for your report writing.

Note: Nessus has many of the CIS templates codified in Nessus audit files so you can quickly run a Nessus scan to compare a device configuration to a CIS benchmark.


I've never felt that I needed to legitimize my reviews of firewalls with some call to a "higher power". While I have had clients come back with responses like, "Show me where it says I can't have the wire transfer application on a shared laptop that's used for webcast presentations," firewalls are a bit easier to justify. The rule is: Anything that isn't legitimately required is a risk, and your increased expense to mitigate this risk is negligible as all you are doing is adding a rule to your existing firewall system. Your cost to do it is less than your cost to argue with me ;)

In any case, unexpected traffic is either a misconfiguration or a compromise. If I need to justify every rule on its own without that principal, why do you (as my client) have a firewall in the first place?

I'm starting to think I'll ingrain in people that they should start with a Fort Knox system and peel off what is too expensive for the benefit rather than start with an patch of grass and start building walls as they see fit. When I start that, I'll cite this question (and you get a +1 on it).

  • Say to a customer: "I have experience enough to say it", it's not my goal. My focus point is to add customer satisfaction referencing some thirty party and 'higher power' organization.
    – boos
    Mar 29 '11 at 13:33
  • It's not a question of justifying experience. It's a simple code of security. Some very simple and basic concepts are hard to cite, and I think that's one of them. I can find a few places that tell me to add an explicit deny at the bottom of a ruleset, but that doesn't help if a client decides the rule before that says anything outbound is ok. That's not a human issue that I've been able to cleanly solve.
    – Jeff Ferland
    Mar 29 '11 at 14:38

An approach I always try to persuade people to use, as it is backed up by a vast array of security guidance and publications, is to start with a firewall with no holes through it and get the business to justify each and every port.

Their justification should be "for application x, we require connection from source port y to destination port z outbound" and could include a review date, test case etc. Security should inform them of the implications of high risk ports, and not allow them to request "any any allow" type rules.

This then makes your job much easier, as you then review the firewall against the list of business required ports. Any extra holes should be blocked until business justification is provided and signed off.

  • 1
    +1, also within the firewall policy itself, each rule should be tagged with a comment including a ticket number of the request from the business, which includes the justification, approval chain, review date, and testing documentation. Mar 31 '11 at 2:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.