Secure Internet Access – User Guide

Secure Internet Access – User Guide

1. Introduction

Securing today’s cloud- and mobile-first enterprise requires a fundamentally different approach built on zero trust. Exium Secure Internet Access (SIA) is a secure internet and web gateway delivered as a service from the cloud. Think of it as a secure internet onramp—all you do is make Exium your next hop to the internet. No matter where users connect—a coffee shop in London, a hotel in Tokyo, or the office—they get identical protection.

Exium SIA uses the latest 5G networking and security technology to deliver a malware-free internet experience for your users. Internet security is essential and when it is coupled with an outstanding user experience it makes things a lot easier for both users and the company.

The trend in work-from-anywhere and BYOD policies means your employees are connecting to trusted and untrusted websites and SaaS applications around the clock. Using personal devices to access these third-party web services puts your corporate data and organization at considerable risk.

With Exium Secure Internet Access, employees can safely connect to SaaS apps, click on web links, and open email attachments without the fear of infecting their devices. Our Intelligent Cybersecurity Mesh or CyberMesh lets you embrace the cloud with the confidence you need to keep your distributed workforce secure wherever they are.

Unlike traditional solutions that require integrating separate point products, Exium SIA combines the best of secure web gateways, intrusion detection and prevention services, DNS, and CASB offerings into a single, easy-to-use, and cost-effective cloud-based service.

How it works?

Adjacent to the internal applications running in a public cloud, data center, or on-premise server, SPA places a small piece of software called Cyber Gateway (CGW), deployed as a container or a VM, which is used to extend a highly secure Zero Trust Path out to the Intelligent Cybersecurity Mesh.
The CGW establishes an outbound connection, and does not receive any inbound connection requests, thereby preventing DDoS and other cyberattacks. Private Access utilizes a lightweight Exium Client installed on a Microsoft Windows, Apple macOS, iOS, Android, or a Linux device. The Exium Client steers Private Access application traffic to the Exium Intelligent Cybersecurity Mesh using either DNS or the IP address.
Moreover, within Exium service, both the user devices and the CGW use battle-tested hardware root-of-trust eliminating credential theft and man-in-the-middle attacks. A Mesh Cybernode approves access and stitches together the user-to-application session. SPA is 100 percent software defined, so it requires no appliances and allows users to benefit from the cloud and mobility while maintaining the security of their applications.
SPA provides zero trust, secure remote access to internal applications running in public cloud environments or private data centres, reducing risk, and simplifying security operations. With SPA, applications are never exposed to the internet, making them inaccessible to unauthorized users.

2. Create Workspace

Navigate to https://speerity.net
Click on “Create new workspace”

Fill all mandatory details on next page to create workspace.
First name
Last name
Email address
Phone number
Workspace name (Please try combinations of lowercase letters and numbers only)
Partner code (Optional – If not available, leave it empty)
Click on checkbox “I’m not a robot”
Click on “Create Workspace”

A verification email will be sent to the email address provided by user.

Workspace creation will start when user clicks on verification link and verifies its identity.

After workspace creation, Admin Console of workspace will be displayed.

Name of the workspace will be displayed at the left bottom of the page.

3. Login to Workspace

If admin has already created the workspace, then they can navigate to below link to login to their workspace.
https://speerity.net/speerity/sign-in
Enter workspace name and click on “Continue”.

Enter username and click on “Continue”.

A verification email will be sent to user’s registered email address and as SMS on registered mobile number. User can click on either of the link to verify the account.


After user clicks on verification link, verification will open and close automatically. User can navigate to earlier login page which will now show admin console of the workspace.

Name of the workspace will be displayed at the left bottom of the page.

4. User Group Creation – Manual

Skip this section/step if Azure AD or Okta is being used for user on-boarding. User groups will be ported directly from Azure AD / Okta after integration.
Below steps describe how user groups can be created manually.
After login to workspace on admin console, navigate to “Users” page.

Select “Groups” under “Users” option. To add a new user group, click on the “Add user group” option.

Add user group name (leave rest optional fields empty, those can be updated later). Click on “Save” to finish creation.

User groups creation can help admins to on-board users if they are using bulk provisioning using csv method.

5. Users On-Boarding

There are multiple ways admin can on-board users on workspace.

  1. Manual user creation
  2. Upload/on-board users using CSV file
  3. Azure AD integration
  4. Okta integration

Note: In case of Azure AD or Okta integration, manual user addition won’t be possible. User management will happen always from Okta or Azure AD.

5.1 Manual User Creation

After login to workspace on admin console, navigate to “Users” page.

On “Users” page, click on “Add User” button.

Fill all below mandatory details and click on “Save” button.
First Name
Last Name
Phone (Put country code and add contact number)
Email
Subscription (By default SIA will be selected, admin can enable SPA and other options)

Follow the same procedure to add other users manually.

5.2 Upload/On-Board Users Using CSV File

After login to workspace on admin console, navigate to “Users” page.

Click on the “?” symbol next to “Upload Users” option.

A csv file “User_Upload_UserFlow.csv” will be downloaded, right click on the file and select “Open with” option. Choose “Notepad” application to open/edit the file.

Go to next line and add entries as shown in below example:
Department and Group are optional in below example so they left empty.

Save and close the file.
Again double click on the file to open it, and use option “Save as” to save the file in csv format.
On admin console “Users” page, select option “Upload Users” and select the csv file saved in above step.


Users present in file will be on-boarded if the file format and entries are in correct format. In case of wrong format, admin console will through an error while uploading the file.

5.3 Azure Active Directory Integration

From single sign-on to enhanced user provisioning Azure AD’s Speerity integration handles users and groups seamless access to Speerity service. Administrators can easily attach Speerity security policy groups to Azure AD user groups.
The following provisioning features are supported by Speerity at present:

  • Assign Users to Speerity app on Azure:
    • Users can be assigned in Azure AD to the Speerity application.
  • Assign Groups to Speerity app on Azure:
    • Users can be assigned in Azure AD to the Speerity application.
  • SSO using Azure AD:
    • Users who have downloaded Speerity app are authenticated using Azure AD SSO.
  • Push New Users/Groups:
    • Users/Groups in Azure AD that are assigned to the Speerity application in Azure AD are automatically added as members to your workspace in Speerity.

Below are the mandatory requirements for admins to integration Azure AD:

All the users configured in Azure AD have email configured (User – Contact Info > Email)

5.3.1 Configuration Steps

5.3.1.1 Enable Azure AD as sign-on setting on Speerity workspace

Click on the workspace name displayed at the left bottom of the admin console page. Click on “Profile” option:

Click on “Sign-in” setting and select “Azure”:

Note down SAML configurations, these will be used on Azure enterprise portal for adding Speerity application.

5.3.1.2 Speerity App Addition on Azure AD

On Speerity app,  click on ”Getting Started” > “Set up single sign on”. On “Set up Single Sign-On with SAML” page, click Edit on ”Basic SAML Configuration”. Copy SSO URL and Entity Id from Step 1 and save as shown below.

Copy “App Federation Metadata URL’ from “SAML Signing Certificate” as shown below to Speerity workspace “Sign-in setting” to “IDP Metadata URL” and save as shown below.

5.3.1.3 Enable Azure AD provisioning to sync users and groups

On Exium app, click on “Provisioning User Accounts” -> “Getting Started”

Copy “SCIM Bearer Token’ from “SCIM” tab on Speerity workspace. On Azure AD “Provisioning”, select “Automatic” and paste copied token as “Secret Token”, select remaining settings as shown below and click on save.

5.3.1.4 On-Boarding of Users

On Azure Speerity app, click on “Users and groups” on left bar, click on “Add user/group”. Click on Users (“None Selected” on left bar, Search and select users or groups on right pop up, click “Select”. Finally Click “Assign” on left bottom as shown below.

Note:

  • After this step, selected users/groups will be able to use Speerity client by doing SSO to Azure AD. Users have to be informed about workspace name and Speerity client download details.
  • Azure AD default syncing time is 40mins. Anytime if you want to fasten up the sync, you can use “Stop Provisioning” and “Start Provisioning”.

5.4 Okta Integration

To be added/updated

6. Policies

Policies or rules are the mechanism to restrict user internet access to provide the security and controlled environment. Admins can create policies/rules and restricts user’s access to specific URLs/domains.

6.1 Policy Levels

6.1.1 Individual User Level Policy

Rules can be created and associated to specific users as per requirements.
In production environments, admins get requests from different users to provide access to them for some URLs which are blocked as per policy. These user requests could be related to business, organization or customer related. In such cases, admins can create individual policies and assign those to users. These policies will have higher precedence over group or workspace level policies.
Click on “Rules” under “Policies” section.
Select “Unassigned” from drop down list as shown below.
Click on “Add Rule” button.

Input page will appear where admin can enter details. It will also show warning that current rule is “Unassigned” so it will not be applied to workspace, group or any user.

Fill the details as per requirements and save. For more details on policy types, please refer section 6.3
Fill the details as per requirements and save. For more details on policy types, please refer section 6.3
Admin can also configure/modify “Validity” of the policy. Available validity options can be found by clicking on drop down list. Admin can set custom range by entering the time of the day. Also, validity can be configured with “Repetitive” option. Admin can select days of the week and time of the day. For eg., admin can apply policies for working days (Monday to Friday), between 9:00AM to 5:00PM.

Validity of the policies can be modified at any point of time as per requirements.
To assign new policy to an individual user, navigate to “Users” page. Select the user to edit/update its profile.

From drop down list, type name of the policy created for individual user and select it. Click on “Update” to apply or select other individual policies and save them all.

6.1.2 User Group Level Policy

Rules can be created and associated to one or multiple user groups.
In production environments, organizations or business units will have different set of user groups. Each user group can be configured with limited or restricted access to internet. Different set of policies can be created and associated to one or multiple user groups. These policies will have higher precedence over workspace level policies.
Click on “Rules” under “Policies” section.
Select user group from drop down list as shown below.
Click on “Add Rule” button.
Input page will appear where admin can enter details.

Fill the details as per requirements and save. For more details on policy types, please refer section 6.3
Admin can also configure/modify “Validity” of the policy. Available validity options can be found by clicking on drop down list. Admin can set custom range by entering the time of the day. Also, validity can be configured with “Repetitive” option. Admin can select days of the week and time of the day. For eg., admin can apply policies for working days (Monday to Friday), between 9:00AM to 5:00PM.

Validity of the policies can be modified at any point of time as per requirements.
If user is already part of the user group (for eg. Development user group), new policy will be automatically applied to the user. Admin can make user part of the user group to apply the policies.
To assign user group to an individual user, navigate to “Users” page. Select the user to edit/update its profile.

From drop down list, select user group. Click on “Update” to apply.

6.1.3 Workspace Level Policy

Rules can be created at workspace level. Rules/policies will be applied to all the users available in workspace irrespective of their user groups.
In production environments, organizations or business units can configure and enforce common restrictions / limitations to all the users by configuring rules as per company/organization policy. Workspace level policies will be applied to all the user, and they will have lower precedence.
Click on “Rules” under “Policies” section.
Select “Workspace” from drop down list as shown below.
Click on “Add Rule” button.

Input page will appear where admin can enter details.

Fill the details as per requirements and save. For more details on policy types, please refer section 6.3
Policies will be enforced immediately on existing users and new users when on-boarded will have these policies automatically associated to their profile.
Admin can also configure/modify “Validity” of the policy. Available validity options can be found by clicking on drop down list. Admin can set custom range by entering the time of the day. Also, validity can be configured with “Repetitive” option. Admin can select days of the week and time of the day. For eg., admin can apply policies for working days (Monday to Friday), between 9:00AM to 5:00PM.

Validity of the policies can be modified at any point of time as per requirements.

6.2 Policy Precedence/Priority

Highest priority – Individual user level
Intermediate priority – User group level
Lowest priority – workspace level

Example: Policies created at workspace level will be overridden by the policies created at user group level. User group level policies will be overridden by the rules or policies created or associated at individual user level.

Admins can navigate to “Policy View” page to monitor the policies assigned at different levels with their priorities.
For example:

  • Assume that there are no policies configured at any level. Admin creates policy at workspace level to block “Facebook.com”
    • “Facebook.com” will be blocked for all the users irrespective of their user groups.
  • Assume that policy to block “Facebook.com” is configured at workspace level. A user group called “Business_users” is configured on admin console/portal. Admin creates a new policy to allow “Facebook.com” and associates this policy to “Business_users” user group.
    • “Facebook.com” will be allowed for the users who are part of “Business_users” group and rest other users in workspace will not be able to access it.
  • Assume that two policies are configured. One at workspace level and another at user group level. Workspace level “Facebook.com” is blocked and it is allowed for “Business_users” group. “John A” is part of “Business_users” group. Admin creates another policy to block “Facebook.com” and assigns that policy directly to “John A” user on admin console/portal.
    • “John A” will not be able to access “Facebook.com” even if it is part of “Business_users” group. Rest other users of “Business_users” group will be allowed to access “Facebook.com”

6.3 Policy View

Under “Users” page, click on the “Policy View” link. Admin can select specific user from drop down list and display the policies enforced under different precedence/level.

6.4 Types of Policies Supported

Admins can select action, type of policy, and provide the value in filter to create the policy. There are different types of policies admin can create:

6.4.1 Content Based Policy

Known domains are already part of the system configuration to provide help to admins. Admin can start writing the name of the domain they would like to use as filter, they can select the same if domain appears in the drop-down list. If domain name does not appear, admin can write full domain name in filter input as shown below.

  • Provide the name of the rule/policy
  • Select action “Allow/Block”
  • Select type “Content”
  • Type app/domain name in filter input and select from drop down if it appears on screen. Admin can add domain name directly to the filter input
  • Select validity according to requirement
  • Click on “Save” to finish

Before saving the configuration, please check if correct identity is selected (User group / Workspace / Unassigned). This information will be shown above the name of the policy admin is creating “Currently assigning to User Group(s)”.

6.4.2 IP Based Policy

Admins can block or allow specific IP or subnet access to users/groups. These IPs/subnets can also be configured with known or custom protocols to restrict user/group access. Admin will also have advantage to configure custom TCP or UDP protocols with IPs/subnets. Admin can use single IP or a subnet in IP* field/input.

  • Provide the name of the rule/policy
  • Select action “Allow/Block”
  • Select type “IP”
  • Enter IP address or subnet in filter input and select known protocol from drop down list. Admin can also add custom TCP/UDP ports to the filter input.
  • Select the port if it is a known protocol or enter the port number if protocol type is custom TCP or UDP
  • Select validity according to requirement
  • Click on “Save” to finish

Before saving the configuration, please check if correct identity is selected (User group / Workspace / Unassigned). This information will be shown above the name of the policy admin is creating “Currently assigning to User Group(s)”.

6.4.3 QoS Based Policy

Admin can configure QoS based rules/policies and restricts user’s uplink and downlink bandwidth. In production environments, organizations will have different user groups and these user groups may not require full bandwidth to carry out their office work. Admin can arrange different policies with different set of QoS configuration and assign them to respective user groups.

For eg. Developer user group may require higher bandwidth and HR group may require moderate. Admin can create 2 different QoS policies and associate them to their respective use groups.

Developers – UL 10Mbps, DL 20 Mbps
HR – UL 5Mbps, DL 10 Mbps

  • Provide the name of the rule/policy
  • Select action “Allow/Block”
  • Select type “QOS”
  • Enter Upload and Download limits (Mbps) in the filter input.
  • Click on “Save” to finish

Before saving the configuration, please check if correct identity is selected (User group / Workspace / Unassigned). This information will be shown above the name of the policy admin is creating “Currently assigning to User Group(s)”.

6.4.4 OS Based Policy

An organization or it’s business unit may have policies to only allow user devices (laptops/desktops/mobiles) with specific Operating Systems. Admin will have advantage to configure such policies and allow/block specific OS.

  • Provide the name of the rule/policy
  • Select action “Allow/Block”
  • Select type “OS”
  • Select Operating System type from filter input drop down list.
  • Select validity according to requirement
  • Click on “Save” to finish

Before saving the configuration, please check if correct identity is selected (User group / Workspace / Unassigned). This information will be shown above the name of the policy admin is creating “Currently assigning to User Group(s)”.

6.4.5 Data Limit (DL) Based Policy

Production environment of an organization may have policies to block users from accessing their private or customer database. It is also possible that they may have policies inside organization to allow limited downloads from any of the private or public network on their devices. Admin can configure “Data Limit(DL)” based policies to handle such requirements.

For eg., if admin selects action “Block” and Download filter 20KB then users or that group/workspace won’t be able to download any file which is more than 20KB in size.

  • Provide the name of the rule/policy
  • Select action “Allow/Block”
  • Select type “Data Limit (DL)”
  • Enter Download limit in KB
  • Click on “Save” to finish

Before saving the configuration, please check if correct identity is selected (User group / Workspace / Unassigned). This information will be shown above the name of the policy admin is creating “Currently assigning to User Group(s)”.

6.5 Policy Configuration Examples

Few examples of content-based policies (block/allow) for admin user group.

Examples of IP based policies (block/allow) for admin user group.

Examples of QoS based policies (block/allow) at workspace level.

7. Web Categories

URLs/Domains are categorized and provided on admin console to restrict/control user’s internet access. List of the web category will be available for admins to assign to user groups or at workspace level.
Select the “Web Categories” available in “Policies section”.
Select the user group or workspace from drop down list.
Select the action “Allow/Block” provided against each web category.
Admin can create web categories for different user groups and edit them later as per requirement.

After creating or editing the web categories configuration, admin must click on “Submit” button.

7.1 Priority/Precedence for Web Categories

User group level web categories will have higher priority/precedence than workspace level.
Rules/policies will have higher precedence than web categories.

For eg., users of group “Developer” will not have access to “Social Networking” if admin blocks same web category for user group “Developer”. Users will not be access Facebook.com because it falls under social networking web category.

Individual policy to allow Facebook.com can be configured (under “Rules” page) for “Developer” group to allow access to Facebook.com. Rest other social networking domains will still be blocked for the users.