Thats not uncommon to take more time to decide than it really should and it often ends up in a matter of taste anyway 🙂 First of all... PAN uses top-down first-match which gives that for performance reasons if you have two or more rules with similar content (as in your case with different usergroups), put the rule which you expect to have more hits before the other rules of similar content. But since PAN uses FPGA/ASICs to handle the traffic (aka dataplane) this will in reality have a minimal impact on the performance. I think however you might get an impact when it comes to user verification (because the dataplane must speak to the mgmtplane or something like that). Then you can use various "design guidelines" in order to how to construct your rules (and in which order to place them). If we start with security purposes (which after all is why you have a firewall in the first place) you can use a design something like: *) blacklists (denies) *) whitelists (allows) *) default deny (with logging, at least on session start but you might need on session end for debugging aswell) Example for above is if you wish to deny access to url-category malware but allow access to url-category newssite. Now... if you only use whitelist and a site is categorized as both newssite and malware at the same time this would be bad wouldnt it? So to fix this you place the stuff you wish to blacklist before the stuff you wish to whitelist. Then we have readiness. If you just have 3 security rules it doesnt really matter in which order they are placed... but if you have hundreds of these security rules you must start to "group" them somehow, or at least place them in such order to its easier to locate a specific rule (this will at the same time break the performance "optimization" which again doesnt matter that much since the performance "optimization" is limited anyway). PAN currently doesnt support security groups (grouping the security rules in the GUI) but this doesnt really matter if you decide to order your rules according to which dstzone they have. In this case it can be handy to be more strict and not combine different dstzone's in the same security rule. You will end up with more rules but at the same time easier to audit your own rules (start to combine your rules only if you hit the roof of how many security rules your device can handle). For example for each dstzone setup: *) blacklists (denies), dstzone=x *) whitelists (allows), dstzone=x *) default deny (with logging, see above), dstzone=x *) blacklists (denies), dstzone=y *) whitelists (allows), dstzone=y *) default deny (with logging, see above), dstzone=y This way you will construct (and place) the security rules per zone and also try to block any misconfigurations later on (in case you in the y-grouping suddently tries to enable traffic into x-grouping - of course this wont be foolproof if you do the other way around but still take care of 50% of the misconfigurations when it comes to allow traffic into zones you shouldnt). Regarding misconfigurations - avoiding combining rules can save you later on. Not uncommon that some people construct rules such as (to keep number of rules down or I dont know): src: 1.1.1.1, 2.2.2.2 dst: 1.1.1.1, 2.2.2.2 service: TCP1111, TCP2222 instead of: src: 1.1.1.1 dst: 2.2.2.2 service: TCP2222 src: 2.2.2.2 dst: 1.1.1.1 service: TCP1111 which of course ends up with to much open between the two hosts (or even worse networks) in case the combined version above is used. Also try to keep your security rules as detailed as possible (specially allows). If you for example wish to allow web-browsing but only for TCP80 then setup the service column to only allow TCP80 instead of "any", or at least use "default-application". So in your case I would set this up something like (given that you use one blacklist per group unless you use a global blacklist for all groups): Allow "app ping" dstzone any Allow "app dns" with service "TCP53_UDP53" dstzone "DNS" Deny any dstzone "DNS" (log on session start) Allow "app smtp" with service "TCP25" dstzone "SMTP" Deny any dstzone "SMTP" (log on session start) Deny "app group blacklist A" for "User group A" dstzone "Internet" (log on session end) Deny "app group blacklist B" for "User group B" dstzone "Internet" (log on session end) Deny "app group blacklist C" for "User group C" dstzone "Internet" (log on session end) Allow "app group A" with service "default-application" for "User group A" dstzone "Internet" Allow "app group B" with service "default-application" for "User group B" dstzone "Internet" Allow "app group C" with service "default-application" for "User group C" dstzone "Internet" Deny any dstzone "Internet" (log on session start) Deny any any (log on session start) but make each rule as detailed as possible (like that allow dns rule above I would also define which srczones etc should be allowed). One could argue that allows should be as narrow/detailed as possible while denies should be as broad as possible. Which is true but if you sort your security rules by dstzone (so you protect whats allowed into each zone) I still think you can use the blacklist for user A, B and C with dstzone "Internet" instead of just dstzone "Any". The ping rule above is just an example on where to place "any" rules in case you wish to allow pings into all zones. The last "Deny any any (log on session start)" should never be reached since each zone should already have blocked unwanted traffic. You could create a daily report regarding this and trigger some alarm in case that last deny any any log rule would get triggered anyway. So the design would be: ALLOW GLOBAL (dstzone=any) DENY (dstzone=x) specific log on session end ALLOW (dstzone=x) specific DENY (dstzone=x) any log on session start ... DENY GLOBAL (dstzone=any) any log on session start
... View more
