K12 Services - Web Security

MCNC Web Security Service Description


The MCNC Internet access service includes integrated, cloud-based web security functionality for Web Content Filtering and Advanced Security Protection. The multi-tenant environment allows LEAs and charter schools to manage and customize their web security policies.

The MCNC web security solution can be used by an LEA or charter school to replace or complement their existing content filtering solution. A LEA or charter school that wishes to keep their existing content filtering solution can still take advantage of the security protection features to provide an additional layer of security around their network perimeter. A LEA or charter school may also elect to only use the web security solution for remote and mobile clients.

MCNC has partnered with Zscaler® to provide the web security solution. This cloud service is offered by redirecting web traffic to Zscaler Enforcement Nodes (ZENs) that function as inline proxies to enforce filtering policy and provide security protection. Zscaler has extended their security cloud by installing private ZENs on the NCREN network that will be dedicated to handling MCNC client traffic.

This document outlines the features provided by the service, an overview the deployment methodology and other topics that technical directors will want to consider.

Service Features

Web Content Filtering

Granular Policy Enforcement

Content filtering rules can be created based on the identity of the user, group membership, the type of transactions (GET vs. POST), location, and time of day. Rules can be applied to existing and custom content categories. When a policy rule is matched, the connection can be blocked, accepted, monitored or caution the user with a warning message.

The use of sub locations allows a LEA or charter school to define a different set of policies for specific internal network IP ranges. For example, authentication can be disabled for the guest wireless network, while leaving it enabled for all other networks.

User-defined Categories

Administrators can define matching criteria based on a domain or sub-domain, a full or partial URL and custom keywords. The custom definitions can be added to existing categories, or to new categories created by the administrator.

Dynamic Categorization

Content is inspected as it is passes through the cloud to enable dynamic categorization of unknown sites.

Web 2.0 Controls

Web 2.0 features can be restricted to allow users to benefit from Web 2.0 capability while managing the risk to the environment. Selective access includes webmail with the ability to prohibit attachments, Instant Message services with the ability to block file transfer, and the ability to view social media, blogging and streaming media sites without being able to post messages or upload files.

YouTube EDU is currently supported by Zscaler and requires that SSL scanning be enabled to work properly. (Note: SSL scanning may cause issues with the Google chat and drive applications.)

SSL Inspection

SSL inspection enables granular policy control and security protection for SSL encrypted traffic. With SSL inspection, HTTPS traffic can be decrypted, inspected, and then re-encrypted as it passes through the Enforcement Node. Exceptions can be created by category or top level domain, so that trusted destinations are not decrypted. Exceptions are also supported at the proxy auto-config (PAC) file level for remote and mobile users. When SSL inspection is used, a Root Certificate signed by Zscaler needs to be installed in each browser to prevent certificate error messages.

Encrypted Transaction Blocking

Encrypted transaction blocking can be used as an alternative to decrypting SSL traffic for on-net users. SSL encrypted web sites can be blocked based on URL category or a custom list. Without decryption, the user is unknown. For this reason, the blocking policy for encrypted traffic applies to all users. Encrypted transaction blocking is only available for on-net users. Policy is not applied to SSL traffic from remote and mobile users unless it is decrypted and inspected.

Granular policy control and user level auditing always applies to HTTP and decrypted HTTPS traffic. The following table compares how SSL encrypted traffic is handled with SSL inspection enabled versus disabled, and how these features extend to remote and mobile users.


SSL Inspection Enabled

SSL Inspection Disabled


On Net

Mobile / Remote

On Net

Mobile / Remote


Configured on a site-wide basis.

Configured in the PAC file, per-browser.

Configured on a site-wide basis.

Configured in the PAC file, per-browser.

SSL Exceptions

Exceptions by category or top level domain.

No exceptions, all traffic is decrypted.



Policy Granularity

User and group level filtering and audit trail.

User and group level filtering and audit trail.

Site-wide policy applies to everyone, user unknown.

No filtering policy, user unknown.

Encrypted transaction blocking



Site-wide policy applies to everyone, user unknown.

Not available.

Advanced Security Protection

Anti-virus / Anti-malware

Each file is downloaded, assembled, uncompressed, and actively scanned for viruses before it is delivered to the end user. Large files are scanned in chunks so the user will begin receiving the file immediately. Files are also passively scanned by multiple commercial AV/AS engines concurrently in offline mode. Additional threat signatures uncovered by passive scanning are updated in the active scan capability across the cloud.

Malicious Active Content

Each web request and response is scanned for known browser exploits, vulnerable ActiveX controls, file format vulnerabilities and other malicious content such as hidden iframes, cross site scripts, signs of phishing attempts and cookie theft.

Communications Control

Web traffic is analyzed to detect P2P applications, traffic anonymizers, and bot-net command and control traffic. Traffic can be blocked according to site policy to prevent attempts to use file sharing programs, voice over IP and online chat programs that attempt to tunnel inside HTTP and HTTPS protocols. File-types can be detected and selectively blocked for over 300 types of files.

PageRisk Index

A PageRisk™ Index that takes into account use of suspicious techniques like javascript obfuscation and zero pixel images is calculated for each page served. This information is correlated with other factors such as GeoIPbased location of the website and its reputation to compute a dynamic risk index.

Management and Reporting

Granular Reporting and Analysis

Drill down reports provide a means to quickly understand user activity, categories of web sites visited, traffic volume and filtering policy compliance. Anti-virus and anti-malware reports show a breakdown of the types of threats that have been detected and the users that are posing the most risk to the environment.

Detailed analysis and filtering can be performed to gather information about specific users or trends across the environment. Graphical reports can be exported to PDF and detailed information can be filtered, analyzed and exported to CSV format. Report settings can be saved for frequently viewed reports. Reports can also be scheduled and sent to a list of email recipients.

Services that operate purely in the cloud, without client software, do not have the same level of visibility into the local environment that an appliance-based solution might have. The MCNC Web Security Service acting outside of the network address translation (NAT) boundary is not able to see the local IP address or the MAC address. Instead, the filtering policy and audit trail is based on the identity of the authenticated user.

Delegated Administration

Administrative roles can be created with full or partial access to delegate authority for management and / or reporting. User names can be obfuscated for administrative roles without full access.

User Authentication

The first time a user accesses the Internet they will be required to authenticate to the Web Security Service. During this initial session, an authentication token will be installed on their computer. If computers are not shared, the authentication token can be configured to last indefinitely. For environments with shared devices, users can be required to re-authenticate after each browser session or after more than a day of inactivity. The authentication settings apply globally to all users; they cannot be configured per user or per device. Zscaler also enables integration with federated identity systems via the use of SAML.

Device Support

All common browsers are supported on Windows, Mac and Linux platforms, regardless of the location of the user. Mobile devices such as smart phones, iPad, iPod touch, Motorola Xoom and other Android-based systems are also supported.

Support for content-filtering of remote and mobile users is available for most mobile devices through use of PAC files. Offsite Android-based device filtering is done by use of a vendor-supplied ‘Safebrowser’. The effectiveness of both PAC files and Android Safebrowser filtering is heavily-dependent on the configuration of the host mobile devices in order to prevent user tampering. LEAs or charter schools that plan to deploy these devices will need to consider device security measures in order to prevent users from changing the settings required to enforce filtering policy.

EZ agent is a lightweight application that automatically sets the proxy configuration for Internet Explorer, Chrome, Firefox, and Safari (Windows only) browsers so that when they are outside of the corporate network, their HTTP/HTTPS requests are forwarded to a ZEN. It installs as a Win-dows service that runs in the System Tray. It prevents tampering by end users by automatically checking the browser’s proxy setting every few seconds, and resetting them if they were changed or disabled by the end user. The service itself is password-protected so that only the network administrator can temporarily disable or uninstall the agent.

Service Deployment


When the service is provisioned for a new LEA or charter school, the LEA’s or charter school's publicly facing IP addresses are registered and a new instance is created in the multi-tenant environment. Once provisioned, MCNC can begin configuring the environment. MCNC will work with the LEA or charter school to configure user administration and authentication options, and migrate existing filtering policy. The final step is to establish the mechanism that will be used to forward traffic to the security cloud. Each of these topics is explained in the following sections.

Network Segmentation

The MCNC ZENs are deployed in a load balancing configuration which relies on the source IP address of a packet to direct session requests to the appropriate ZEN. In order to effectively utilize load balancing, LEA firewalls should be configured so that a least one unique public IP address is assigned to each school and network address translations are configured accordingly. Corresponding sub-locations for each of the unique IP addresses should also be created in the Zscaler UI.

User Administration

The recommended mechanism for most LEAs or charter schools is to synchronize with an existing directory service. Zscaler supports synchronization Active Directory, eDirectory and other directory services that support LDAP/LDAPS. With the directory synchronization option, user administration and password management is performed on the directory server. User name and group membership is imported and used for policy enforcement and reporting. Password data is maintained on the directory server which is queried by Zscaler to authenticate users. A firewall rule will need to be created to enable account synchronization and authentication from the cloud. Synchronization can be initiated manually or automated on a scheduled basis.

The hosted database option is an alternative to directory synchronization. With the hosted database configuration, user administration and password management are performed through the administrative UI and all user information is stored in the cloud. Users can be added manually or imported from a file.

Policy Migration

MCNC will work with the LEA or charter school to create a baseline configuration using the pre-configured categories to enforce the client’s filtering policy. New categories and associated rules will be defined to explicitly permit existing 'white listed' sites and explicitly deny existing 'black listed' sites.

Traffic Redirection

Once the policy rules have been configured, traffic can be redirected to the enforcement nodes. MCNC will use Generic Routing Encapsulation (GRE) tunnels to redirect traffic directly from an LEA to the nearest MCNC ZEN. In this scenario, two GRE tunnels will be configured on the LEA’s edge router. A policy based route will be created to route all traffic on ports 80 and 443 over the tunnel. If connectivity through one tunnel goes down, the router automatically switches to the secondary MCNC ZEN.

Remote and mobile users are directed to the closest ZEN by a proxy auto-config (PAC) file or a hard coded proxy setting. The user retains the same policy regardless of their location. PAC files don’t have the platform dependencies that client agents typically do. However PAC files have limitations, e.g. potential problems with captive portals, which should be discussed with the MCNC engineers during service evaluation.

Securing the Environment

The effectiveness of the content filtering capability relies on sound practices in system and network security. Depending on the configuration of the environment, the following commonly accepted security measures need to be considered:

  • Outbound traffic filtering using a ‘default deny’ stance are recommended as best practices in network security. A ‘default deny’ stance will force traffic to use well defined communication ports that can be monitored and controlled. This limits a student’s ability to use external proxies and tunneling to by-pass content filters. This also limits the paths that malware can use to communicate with outside world without first being inspected by the Enforcement Node. MCNC will help clients understand which firewall ports need to remain open to support existing applications.
  • Laptops and workstations should be restricted so that end users cannot modify proxy settings or download tools that may be able to circumvent content filters. Security patches should be kept up to date and other best practices for system security should be followed. This will reduce a student’s ability to escalate their privileges or otherwise bypass the restricted environment. In Windows environments where end-users have administrative access to the device, the EZ agent is recommended.