Firewall Rule Audits or Approvals - Learning Resource?

[George_Ellis]

Has anyone found a good guide/book/publication to help teach junior analysts/engineers about reviewing firewall changes or auditing rules?  I know there is about nothing that teaches folks on how to do remediation of rules.  Nice of PCI-DSS to demand it, but provide nothing to help support their review cycle.  I have an internal document where I show how to use our tools to do it, but that fundamentals doc on what are good rules and what righteously sucks seems to be elusive.  "PCI auditors" just go by bad protocols and too many addresses, but don't actually understand why. 

So if anyone has any insight into a resource to help with why a firewall rule is good or bad, that would greatly be appreciated.

George

[G_W_Albrecht]

sk98348: Best Practices - Security Gateway Performance

[George_Ellis]

Thanks.  Yes, great for someone to support Check Point at level 2 and 3, but it does not address teaching what is a rule that applies for common network rules.

[Tal_Paz-Fridman]

Hi

You should also here:

Check Point for Beginners

https://community.checkpoint.com/t5/Check-Point-for-Beginners-2-0/bg-p/check-point-for-beginners-2-0...

https://community.checkpoint.com/t5/custom/page/page-id/CommunityBeginnersChild?cat=2

BR

Tal

[George_Ellis]

Great for someone to support Check Point devices and applications.  But they really don't go deep into common usage.

[the_rock]

I think you got 2 excellent responses.

[Ruan_Kotze]

For what it's worth - I'm a PCI-DSS ISA and have helped a couple of orgs with remediation and compliance efforts.  PCI Req. 1.1.7 deals with ruleset reviews and it's as much a process requirement as a technical one, so it's important to keep that in mind.

One can really go deep into the weeds here, and no doubt you have vendors pushing toolsets which will claim to solve your problem with one click of a button but in my opinion the point of origin and the answer to your question "why is a firewall rule good or bad" is simple - is there a documented business justification for the rule?

If the justification for every rule is documented and backed up by CAB minutes which includes risk and impact assessment you'll have a much easier journey with your auditors.  There will always be edge cases, like a legacy system supporting only telnet or SSLv3 or this or that, but for that you create a compensating control and move on with your life.

Something that I always recommend my clients do to help ease the review process, is to put the change request nr. in the rule description, and that CR in turn links back to the CMDB system.

[Chris_Atkinson]

Agreed the job is infinitely harder without documentation & context.

Compliance blade & SmartOptimize can help, at a high level the basis of these is regulatory & cleanliness.

[George_Ellis]

If you don't understand the traffic, you don't know if it should be justified and who it might be.  PCI-DSS demands a rule must have a comment.  This is and everything else is accounting.  Accounting does not explain the traffic.  PCI-DSS focuses on accounting and not enterprise life.  A rule may have business justification, but there could be other traffic piggy-backing on it that needs its own justification or to be stopped.

So, you have multi-domain enterprise AD.  How does a person recognize a rule request, the business justification for the components, etc.?  Shoot, even MS does not list all the ports used like 464/TCP for Apple Kerberos.  So in the audit portion of a rule request, the approver has the business justification right there in front of them, but the AD requests includes 1433/TCP.  A newer person does not realize that that is an SQL connection request in it.