The Problem

Here’s the situation – you have a group of users who work a hybrid schedule.  One of the users, while working at home, gets malware from a compromised website.  That malware-infected PC gets taken back to the office and put on the corporate network, whereupon the malware now can try and spread to other devices.  How do we protect against this kind of situation?

Historically, tools to manage remote device security on the endpoint itself were limited in their security capabilities or had undesirable effects on user experience.  Alternately, remote users would be required to VPN into the corporate office at time of boot, where all traffic would be sent over the VPN for processing by the on-premises security stack.  The first issue is that with a lot of remote users, the corporate firewall and the internet connections would be put under considerable load, perhaps enough to demand a larger firewall and faster Internet connections.  Second, there is a problem with what happens when the endpoint is off the VPN – there is still the potential for malware or user misbehavior in this case.  Setting up endpoints for always-on VPN (the VPN tunnel establishes itself pre-logon, usually with certificate based authentication) is a possibility, but always-on VPN is notoriously complex and finicky to deploy, making it a poor solution for most organizations.

Advanced Threats

Another demand on security is the need for SSL decryption to detect threats.  Modern malware also uses SSL encryption, and as such, is much harder to detect without decrypting and inspecting that traffic.  SSL decryption on an on-premises firewall has a substantial performance impact, often cutting firewall throughput in half or more – this makes it impractical for the traditional full tunnel VPN option.

A New Defense

These days, we have better tools.  A whole class of services known as SASE (secure access services edge) have arisen in response to the need to secure a distributed workforce.  However, SASE services all differ quite a bit due to how they’re implemented.  Most services require some form of always-on VPN for connection to the SASE service with all the complexity that entails to avoid the problem of what happens when the user isn’t on the VPN to the SASE service.

Our preferred SASE solution for remote workers is Umbrella SIG, as it addresses all the common problems I’ve discussed above.  SIG works a bit differently than other solutions, as it doesn’t rely on VPN connectivity.  Instead, traffic destined for the Internet gets proxied through the Umbrella cloud, where SSL decryption occurs, followed by inspection and filtering for malware and content restrictions. 

Agile and Effective: Umbrella SIG

So, what can SIG do from a security perspective? Here are the key capabilities:

• File download scanning – files that match known malware signatures are blocked.
• File type control – disallow users from downloading risky file types. For example, no normal user needs to download a .dll file to their laptop.
• Detailed content filtering – block not just domains, but specific URLs within a domain. This is especially important with large, sprawling sites like Reddit that contain both legitimate and risky content.
• Data Leak Prevention (DLP) – scan Internet-bound traffic for well-known or user defined data patterns that match controlled data such as credit card numbers or intellectual property.
• SaaS Tenant Controls – keep users contained to the organization’s tenant for services like Microsoft 365.
• CASB – Discover ‘shadow IT’ SaaS application usage and block access to those apps as needed.
• Logging and Reporting – Get a clear picture of remote users’ Internet activities and what security events each user has caused.

SIG Simplifies Deploying SSL Decryption

Deploying SIG is much easier than most other SASE services. SIG has a streamlined deployment compared to other SASE services due to how it operates. As mentioned before, there is no need for always-on VPN or other invasive endpoint configurations that can break easily. Core features can also be implemented quickly – where there is complexity, it’s where it is inherent to the features available and not in setting up prerequisites. For example, SSL decryption will always need a certificate installed on the endpoint to not break the Internet, and choosing what to decrypt or not often needs input from other parts of the organization to ensure users’ private information isn’t compromised (think banking or medical information here – stuff that can cause liability to the organization by inspecting it.)

Your Umbrella SIG Deployment Guide

Here’s a guide to getting SIG up and running – this assumes that you currently have a fully functional Umbrella DNS deployment and want to expand that to SIG. I don’t go into the more complex features here, so consider this a starting point, not an authoritative guide.

Enable the Secure Web Gateway (SWG) capability remotely. Note that this requires the use of the new Cisco Secure Client (aka Anyconnect 5.0 or later) to work. SWG can be enabled globally or on a per-identity basis.

Install the Umbrella root certificate on the PCs/Macs to protect. Alternately, if you already have a local CA, your cert can be used in place of the Umbrella cert. Without this, enabling SSL decryption will completely break the Internet for the unfortunate users.

Next, define a list of categories, applications, and URLs to bypass SSL decryption. Some sites will need to be bypassed for functionality purposes (ex: Windows Update) while others will need to be bypassed for non-technical reasons (banking, health, or other sites that can leak protected information.)

Now it’s time to set up a SWG policy. First, we create a destination list (or several, as needs direct). Destination lists are how content filtering policies are applied. If you have a pre-built list of domains and URLs to filter, they can be imported into a destination list via .csv file.

Next, we configure the Web policy.

First, configure the global settings for the ruleset. This is where SSL decryption, file controls, logging, and general security settings are configured. Let’s start with SSL Decryption.

Enable the feature and associate a selective decryption list with it. Next, configure the other global settings as appropriate.

Following this, configure a ruleset for content filtering using the destination lists we created earlier. The individual rules follow the same mode of operation as an ACL – once a match occurs, traffic is either blocked or forwarded, so be careful of rule order to avoid shadowing. Be sure to add identities to each rule and ruleset for them to be applied!

Finally….

Test SWG settings before rolling it out to the entire organization. Note that once SWG is enabled globally, any endpoint with Secure Client and the Umbrella agent component will then forward all traffic to the Umbrella cloud to be proxied. No policy is applied unless identities are added to rulesets, so impact will be minimal until appropriate rulesets and identities are configured.