Allowing Uncategorized

You have really only three options:

1. Block the uncategorized sites and manually unblock case-by-case
2. Block the uncategorized sites and Allow the users to submit recategorization request to Netskope for non-critical cases where a 1-2 business day turnaround is acceptable
3. Allow the sites (recommended to have a threat policy enabled to scan for malware)

You may want to use a combination of the options above.

For option 2 I recommend adding this URL to your block page which will auto-populate the recategorization request:

https://www.netskope.com/url-lookup?url=https%3A%2F%2F{{NS_URL}}&email={{NS_USER}}

Something like this:

<p>If there is a business need to access this website please review the following options:
<b>If the request is not urgent</b>: click <a href="https://www.netskope.com/url-lookup?url=https%3A%2F%2F{{NS_URL}}&email={{NS_USER}}">here</a> to submit a web site recategorization request.

​@notskope 

Appreciate the response.  Looking at a few (non-public) reports of malicious URLs over the last day or so (with the majority of those being “credential capture” type), seems like the “scan for malware” option would (at least in those cases) be ineffective (let me know if I am mistaken) since we are not talking about code but rather a malicious landing page for someone to type in their credentials.  Further, and unfortunately, about 33% of those credential capture type sites I looked at (granted we are only talking about 9 in total over the last few days) were and still are as of today categorized as “Uncategorized” by Netskope --- so it does appear there is a realized risk here and not just theoretical.

What about having a policy where we are blocking Uncategorized, but only in combination with either “Post” actions (which in theory at least would prevent someone from actually submitting their credentials) as well as “Download” (which would prevent someone from downloading actual files which could contain malicious content) --- could in theory add in the use of and isolated browser session (not sure if these can all be used in conjunction) to deal with JS (drive-by type) threats. Thoughts? 

I really can’t see us using option 1since it does not scale and as I mentioned is just an exercise in futility.  Option 2 could work, but does not address the critical business process use cases where time is essential in making a business decision.

You may be able to use the “login attempt” and “upload” action criteria.

If that does not work as expected you may be able to creatively apply a DLP policy to look for keywords that indicate a phishing attempt.