Use destination networks even with App-ID specified?

[btenberge]

I've been creating security rules to allow Traps Management (with the traps-management-service App-ID) pretty tightly by also defining destination networks (using FQDN objects for the multiple <tenant>.traps.paloaltonetworks.com and common contentprod and distributions hosts).

According to the documentation on https://docs.paloaltonetworks.com/traps/tms/traps-management-service-admin/get-started-with-tms/enab... it should be enough to simply use the App-ID and keep it at that.

So now that got me thinking, does the traps-management-service App-ID take destination networks into account?

Am I too paranoid doing things like this, or is it good practice to keep security rules as tight as possible, even with App-ID's?

[BPry · Accepted solution]

@btenberge,

I believe that the traps-management-service signature actually takes the certificate of the connection into account, so the app-id itself should be relatively bulletproof. 

Like anything else, how you should configure this really depends on your environments risk level. I have some organizations where I limit access to set destination addresses for any rule allowing outbound traffic; and I have others where the app-id itself is more than sufficient. If you utilize app-id to limit access, you are still allowing a handshake to take place at minimum. Some orgs will find that acceptable, others won't. 

From an over-arching answer I'll say this, the vast majority of environments shouldn't feel like they need to limit app-id use to specified destinations. Even in highly secure environments, I generally would only go to the lengths you are going to on machines that actually have access to access sensitive information. 

[btenberge]

Thanks for sharing your input @BPry.!