05-22-2018 06:36 AM
What method is everyone using to handle false positives for credential phishing? Does everyone just create a custom URL category and drop in the sites where users use corporate email as their user ID?
02-12-2019 10:10 AM - edited 02-12-2019 10:11 AM
I'm glad you asked. I'm going to lay out first what options are available for phishing detection on PAN for admins that are new to the feature.
Credential phising detection on PANs can be deployed in one of three ways:
I deployed option 3 at my organization. Option 1 and 2 aren't detecting sensitive information so we did not opt for those choices. Domain Credential filter has some additional requirements above and beyond option 1 and option 2. Domain credential filter requires the following:
Unless users are browsing 100% unecrypted http links, SSL decrytipon is also required because the firewall cannot see into SSL traffic without decrypting it. Nearly all modern websites and phishing websites have have an SSL certificate so enabling decryption is required to detect corporate credentials in these cases.
I am going to define a false positive in this instance as the firewall saying a credential (corporate password in our case) was detected where one was not entered and was not present in the flagged traffic.
How do we know thse are false positives?
First we look at the link:
www.marriott.com/aries-auth/loginWithCredentials.comp
www.thegoodwynn.com/Apartments/module/application_authentication
order.dominos.com/power/login
my1.equityapartments.com/Login.aspx?ReturnUrl=/
It's quite clear that the above links are all handling logon/authentication and are True Positive hits because a user definitely was in the process of logging into that site when the credential phishing detection fired a hit.
What does a false positive look like?
This is just a short sampling. We've had many many more false positive hits than these.
The above links are obviously not login events to a website. A user also did not accidentally type their password and send an http post to those links. So what are they? They are all third party analytics gathering services. What we've discovered is that third party ad/analytics gathering services cause the credential phishing detection to throw false positives when Domain Credetial filter detection is being used in conjuction with decryption. I've tried to debug this with PAN tac but because it cannot be reproduced on demand the issue cannot be addressed.
02-07-2019 11:20 AM
02-07-2019 11:47 AM
@fcatapano1 wrote:What method is everyone using to handle false positives for credential phishing? Does everyone just create a custom URL category and drop in the sites where users use corporate email as their user ID?
Yes, we're just using the IP-mapping so there's inherently false positives. So we just have a custom category for allowing.
02-07-2019 11:48 AM
@staustin wrote:
I k ow this thread is old but we have false positive issues as well. We're using password detection which requires decryption and a read only domain controller. There are false positive issues but I've yet to be able to recreate the issue on demand and pan won't troubleshoot it unless it can be reproduced on demand.
requires decryption? You mean "domain credential filter?" How are you getting false positives? How do you know?
02-12-2019 10:10 AM - edited 02-12-2019 10:11 AM
I'm glad you asked. I'm going to lay out first what options are available for phishing detection on PAN for admins that are new to the feature.
Credential phising detection on PANs can be deployed in one of three ways:
I deployed option 3 at my organization. Option 1 and 2 aren't detecting sensitive information so we did not opt for those choices. Domain Credential filter has some additional requirements above and beyond option 1 and option 2. Domain credential filter requires the following:
Unless users are browsing 100% unecrypted http links, SSL decrytipon is also required because the firewall cannot see into SSL traffic without decrypting it. Nearly all modern websites and phishing websites have have an SSL certificate so enabling decryption is required to detect corporate credentials in these cases.
I am going to define a false positive in this instance as the firewall saying a credential (corporate password in our case) was detected where one was not entered and was not present in the flagged traffic.
How do we know thse are false positives?
First we look at the link:
www.marriott.com/aries-auth/loginWithCredentials.comp
www.thegoodwynn.com/Apartments/module/application_authentication
order.dominos.com/power/login
my1.equityapartments.com/Login.aspx?ReturnUrl=/
It's quite clear that the above links are all handling logon/authentication and are True Positive hits because a user definitely was in the process of logging into that site when the credential phishing detection fired a hit.
What does a false positive look like?
This is just a short sampling. We've had many many more false positive hits than these.
The above links are obviously not login events to a website. A user also did not accidentally type their password and send an http post to those links. So what are they? They are all third party analytics gathering services. What we've discovered is that third party ad/analytics gathering services cause the credential phishing detection to throw false positives when Domain Credetial filter detection is being used in conjuction with decryption. I've tried to debug this with PAN tac but because it cannot be reproduced on demand the issue cannot be addressed.
02-12-2019 10:49 AM - edited 02-12-2019 10:51 AM
@staustin wrote:I'm glad you asked. I'm going to lay out first what options are available for phishing detection on PAN for admins that are new to the feature.
...<words>...
Oh ok, now I get it. The reason for my confusion was not because I don't understand the options but rather because you're incorrectly attributing the need for SSL decryption in general firewall config SOLELY to option 3.
Regardless in options 1, 2 or 3 once navigating around a SSL website you will NEVER see domain user ID/password combinations.
Whether it's user ID to group association, user ID to known IP address, or user ID with valid domain password using a bloomfilter the firewall will never see any combination without SSL decryption for said SSL website.
Regarding your false positive examples, my guess based off what you showed is that "option 3" or "Domain Credential Filter" leverages a "bloomfilter" which is created by the credential agent. Just my guess is the bloomfilter just happens to match a value which is seen in the URI.
I've never seen an example of what a bloomfilter is which would match valid domain user id/pw, but that's just my guess on the reason for the false alerts.
02-12-2019 10:56 AM
The extra information was added for the community as a whole as it is a new feature.
You may be on to something. I haven’t calculated the entropy of the bloomfilter the pan generates to determine how likely a bloomfilter collision could be. I'm going to run some numbers on it.
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
