.png)
Back in 2014 I wrote a blog on the different options available to Blue Coat ProxySG Customers for handling uncategorised websites (or the category ‘none’). At the time, the choice was limited being only 3-fold:
1. Block Access
2. Allow Access
3. Provide Coaching Pages to allow the user to decide
Jump forward a few years (from 2014) and Major Version Releases to SGOS 6.6.2.1 where the Threat Risk Level Intelligence Service was introduced. This service introduced (alongside the Blue Coat Web Filter Database) the concept of assigning a Threat Risk Level to URLs numbering from 1 (Low Risk) to 10 (High Risk). This additional metric gave Security Teams the ability to control access to a URL based not only on how it was categorised, but also based upon how risky the Blue Coat Intelligence Services Cloud found it to be.
The following gives an overview of the risk levels and how Symantec has reached this conclusion:
Low (Levels 1-2)
The URL has an established history of normal behaviour and has no future predictors of threats.
Medium-Low (Levels 3-4)
The URL has an established history of normal behaviour but is less established than URLs in the Low group.
Medium (Levels 5-6)
The URL is unproven; there is not an established history of normal behaviour.
Medium-High (Levels 7-9)
The URL is suspicious; there is an elevated risk. Symantec recommends blocking at this level.
High (Level 10)
The URL is confirmed to be malicious. Symantec recommends blocking at this level.
You might ask yourself, if a URL already has a category, why do I need a Threat Risk Score as well to control access?
There are two answers to that question:
1. Improved handling of the category ‘none’ (or uncategorised). 2. The ability to permit access to middle of the road categories i.e. categories you may be unsure whether to allow or block completely.
To understand why threat risk scoring can help, we need to understand how threat risk scoring plugs the gap where categorisation fails.
If a client makes a request to a URL (via a Symantec Secure Web Gateway licensed with Symantec Intelligence Services) that is not currently present in the local database, the URL will automatically be passed to the Dynamic Real Time Rating (DRTR) service in Symantec Global Intelligence Network (in the cloud). The DRTR service is a module based Artificial Intelligence (AI) engine comprising of over 300 modules that each look for specific characteristics to help determine the category of a site. Each module can then vote on what category (or categories – Symantec supports up to 4 categories per URL) a URL belongs to all within a fraction of a second upon retrieval of all content. However, in some instances, not enough votes are stacked up to conclusively return a category. This results in the return of the category ‘none’. Back in 2014 this is where the story ended.
Today, where the DRTR service was unable to acquire enough votes to conclusively identify the category of a site, Symantec realised that votes from key modules could be used to determine how risky a given URL might be. To further bolster Symantec also developed three new systems to work in conjunction with the DRTR service to provide higher assurance of the assigned threat risk level. Information on these three systems can be found (and better explained) in the following White Paper under the title “Where Threat Risk Levels Come From” – Page 03
So now we understand how Symantec can provide a risk score rating in the absence of a category, we now have the ability to apply more bespoke controls to handle the category none based upon our risk appetite.
Where before Security teams would look to simply block access to the category none or implement Coaching Pages to allow the user to decide whether they intended to visit the URL they have entered/clicked to visit, they now can combine the category none with a risk level. As the risk level 1-2 is deemed to be safe, a security team can have confidence that although there is no specific URL category, traffic to a URL with this threat Risk score can be allowed. Risk Level 3-4 follows suit. Risk Level 5-6 is the grey area where a security team needs to consider its risk appetite. As the category none was assigned due to limited information being available, coupling that with a risk rating score of 5-6 where there is no track record of good or bad behaviour could be a bad choice and open the organisation up to threats. Typically for Risk Level 5-6, I would recommend Security teams block or even perhaps combine coaching pages to allow the user to decide. Risk levels 7 through 10 should be blocked with the category none and even should be considered for outright blocking across all URLs.
Earlier I mentioned that threat risk scoring could be combined with middle of the road categories to provide enhanced protection for an organisation. Take for example the Software Downloads category. Downloading software could be considered a risk to an organisation. In fact, I have seen a number of organisations block access to this category outright. However, what if the Software Downloads category was combined with the risk scores 1 through 4 or even 6 for example? Organisations could feel more confident that software from these reputable URLs are considered safer.
In conclusion, the introduction of Threat Risk scoring has introduced the ability for Symantec to provide organisations with a calculated opinion on URLs being requested by clients. The combination of Threat Risk scoring with the category none allows organisations to be more permissive of client requests thus removing the need for blanket blocks or coaching pages (although both still can be utilised). As a result of the increased permissiveness, organisations should see reduced calls to the service desk and hopefully a reduction of URLs being entered into static white lists to override any blanket blocks.
