The PCNSA exam domain of Traffic Enforcement requires you to understand how a firewall decides what to let in and what to block. Security policies are the core mechanism that makes this decision happen, but the order in which you place those policies is just as important as the policies themselves. For a complete beginner, this chapter will show you why a firewall is not a simple on-off switch and how rule ordering can mean the difference between a secure network and a wide-open door.
Jump to a section
A simple way to picture Securing Traffic: Security Policies and Rule Placement
A department store has a single main entrance and several employee-only doors.
The store's front door is the main public access point. A security guard stands there with a clipboard that lists rules. This clipboard is the store's security policy. The rules are listed in a specific order, from top to bottom, and the guard checks each rule in that order for every single person who walks in. Rule number one says: "If a person is holding a store employee badge, let them through immediately." Rule number two says: "If a person is carrying a large backpack, stop them and search it." Rule number three says: "If a person is wearing a red shirt, they are a VIP and get expedited entry." Rule number ten says: "Everyone else is allowed in."
The critical point is rule ordering. If the guard checked rule ten (allow everyone) before rule two (search backpacks), then every person with a backpack would be let in before being searched. The general permission would always be applied first, making rule two useless. In a network firewall, this is exactly how security policies work. The firewall examines traffic against a list of rules from top to bottom. The first rule that matches the traffic is the one that gets applied. This is why placing a broad "allow all" rule at the top of the list is a disaster, just like putting rule ten first at the department store. The specific rules that block or inspect dangerous traffic must come first, before the general permission rule.
A firewall is a network security device that sits between your internal network (like your company's computers and servers) and the internet. Its fundamental job is to examine every piece of data that tries to cross from one side to the other and decide whether to allow it or block it. This decision is not random. The firewall uses a set of written instructions called security policies. Each security policy is a single rule that says: "If traffic matches these specific conditions, then take this specific action."
A security policy contains three essential parts. The first part is the source. This is where the traffic is coming from. It could be a specific computer's IP address (a unique numerical label assigned to each device on a network), a range of addresses, or even an entire network zone (like the "Trust" zone for internal users). The second part is the destination. This is where the traffic is trying to go. It could be a specific server, a website address, or a network zone (like the "Untrust" zone for the internet). The third part is the application. This identifies what type of traffic it is. Is it web browsing (HTTP), email (SMTP), file transfer (FTP), or something else? Palo Alto Networks firewalls are famous for being able to identify applications, not just port numbers (which are like door numbers for different services). For example, a policy might specify the application "facebook-base" to block all Facebook traffic, regardless of which port or IP address Facebook uses.
The final part of a policy is the action. The action is almost always either "Allow" or "Deny". An Allow action means the traffic is permitted to pass through the firewall. A Deny action means the traffic is dropped and never reaches its destination. The firewall also logs this action so an administrator can see what was allowed or blocked.
Now, imagine you have ten policies in your firewall. They are stored in a list. The firewall processes this list from the very first policy at the top down to the very last policy at the bottom. For every single packet of data (a small chunk of the complete data stream), the firewall starts at policy number one. It checks: "Does this packet match the source, destination, and application defined in policy one?" If yes, it applies the action of policy one (allow or deny) and stops checking further policies. If no, it moves to policy two. It continues this process until it finds a match or until it reaches the end of the list. If no policy ever matches, the firewall has a default implicit deny rule at the very bottom. This means any traffic that does not match any explicit policy is automatically blocked. You cannot see this rule in the list, but it always exists.
This sequential processing is called rule ordering. It is the most critical concept to understand. Because the firewall stops at the first match, a general rule placed above a specific rule will always be applied first, making the specific rule pointless. For example, if you have a top rule that says "Allow all traffic from the internal network to the internet" and a second rule that says "Deny traffic from the accounting computer to the internet", the deny rule will never be triggered. Every packet from the accounting computer will match the first rule (Allow all) and be allowed through before the firewall even looks at the second rule.
Why does this matter? It replaces the older method of firewall management where administrators configured access control lists (ACLs) on routers. ACLs were also ordered lists, but they were much more primitive. They could only look at IP addresses and port numbers, not applications. A user could try to access Facebook using an unusual port, and a port-based ACL would let it through. A Palo Alto Networks security policy, however, can identify the application "facebook-base" regardless of the port or IP address used. This is a fundamental upgrade in security capability.
Best practices for creating these policies follow a simple pattern. You place your most specific and restrictive policies at the top of the list. These are policies that block dangerous applications, malicious IP addresses, or traffic from untrusted sources. Next, you place policies that control legitimate but specific traffic, like allowing access to a particular server for a particular team. Finally, at the very bottom of your list, but above the implicit deny, you place a very general rule. This general rule is often called a "catch-all" or "allow-internal" rule. It permits the general traffic that you know is safe, like allowing all internal users to browse the internet. But because it is at the bottom, it only applies to traffic that did not match any of the more specific rules above it. This ensures that exceptions and blocks are always enforced first.
Identify Traffic Needs
Determine what traffic needs to be allowed, what must be blocked, and which users or departments need access. This information comes from business requirements and security policies. Without this step, you are guessing.
Order Policies by Specificity
List your rules from most specific to least specific. Specificity means how tightly defined the source, destination, and application are. A rule that blocks a single IP address to a single application is more specific than a rule that allows all traffic from any IP. Place the most specific rules at the top.
Place Block Rules Above Allow Rules
Any rule with a 'Deny' action that targets dangerous or prohibited traffic must be placed above any general 'Allow' rules. If a block rule is placed below a catch-all allow rule, the allow rule will match first and the block rule will never be applied.
Create a Catch-All Allow Rule at the Bottom
At the very bottom of your explicit policy list, create a rule that allows general traffic from your internal network to the internet. This rule must use broad conditions (source: Trust zone, destination: any, application: any). This ensures that all other specific rules are evaluated before this general permission.
Test and Validate Order
Use the firewall's built-in policy hit counter or packet capture tools to verify that each rule is matching the expected traffic. If a deny rule shows zero hits, it may be placed too low in the list and never reached. Reorder and retest until the traffic flows as intended.
An IT professional working for a mid-sized company called Orion Marketing is responsible for the company's Palo Alto Networks firewall. Orion Marketing has 200 employees. The company uses cloud-based software for email (Office 365), project management (Asana), and file storage (Dropbox). Management has also allowed employees to use social media for marketing purposes, but strictly forbids streaming video (like Netflix) or peer-to-peer file sharing (like BitTorrent) because they consume massive bandwidth and pose security risks.
The IT professional's task is to create a set of security policies that enforce these rules. The professional begins by connecting to the firewall's management interface. This is a graphical dashboard where policies are listed and ordered. They see an empty policy list with a single invisible rule at the bottom: "Deny All".
Step one: The professional creates the most specific deny policies. They create a policy named "Block Malicious IPs" that blocks all traffic from a list of known malicious IP addresses provided by an external threat intelligence feed. This policy is placed at position #1. It is the most specific and restrictive.
Step two: They create a policy named "Allow Office 365" that allows traffic specifically to Microsoft's Office 365 servers. They define the destination as the list of Microsoft's public IP address ranges and the application as "office-365". This is placed at position #2. It is a specific allow rule.
Step three: They create a policy named "Allow Asana" and one named "Allow Dropbox" using the same logic, placed at positions #3 and #4. These are specific applications that are explicitly permitted.
Step four: They create a policy named "Block Streaming" that blocks applications like "netflix-base", "hulu-base", and "youtube-base". This is placed at position #5. It is a specific block rule for a category of applications.
Step five: They create a policy named "Block Peer-to-Peer" that blocks applications like "bittorrent" and "edonkey". This is placed at position #6.
Step six: They create a policy named "Allow Social Media for Marketing" that allows applications like "facebook-base", "twitter-base", and "instagram-base" but only for the IP addresses of the marketing department's computers. This is placed at position #7.
Step seven: Finally, they create a catch-all policy named "Allow General Internet" that allows all traffic from any internal user to any destination. But they place this rule at the very bottom, position #8. This rule ensures that all employees can browse the web for general work tasks.
The critical moment comes when an employee in accounting tries to watch Netflix. The traffic enters the firewall. The firewall checks policy #1 (Block Malicious IPs) — no match. Policy #2 (Allow Office 365) — no match. Policy #3 (Allow Asana) — no match. Policy #4 (Allow Dropbox) — no match. Policy #5 (Block Streaming) — match! The application is identified as "netflix-base". The action is Deny. The packet is dropped. The employee gets no video. Because the Block Streaming rule is placed before the General Internet rule, it works perfectly.
If the IT professional had placed the General Internet rule at position #1, every employee including Netflix users would have matched that rule first. The Block Streaming rule would never have been checked. This is the real-world consequence of poor rule ordering.
The PCNSA exam (Palo Alto Networks Certified Network Security Administrator) tests your understanding of security policies and rule placement very directly. Expect to see at least 5-8 questions on this topic. The exam does not ask you to configure a real firewall. Instead, it presents multiple-choice questions, drag-and-drop ordering scenarios, and "select all that apply" questions. You must know the concepts cold.
Here are the exact concepts the exam loves to test:
First-match logic: The exam will describe a scenario with three or four policies in a specific order. Then it will describe a specific traffic flow (for example, a user on a specific IP trying to access a specific application). You must predict which policy matches that traffic. The correct answer is always the first policy in the list that matches the source, destination, and application.
Implicit deny: The exam will present a scenario where traffic does not match any explicit policy in the list. The correct answer is always that the traffic is denied by the implicit deny rule at the very bottom. You must remember that this rule exists even though it is not visible in the GUI.
Application vs. port: The exam will present a misconfiguration where a policy uses a port number (like port 80 for HTTP) instead of an application (like web-browsing). The exam tests that an application-based policy is superior because it can identify the application even if it uses a non-standard port. For example, a user could run a game over port 80. A port-based policy would allow it; an application-based policy would block it.
Rule placement best practices: The exam will ask you to identify the correct order for a set of rules. The correct pattern is: specific deny rules first, then specific allow rules, then catch-all allow rules last.
Zone-based policies: The exam tests that a security policy is tied to zones (like Trust, Untrust, DMZ). Traffic moving from one zone to another (for example, from Trust to Untrust) must match a policy. The exam tests that you must define both the source and destination zones correctly.
Intrazone vs. interzone: The exam will test the difference between traffic inside the same zone (like two computers in the Trust zone) versus traffic between different zones. Intrazone traffic sometimes requires a specific policy to allow it, depending on the firewall configuration.
Common traps the exam sets:
The exam shows a list where a general "allow all" rule is above a specific "block" rule. They ask: "What happens to traffic that matches the block rule?" Beginners often say it gets blocked. The correct answer is that it gets allowed by the first rule before it reaches the block rule. This is the most common trap.
The exam gives a policy with a very broad source (like "any") and a very broad destination (like "any"). They ask: "What does this policy do?" Beginners overthink it. The answer is that it matches all traffic and applies its action (usually allow) to everything.
The exam asks about logging. Logging is optional per policy. A policy can be set to log at session start or session end. The exam tests that you must enable logging to see what traffic was allowed or denied.
The exam tests the concept of policy hit count. A policy that never matches any traffic is called a "zero-hit" policy. The exam tests that zero-hit policies are often misconfigured or the result of incorrect ordering.
A firewall processes security policies from top to bottom and applies the action of the first matching rule, then stops checking further rules.
Always place the most specific deny rules at the top of the policy list and the most general allow rules at the bottom.
The implicit deny rule is invisible and unchangeable, and it blocks any traffic that does not match an explicit policy above it.
An application-based policy is more effective than a port-based policy because it can identify traffic regardless of the port or IP address used.
A policy placed above a more specific rule will match traffic first, potentially making the specific rule ineffective.
Logging must be explicitly enabled on a policy; the firewall does not log traffic by default for every policy.
These come up on the exam all the time. Here's how to tell them apart.
Security Policy Rule
Uses application identification (App-ID) to inspect traffic
Is ordered sequentially with first-match logic
Can be applied to zones (Trust, Untrust, DMZ)
Access Control List (ACL)
Uses only IP addresses, ports, and protocols
Is ordered sequentially with first-match logic
Is typically applied to router interfaces, not zones
Allow Rule
Permits traffic that matches its conditions
Should be placed after specific deny rules
Typically used for general internet access at the bottom of the list
Deny Rule
Blocks traffic that matches its conditions
Should be placed at the top of the list for specific threats
Typically used for malicious IPs or prohibited applications
Implicit Deny
Is built into the firewall and cannot be removed
Applies only if no other rule matches
Is invisible in the policy list
Explicit Deny
Is a rule created by the administrator
Is visible in the policy list
Can be moved, edited, or deleted
First-Match Logic
Firewall stops checking after the first matching rule
Used by Palo Alto Networks firewalls
Requires careful ordering of rules from specific to general
Last-Match Logic
Firewall checks all rules and applies the last matching one
Used by some older firewall models
Requires rules to be ordered from general to specific
Mistake
The first rule in a firewall policy list is the most important one, and the last rule is the least important.
Correct
The first rule is the most frequently applied, but the rule at the bottom (the implicit deny) is critically important because it catches all unmatched traffic. Every rule's position determines its priority, not its importance.
Beginners think position equals hierarchical importance (like a CEO at the top). In firewalls, position equals processing order, not authority.
Mistake
If I have a deny rule and an allow rule that both match the same traffic, the allow rule wins because it is more permissive.
Correct
Neither rule wins inherently. The rule that is physically higher in the list wins, regardless of whether it is allow or deny. The firewall does not prefer allow over deny.
People bring a 'freedom' bias into tech: they assume systems are designed to be permissive. Firewalls are neutral; they follow order, not preference.
Mistake
A firewall can automatically reorder my policies to be more efficient, so I don't have to worry about placement.
Correct
Palo Alto Networks firewalls do not automatically reorder policies. The administrator must manually set the order. Some other firewall brands offer optimisation tools, but the PCNSA expects you to know that you control the order.
Many beginners come from smart devices that auto-arrange things (like phone apps sorting by use frequency). Firewalls are manual by design for security control.
Mistake
The implicit deny rule at the bottom of the list can be deleted or replaced with an explicit allow rule.
Correct
The implicit deny rule is hardcoded into the firewall's operating system. It cannot be deleted, moved, or modified. You can only add explicit rules above it. The implicit deny always remains the last resort.
Users assume everything in a software system is configurable. The implicit deny is a fundamental safety net, baked into the system to prevent accidental full opening of the network.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The traffic is blocked by the implicit deny rule. This rule is built into the firewall and cannot be deleted. It applies automatically to any traffic that does not match a rule in your list.
Yes, but only the first one in the list will ever be applied. The second policy will never match because the first policy already handled that traffic. This creates a 'shadowed' rule which is a waste of space and can be confusing.
Yes, order matters even if all rules are deny rules. If you have a general deny rule at the top that denies all traffic, and a specific deny rule below it that denies traffic to a specific malicious IP, the specific rule never gets checked because the general rule already denied everything.
A catch-all rule is a very broad allow rule placed at the bottom of your policy list. It permits traffic that did not match any of the more specific rules above it. It is the last explicit rule before the implicit deny.
The firewall uses a technology called App-ID that inspects the data itself, not just the port number. It looks at signatures, protocol decoders, and behavioural patterns to identify the exact application, even if it is using a non-standard port.
A zero-hit policy is a security policy that has never matched any traffic. It is usually the result of being placed too low in the list or having conditions that are too specific. Administrators look for zero-hit policies to identify misconfigurations.
You've finished Securing Traffic: Security Policies and Rule Placement. Continue through the PCNSA study guide to build a complete picture of the exam.
Done with this chapter?