topic Re: Use destination networks even with App-ID specified? in General Topics

Use destination networks even with App-ID specified?

btenberge — Thu, 09 Jan 2020 11:34:40 GMT

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/enable-access-tms.html 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?

Re: Use destination networks even with App-ID specified?

BPry — Thu, 09 Jan 2020 19:39:36 GMT

@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.

Re: Use destination networks even with App-ID specified?

btenberge — Mon, 13 Jan 2020 09:12:30 GMT

Thanks for sharing your input @BPry.!