About RH747

Hello,   I have established an outbound SSL decrypt policy that I have enabled for only myself as I test functionality. Over the past few months, I've noticed a quirk that I'm unsure of the reasoning behind. With the policy enabled, sometimes connections to certain destinations will require a reload of the webpage to establish connection.   For example: Navigate to a knowledgebase for a vendor - failed to establish connection upon first attempt Reload the webpage - successfully establish connection   This behavior is exclusive to when I have the decrypt policy enabled so I'm fairly certain that I am pointing the finger at the correct culprit. It seems a problematic destination is random, as it's not always the same sites and varies between days/weeks on occurrence.   The work around of simply refreshing the page is easy enough, my concern is when I enable this for the company and users flood my inbox with this issue for various sites and I have to tell them all to refresh... seems half-baked.   My question is - Is this normal behavior for SSL decryption, or am I missing something within the configuration? I followed the best-practice guide released by Palo Alto.   Thanks! ... View more

I'm going through implementing a special 'modified' SP800-171R2 control list and I believe I can achieve satisfying controls such as 3.13.9 "user session timeout/terminate external access etc etc" control with the UID timeout function.   If I tied external internet access to a security group in my AD and granted users membership to that group, then when their ip-mapping cache is up for renewal and isn't renewed then they would effectively have their "session terminated" as the control requires.   However, I have several questions on how UID determines a renewal. Obviously UID caches the user's successful log in or kerberos grant and that lasts your defined cache period (45 minutes by default), but once a renewal is necessary what is criteria that UID is searching for to grant a renewed ip-mapping?   This article states a few Event ID's that UID looks for to grant a mapping, but I can almost bet money these aren't everything UID is using to define user activity: Security Event IDs from Active Directory Used with User-ID Agent    The reason I doubt that's an exhaustive list is it seems there's a large gap for security events to be missed. For example - a user logged in, and then 20 minutes later was locked out of their account. Both events happen within the 45-minute cache renew window with the lockout being the most recent event to be logged. Would UID read the Event ID 4740 for account lockout and deny a mapping renewal for that user? According to that article, no, but that seems silly, and I highly doubt that to be the case as that would leave fairly major security gaps within the UID function. Would the lockout be handled by LDAP and UID genuinely only monitors log-in activity?   If that's the case, what if a user logs in and is active for the entire 45-minutes so they don't log in a second time to trigger a renewal and the kerberos ticket lifetime is 10-hours so there wouldn't be a TGT event ID for a renewal either. Would the user need to log out/in to trigger UID to map their ID to an IP? Would I need to set our kerberos halflife to a shorter duration so the events are more frequent and keeps ip-mappings fresh?   I'm trying to understand what exactly triggers UID to grant ip-mappings and subsequently renew those mappings. If there's a way to "game the system" with the way UID processes renewals, then I may not be able to use it for meeting compliance.   Has anyone tested UID to this extent or found a document useful in explaining more about this topic?   TL; DR Is there an official exhaustive list of Event ID's that UID utilizes to trigger renewals, or adversely denials, for ip-mapping? ... View more