Exam objective 2.2 focuses on configuring service objects, service groups, and application objects to specify traffic characteristics. This concept is the foundation of writing effective security policies. If you cannot correctly identify what a service is versus an application, your firewall rules will be either dangerously permissive or uselessly restrictive.
Jump to a section
A simple way to picture Managing Objects: Services, Service Groups, and Application Objects
You are the head chef at a busy restaurant. Your job is to ensure every meal that leaves your kitchen is exactly what the customer ordered, cooked correctly, and delivered on time. But you don't cook every dish yourself. You manage a team of specialised cooks, each responsible for a specific type of food. One cook only handles grilling steaks, another only prepares salads, and a third is exclusively for desserts. Each cook has a dedicated workstation with the exact tools and ingredients they need.
To keep things running smoothly, you have a system. On the wall, there is a list of every 'service' you offer: a 'Grilled Steak' service that uses the grill station, a 'Caesar Salad' service that uses the prep station. These are your service objects. When a table orders multiple items, like a steak and a salad, you can create a 'service group' called 'Main Course Combo' that bundles them together. But here is the clever part. You also have 'application objects'. Instead of just saying 'bring the steak', you look at the actual application on the table. Is it a customer who ordered the 'Premium Dining Experience' application? That determines more than just the steak. It dictates the plate it goes on, the garnish, the side dishes, and even the order in which courses are served. The application defines the full behaviour. If you only looked at the port (the grill station), you might miss that a 'Burger' and a 'Steak' both use the grill but are completely different applications with different rules. By defining the application itself, you get total control over the experience, not just the transport method.
This is exactly how a Palo Alto Networks firewall manages network traffic. You create 'service objects' for specific ports and protocols, 'service groups' to bundle them, and 'application objects' to identify the actual software in use, like Facebook or Salesforce. This gives you precise control over what traffic is allowed, blocked, or inspected, based on what the application is doing, not just where it is going.
To write a firewall rule that allows or blocks traffic, you must first define what that traffic looks like. Think of a traditional firewall. It only looks at two things: the destination port number and the protocol (TCP or UDP). For example, web traffic usually uses TCP port 80 (HTTP) or TCP port 443 (HTTPS). Email traffic uses TCP port 25 (SMTP), 110 (POP3), or 143 (IMAP). The firewall says, 'I see traffic to port 443. That must be a secure website. I will allow it.' This is a 'service-based' rule. It relies on the assumption that specific ports always mean specific applications.
But this assumption is broken in the modern world. Many applications no longer use their standard ports. For example, Facebook Messenger can use port 80 or 443, just like a regular website. Skype famously uses random high-numbered ports. A malicious program can disguise itself by sending its traffic over port 443, pretending to be safe HTTPS traffic. If your firewall only checks the port, it will let the malware through because it sees a legitimate-looking service.
This is why Palo Alto Networks introduced 'App-ID'. Instead of just asking 'What port is this traffic using?', the firewall asks 'What application is this traffic?' It analyses the traffic in real time using multiple techniques: packet inspection, protocol decoding, decryption, and signature matching. It looks at the actual content and behaviour of the traffic to determine if it is truly Facebook, or if it is malware pretending to be Facebook.
Here is where objects come in. In the Palo Alto Networks firewall, you manage your definitions through objects:
Service Object: A definition of a single network service. It has a name (like 'web-80'), a protocol (TCP or UDP), and a destination port number (like 80). This is the traditional way. You use this when you want to allow traffic based on port, or when writing rules for protocols that App-ID cannot identify.
Service Group Object: A collection of multiple service objects grouped under one name. For example, 'Basic-Web-Services' could include 'TCP-80', 'TCP-443', 'UDP-53'. This is purely for convenience and organisation. Instead of writing three separate rules for three ports, you write one rule that references the group.
Application Object: This is where Palo Alto excels. An application object represents a specific application, like 'facebook-base', 'smtp', or 'ssl'. The firewall identifies the application using App-ID. When you create a rule using an application object, you are telling the firewall to inspect the traffic and match it based on the actual application, not just the service. Each application object has properties: a name, a category (like 'collaboration' for webex), a subcategory, a technology (like 'browser-based'), a risk level (1-5), and characteristics like 'evades-by-encryption' or 'tunnel-other-applications'.
To write a security rule, you must define a 'source' (where the traffic comes from), a 'destination' (where it goes), and then the 'application'. You can also optionally specify a 'service' if you want to restrict traffic to a specific port, but this is not required when using App-ID. For maximum security, you should specify the application and leave the service as 'application-default'. This tells the firewall only to allow traffic for that application on its standard, known ports. If an application tries to use a non-standard port, the firewall blocks it.
Why does this exist? It replaces the old, insecure model of port-based firewalling. It exists because applications are dynamic. They update, they change ports, and they can be manipulated by malware. By defining the application itself, you gain control over the traffic's behaviour, not just its destination. This allows you to, for example, allow Facebook for browsing but block Facebook games, all within one rule.
For a beginner studying PCNSA, you must memorise the difference between these objects, how to create them, and when to use a service versus an application. The exam will present scenarios where you need to allow a specific application (like WebEx) and you must choose the correct object type. Remember: always prefer application objects for modern traffic. Use service objects only for legacy protocols that cannot be identified by App-ID.
Identify the Application or Service
Determine what traffic you need to manage. Is it a standard application like Microsoft Teams (which App-ID can identify) or a custom legacy program that only uses a specific port? This determines whether you need an application object or a service object.
Create a Service Object (If Needed)
If the traffic is a legacy protocol or a custom service that App-ID cannot identify, create a service object. Go to Objects > Services > Add. Give it a name (e.g., 'custom-tcp-8080'), select the protocol (TCP), and enter the destination port number (e.g., 8080). Save it.
Create a Service Group (Optional)
If you have multiple service objects that are always used together, create a service group. Go to Objects > Service Groups > Add. Give it a name (e.g., 'Web-Services') and add the relevant service objects (e.g., 'tcp-80', 'tcp-443'). This simplifies rules by allowing one reference instead of multiple.
Select or Create an Application Object
For modern applications, use a pre-defined application object. Go to Objects > Applications > search for the application (e.g., 'ms-teams-base'). If it does not exist, create a custom one. Provide a name, define the default ports (for custom apps), and set the risk level and characteristics. The firewall will use App-ID to match the traffic.
Write a Security Rule Using the Objects
Now create a security policy rule. Go to Policies > Security > Add. Set the source and destination zones and addresses. In the 'Application' tab, add the application object(s). In the 'Service/URL Category' tab, you can optionally specify a service (use 'application-default' to enforce port adherence). Set the action (allow or deny). Commit the rule.
Test and Verify the Rule
After the rule is committed, generate traffic from a client that matches the rule conditions. Check the firewall logs (Monitor > Logs > Traffic) to confirm that the traffic was matched by the correct rule and that the application was correctly identified. If the traffic is not matched, refine your objects or rule conditions.
An IT professional, let us call her Priya, is responsible for managing security at a mid-sized company called 'BrightTech'. The company has 500 employees who use a mix of internal applications, cloud-based tools like Salesforce and Microsoft 365, and web browsing. Priya has just received a new Palo Alto Networks firewall and needs to build the security policy from scratch.
Priya starts by identifying the company's critical applications. She knows that the sales team uses Salesforce exclusively. The engineering team uses a custom internal tool on TCP port 8080. Everyone uses Microsoft Teams for chat and video calls. Priya needs to write rules that allow these applications to work while blocking everything else.
First, Priya creates application objects for the known applications. She navigates to the Objects tab on the Palo Alto Networks firewall GUI, then to 'Applications'. She sees that Palo Alto already has hundreds of pre-defined application objects. She simply selects 'salesforce-base', 'ms-teams-base', and 'webex' (they also use WebEx for client meetings). She does not need to create these from scratch. For the custom internal tool, she must create a new application object. She clicks 'Add' and gives it a name: 'brighttech-internal-app'. She selects the port it uses: TCP 8080. She sets the application characteristics. Because her internal tool is a known, trusted application, she sets the risk to 1 (lowest). She configures it to use 'application-default' for the service, which means the firewall will only allow this traffic on TCP 8080.
Next, Priya creates service objects for legacy systems that her company still runs. They have an old file server that uses FTP (TCP ports 20 and 21). She creates two service objects: 'ftp-control' for port 21 and 'ftp-data' for port 20. She then creates a service group called 'Legacy-FTP' and adds both service objects to it. This makes her rule cleaner: instead of two lines for services, she has one line for the group.
Now Priya writes security rules. She creates a rule called 'Allow-Salesforce'. The source is the 'Sales-Users' address group. The destination is 'any' (because Salesforce is in the cloud). The application is 'salesforce-base'. She leaves the service as 'application-default'. This ensures that only genuine Salesforce traffic is allowed, even if someone tries to use a different application on the same port. She creates another rule for the custom internal app: source is 'Engineering-Users', destination is 'Internal-Server', application is 'brighttech-internal-app', service is 'application-default'.
Priya tests the rules. She asks a salesperson to log in to Salesforce. The firewall logs show the traffic was matched to 'Allow-Salesforce' and allowed. Then she asks a rogue employee (simulated) to try to use a gaming application over port 443. The firewall inspects the traffic, determines it is not HTTPS but a gaming app, and blocks it because no rule explicitly allows that application. The log shows it as 'App-ID: gaming' with action 'deny'.
Priya also uses 'service objects' in rules that are not application-specific. She writes a rule that blocks all traffic to TCP port 3389 (Remote Desktop Protocol) from the internet, regardless of application. This is a safety net. Even if an unknown application tries to use that port, the rule blocks it by service.
In her day-to-day, Priya regularly audits the application objects. She looks at the 'Application Statistics' report to see which applications are being used in her network. She discovers that some employees are using a new file-sharing app called 'ShadowShare'. She creates a new rule to block this application. She also uses the 'SaaS Security' feature, which is an extension of application objects, to enforce policies on sanctioned cloud apps.
The key takeaway for IT professionals is to always use application objects as the primary identifier in security rules. Use service objects as a secondary filter or for legacy protocols. Use service groups to keep the rulebase organised. This approach minimises the attack surface and gives granular control over the network.
The PCNSA exam, specifically objective 2.2, will test your ability to distinguish between service objects, service groups, and application objects, and to know when to use each. The questions are typically scenario-based, asking you to choose the correct configuration for a given business requirement.
Here are the specific topics the exam will test:
- The definition of a service object: a definition of a protocol and a port. You must know that a service object has fields for 'Name', 'Protocol' (TCP, UDP, or other IP protocols), and 'Port Number' (or port range). The exam will test you on creating a service object for a non-standard port, like TCP port 2345 for a custom application. - The definition of a service group: a container that holds multiple service objects. The exam will ask, 'An administrator wants to allow web traffic on ports 80, 443, and 8080. What is the most efficient way to configure this?' The answer is to create a service group containing those three service objects. - The definition of an application object: a definition of a specific application, identified by App-ID. The exam will test that you cannot create an application object just from a port. It requires the firewall to perform deep packet inspection. You must know that Palo Alto Networks provides thousands of pre-defined application objects. - The difference between 'service' and 'application' in a security rule: When writing a rule, you can specify a 'service' (which is optional) and an 'application' (which is required for modern rules). The exam loves to ask: 'What happens if you specify an application and do not specify a service?' The correct answer is: the firewall uses the 'application-default' service, which means it only allows traffic for that application on its standard ports as defined in the application object. - The trap: The exam will present a scenario where a user needs to allow 'Skype' traffic. An incorrect answer will say 'Create a service object for UDP port 3478 and allow it.' The correct answer is to create a rule using the pre-defined application object 'skype-base'. This is because Skype uses many ports and changes them dynamically. Only App-ID can properly identify Skype. - Another trap: The exam asks about 'custom' applications. You must know that to create a custom application object for an internal application, you need to define the port(s) it uses. The exam will test you on the fact that for custom applications, you specify the 'default port' in the application object configuration. - The exam tests 'service groups' as a time-saver. A question might present a scenario with 5 different service objects that are always used together. The correct configuration is to bundle them into a service group. - Key definitions to memorise: * Service Object: Defines a port/protocol pair. Used for legacy or non-applicable traffic. * Service Group: A collection of service objects. Used for organisation. * Application Object: Defines an application based on App-ID inspection. Preferred for modern traffic. * Application-Default Service: The set of ports that an application is known to use, pre-defined in the application object. - The exam will also test that you cannot use a service group within an application object. Application objects reference services only through the default port setting. Service groups are only for use in security rules. - Finally, the exam loves to ask about the 'zone-based' nature of security rules. Objects are referenced by rules, and rules are applied to zones. You must know that service objects and application objects are independent of zones. They are just definitions you use in rules.
To pass, practise building rules in the Palo Alto Networks learning environment. Understand that the exam is not about memorising port numbers. It is about understanding the architecture of object-oriented policy management. When you see a question about allowing an application, your first thought should be: 'Use an application object.' Only if the question explicitly says 'this is a legacy protocol that cannot be identified' should you reach for a service object.
A service object defines a specific port and protocol combination, like TCP port 443 for HTTPS.
A service group is a collection of multiple service objects used to simplify rule creation by grouping related services.
An application object defines a specific network application, such as 'facebook-base' or 'ssl', identified by App-ID through deep packet inspection.
In a security rule, you should always prefer using an application object over a service object for modern traffic to ensure accurate identification and control.
When you specify an application object and leave the service as 'application-default', the firewall enforces traffic only on the ports the application is known to use.
Service groups can only contain service objects, not application objects, so use them purely for port-based organisation.
Palo Alto Networks provides a comprehensive library of pre-defined application objects for thousands of popular applications, reducing the need to create custom ones.
Using 'any' as the service in a rule with an application object disables port enforcement, reducing security; use it only when necessary.
These come up on the exam all the time. Here's how to tell them apart.
Service Object
Defines traffic by port and protocol only (e.g., TCP 80).
Does not inspect the content of the traffic.
Can be bundled into a service group.
Application Object
Defines traffic by application identity (e.g., 'facebook-base').
Uses App-ID to inspect content and behaviour.
Cannot be placed in a service group; used directly in rules.
Service Group
A single object that contains multiple service objects.
Simplifies the rule by having one entry instead of many.
Only for port/protocol services, not applications.
Security Rule with Multiple Services
Adding multiple services individually to one rule.
More cluttered rulebase and harder to update.
Can also include application objects, not just services.
Pre-defined Application Object
Provided by Palo Alto Networks for common apps.
Has built-in application signatures and port defaults.
Cannot be modified, but can be cloned.
Custom Application Object
Created by the administrator for proprietary apps.
Requires manual definition of ports and characteristics.
Can be tailored with specific risk levels and timeout values.
Using 'application-default' for Service
Restricts traffic to known ports for the application.
More secure; prevents port-hopping by malware.
Recommended best practice for security rules.
Using 'any' for Service
Allows the application on any port.
Less secure; can be exploited.
Use only for troubleshooting or specific purposes.
Mistake
A service object and an application object are the same thing, just with different names.
Correct
A service object only defines a port and protocol. An application object defines a specific application detected by App-ID through deep packet inspection.
This confusion arises because in older firewall systems, 'service' was the only concept. Beginners assume 'application' is just a fancy new word for 'service'.
Mistake
If I create a rule that allows an application, I also have to specify its exact port number in the service field, or it won't work.
Correct
If you specify an application object and leave the service as 'application-default', the firewall automatically uses the ports defined in the application object's default settings.
Beginners think they must manually type the port because they are used to port-based firewalls. They do not trust the automatic default.
Mistake
Service groups can contain both service objects and application objects.
Correct
Service groups can only contain other service objects. They cannot contain application objects.
The name 'group' implies it can hold anything. But in Palo Alto, service groups are strictly for port/protocol definitions, not applications.
Mistake
You must create a new application object from scratch for every application you want to allow, even for popular ones like Facebook.
Correct
Palo Alto Networks provides thousands of pre-defined application objects for common applications. You only need to create custom objects for proprietary or unknown applications.
Beginners think they need to build everything themselves, not realising that Palo Alto already has a massive library of application signatures.
Mistake
If you set the service to 'any' in a rule, the firewall will match any port, which is the most permissive and best for troubleshooting.
Correct
Setting the service to 'any' means you lose the ability to restrict traffic to application-default ports. It is less secure and should only be used for troubleshooting or specific use cases.
Beginners think 'any' is the easiest and safest because it lets everything through, but it bypasses the security benefit of port enforcement.
Mistake
Application objects are only used to identify traffic, never to block it.
Correct
Application objects are used in both 'allow' and 'deny' rules. You can create a rule that blocks an application, such as blocking 'facebook-base' for a specific user group.
Beginners associate the word 'object' with something you allow. They do not realise the same object can be used in a deny action.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A service object only defines a port and protocol number (like TCP 443). An application object defines an entire application (like Facebook) based on deep packet inspection. Application objects are more accurate and secure.
No. Palo Alto Networks provides a built-in library of thousands of pre-defined application objects for common apps like Salesforce, WebEx, and Microsoft 365. You only need to create custom objects for proprietary or unknown applications.
The firewall automatically uses the 'application-default' service. This means it only allows traffic for that application on the ports that the application object defines as standard. If the application uses a non-default port, it will be blocked.
No. Service groups can only contain other service objects (port/protocol definitions). To group applications, you must add multiple application objects directly into a single security rule.
Use a service object only when you are dealing with a legacy protocol or a traffic type that App-ID cannot identify, such as a simple TCP port for a custom printer that has no application signature. For all modern applications, use application objects.
'Application-default' is an option in the service field of a security rule that tells the firewall to only allow traffic for the specified application on the ports it is known to use. It is important because it prevents applications from being used on non-standard ports, which is a common evasion technique for malware.
You've finished Managing Objects: Services, Service Groups, and Application Objects. Continue through the PCNSA study guide to build a complete picture of the exam.
Done with this chapter?