Endpoint HTTP/HTTPS False Positives - Cookies

[ThunderHorse]

In my environment, we utilize both the following Data Identifiers in our Endpoint Detect policies:

• Randomized Social Security Number Patterns
• US Social Security Number Patterns

Both of these Data Identifiers are configured to use the Narrow Breadth and have not been modified from their original design (using all of the standard/default RegEx Patterns, Validation Checks, etc.)

I find that both of these identifiers will frequently detect false positives in the HTTP/HTTPS protocols due to certain tracking cookies that match these identifiers.

Examples:

• Google Analytics Tracking/Targeting Cookies (https://developers.google.com/analytics/devguides/collection/analyticsjs/cookie-usage)
  • __utma
  • __utmb
  • __utmc
  • __utmz
• HubSpot Tracking/Targeting Cookies (http://knowledge.hubspot.com/cookies)
  • __hssc
  • __hstc
• Unknown, but common cookie (https://tools.digitalpoint.com/cookie-search?name=OX_ssn)
  • OX_ssn

For now, my process has been to research and document the purpose and typical use of these cookies through online research. Once documented, I then build a policy exception using RegEx to exclude these specific cookies.

I'm curious if others have experienced this same problem? If so, how did you tune these out? Do you have any good resources for performing research on what the cookies are used for to help document and provide justification for tuning them out?

Thanks in advance!

[jjesse]

 

Yes I deal with this all the time... As a consultant I come across this all the time.  One of things I try to exclude is the phrase or keyword "utma=" as this is used a bunch of times by various cookie companies or provider.  Also I see this a lot w/ Target.com cookies and Instagram Cookies.

Subscribing to this thread to help w/ a converstation around this.

[ThunderHorse]

jjesse,

As I alluded to above - I have had the best luck building policy exceptions using the Content Matches Regular Expression condition to match based on RegEx within the body of HTTP/HTTPS messages. However, it still causes some administrative pain to have to build these whenever another cookie starts throwing false positives.

I've included plain text copy of the RegEx and screenshots of the policy exceptions included below for your benefit. Still interested to see if someone else has found a better methodology for these.

 

Google Analytics RegEx

__hs[zst]c=\d{9}

 

HubSpot Analytics RegEx

__hs[zst]c=\d{9}

 

[jjesse]

Thanks for posting the Regular Expressions that you use.  I wish there were more and more people collaborating on these types of issues here, but unforntately it seems people like to stay silod and not share their data or answers.

Hopefully more people can post to this thread

[RonCaplinger]

I have encountered so many that a Regex isn't sufficient anymore.  I have modified the Data Identifier for those two to include an Exclude Prefix and added all of the various incarnations of prefix characters I have found:

pool=,"id":,"offset":,"planCourseId":,"requestId":,"UserTrackId\":,&a=,&m=,&z=,\"UserTrackId\":,__user value:,_reqid value:,_subject_uid,_utma=,_utmb=,_utmc=,_utmn=,_utmv=,_utmz=,“user":",a.,ac value:,ac=,amp;,AutoWhiteVersion=",av=,cb value:,cb=,document ID,doi:,endTime=",id=,LocID=,name:,pc value:,pc=,pi value:,pi=,SessionID:,si=,user:,utmhid=,ValidDpci=,value:,www-prd_ch=

[ThunderHorse]

I agree wholeheartedly - I expected a thriving support community around this product. Have had very mixed results with support and there isn't as much collaboration amongst the user community as I would like. I'm personally always looking for networking opportunities and appreciate having a sounding board for questions like this. Thanks for joining the conversation.

[ThunderHorse]

Ron - thanks for confirming that I'm not alone and thank you for sharing your approach. I may have to consider something similar to help reduce the noise.

[jjesse]

I think this forum is the wrong place for growing this type of discussion. This thread will never be "marked as solved" sicne we will always be discussing this.  I'm going to reach out to the Connect staff and see if there is a better way of doing this.

 

[ThunderHorse]

Hey Ron - I don't know if you are still following this thread. We've attempted to implement the approach you describe above. Specifically, we have a high false positive rate on the "si=" prefix. However, the problem is persisting even after creating custom Data Identifiers using the Exclude Prefix validator with "si=" as a value.

When viewing the raw HTTP POST message, I see the following:

si=593100693

When viewing the Message Body within DLP, it is displayed a little differently:

Based on your previous post, this is one of the prefixes you've also experienced some issues with. Any input you could provide is appreciated! I see that you did include "value:" as one of your prefixes. I'd like to entertain the idea of adding that as another prefix, but the concern would be increasing our false negative rate.

Any input is appreciated!