Use destination networks even with App-ID specified?

Reply
Highlighted
L1 Bithead

Use destination networks even with App-ID specified?

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?


Accepted Solutions
Highlighted
Cyber Elite

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

View solution in original post


All Replies
Highlighted
Cyber Elite

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

View solution in original post

Highlighted
L1 Bithead

Thanks for sharing your input @BPry.!

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!