Qualifiers

Qualifiers consist of one or more criteria that describe a device or user. Qualifiers are listed in the chart below.

A qualifier can be added by choosing “Qualifier Menu” > “Qualifiers” and then choosing one additional sub-tab.

Single IP

A single IP can be added by choosing the “IP” sub-tab, entering the IP address and clicking save. Before an IP address can be enforced, a subnet mapping must be created in the configuration pages.

IP Range

An IP range can be added by choosing the “IP Range” sub-tab, entering the start and finish IP Address and clicking save. Before an IP Range can be enforced, a subnet mapping must be created in the configuration pages.

An IP range can be added by choosing the “IP Range” sub-tab, entering the start and finish IP Address and clicking save. Before an IP Range can be enforced, a subnet mapping must be created in the configuration pages.

IP Subnet

An IP subnet can be added by choosing the “Subnet” sub-tab, entering the network address, choosing the mask and clicking save. Before a subnet can be enforced, a subnet mapping must be created in the configuration pages.

An IP subnet can be added by choosing the “Subnet” sub-tab, entering the network address, choosing the mask and clicking save. Before a subnet can be enforced, a subnet mapping must be created in the configuration pages.

User Roles

An LDAP user or Guest role can be added by choosing the “Role” sub-tab, entering the Role name and clicking save. Guest roles must first be created in the configuration pages.

Usernames

An individual username can be added by choosing the “User” sub-tab, entering the username and clicking save.

MAC Address

A MAC address can be added by choosing the “MAC Address” sub-tab, entering the mac address and clicking save.

Device Attributes

A Device attribute can be added by choosing the “Device Attributes” sub-tab, selecting the source, attribute name, entering the value and clicking save.

For Cisco Wireless, before location attributes can be used, ensure that under “Security > RADIUS > Accounting” “Acct Called Station ID Type” is set to "AP MAC Address:SSID".

Qualifier Sets

After qualifiers have been defined, qualifier sets must be created. Qualifier sets have an implied OR condition between their qualifiers. There are four qualifier archetypes, defined in the chart below:

A qualifier set includes one or more qualifiers of the same archetype.

A qualifier set can be created by choosing “Qualifier Menu” > “Qualifier Sets”. From here, click “New” and enter a name, select an archetype and the desired qualifiers. Once completed, click the save button.

To locate an existing qualifier set, use the instant search box on the left.

Qualifier Containers

A Qualifier container includes two or more qualifier sets. Every qualifier container must contain a single machine type qualifier set and one or more additional qualifier sets. A qualifier container can only contain one qualifier set for each of the four archetypes. Qualifier containers have an implied AND condition between their qualifier sets.

A common qualifier container could combine a host type of Windows with a network set containing an IP range, and an identity set containing the faculty LDAP role. In this use case, a user must be on a Windows device, while connected to one of the defined IP range, AND authenticated with faculty credentials to match on this container.

This specific configuration can be used to prevent internal users from accessing Guest networks, for example.

A qualifier container can be created by choosing “Qualifier Menu” > “Qualifier Container”. From here, click “New” and enter a name, select no more than one qualifier set for each archetype. Once completed, click the save button.

Check one of the Archetype boxes (Machine Types, Networking, Device, Identity) to show only Sets of that type.

To locate an existing qualifier container, use the instant search box on the left.

Policies

Policies define the posture assessments to be enforced in a given policy group, and how failed assessments are enforced. The chart below gives an overview of policies and how they can be enforced.

Creating policies is done by selecting the sub-tab that corresponds with the policy that will be enforced:

Once the "what" has been defined, the "how" must also be defined. Enforcement actions can be an audit, warn, quarantine, or a mix of multiple warnings followed by a quarantine. This table describes each:

A policy can be created by choosing “Policies Menu” > “Policies”.

When choosing an enforcement action for a policy, several common choices are available as shown in the screenshot. All policies, except for Authentication, Policy Key and Always Block allow the choice of how to enforce. A custom enforcement option is provided for cases where the common choices will not suffice for the environment. To use custom enforcement, choose the “Custom enforcement” option from the dropdown and then choose “edit”.

When using custom enforcement thresholds, up to 4 enforcement actions can be chosen. If multiple actions should be taken, all but last action must be either Temporary Warning or Temporary Quarantine. The final action can be set to any item. Temporary actions, or a recurring warning, require a duration to be set.

Each action is outlined in the table below.

Authentication

To use authentication, choose the “Authentication” sub-tab, selecting an Authentication Scheme, selecting an Authentication web message and choosing an authentication frequency. OPSWAT recommends SafeConnect administrators always check the “Use HTTPS for authentication” checkbox to ensure users are submitting credentials securely. Once complete, click on the “Save” button.

Authentication Best Practices:

Authentication is often the most visible component of any SafeConnect deployment. As such, it pays to put some thought into how often users should be required to authenticate.

Extremely frequent, or untimely, authentication can result in a frustrating end user experience. This can lead to a difficult end user relationship with Help Desk or Networking personnel. Examples of frequent authentication include:

• Force re-authentication every X hours – This option is typically only recommended for Guest networks, where it is not important to allow users long periods of uninterrupted access. Frequent interruptions may even be desirable since they encourage users to move to different network segments. This option should be used with extreme caution on wired networks since it will likely interrupt users during an active internet session. This option should never be used on secure wireless.

• Every Login – Since users often log out and back in several times per day, forcing a manual authentication each time can be perceived as excessive.

On most production networks, it’s best to provide users with longer periods of uninterrupted access. Examples of longer authentication periods include:

• One Time – Prompts users for credentials when they first enter the network on a given device, then persists the correlation of username to device indefinitely, if the device accesses the network every 30 days.

  • This setting can be especially helpful on open wireless networks, where endpoints will typically pick up an IP address, even if the end user is unaware of being connected to the network. On router enforced networks, one-time authentication ensures that the Impulse_Block Access List contains as few unnecessary IP addresses as possible.

• Every Session Provided X hours have passed – Gives users several hours, during which they can log out and back in as many times as they like, without being prompted for authentication.

  • If set to 168 hours, the user will be prompted to authenticate at most once per week, and never during an active session. This is a very popular choice for wired networks.

  • If set to 720 hours, this will allow a full 30 days between authentication prompts.

• Force Authentication on DATE – Fails everyone in the authentication policy on the specified date. This is commonly used in education environments where admins want to re-authenticate all users at the start of a new session or semester.

NAT Policy

NAT (Network Address Translation) detection allows SafeConnect to identify machines that are behind an unauthorized personal router. This functionality is only available to Policy Key devices. NAT Detection works by comparing the DHCP assigned upstream IP address to the local IP address of the machine as reported by the Policy Key. If the Policy Key reported local IP address does not match the DHCP assigned IP address, the machine will be flagged for failing NAT detection. To use NAT detection, choose the “NAT” sub-tab and selecting the enforcement level. Once complete, click on the “Save” button.

AntiVirus

SafeConnect contains a comprehensive and up-to-date list of antivirus software for both Windows and Macintosh machines. In situations where domain managed machines require a specific antivirus package, the Policy Manager can be used to select only the approved package. For other machines that do not require a specific antivirus, select all the antivirus packages in the list.

To use anti-virus detection, choose the “Anti-Virus” sub-tab and select the anti-virus packages to check for. Alternatively, checking the “Let the system manage AV Packages” will enable all anti-virus packages by default. This option is the only way to automatically include any new AV packages that become available. Once Anti-Virus packages have been selected, a separate enforcement level must be set for Installed, Running and Definitions. Once complete, click on the “Save” button.

Windows Update

When a Windows Update patch policy is in place, if a user has Windows Update set to download and install, they will always pass the OS update policy regardless of how strict the requirements are configured. To use patch settings detection, choose the “Windows Update” sub-tab and selecting the patch policy and enforcement level. Once complete, click on the “Save” button.

If an on-site WSUS server should be used, select “WSUS Server” from the Patch Policy dropdown. A box will appear where a registry key can be placed. The registry key can be obtained from any machine that is already configured to use the WSUS server. From regedit, export the registry key below, then copy and paste its contents:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

End of Life Policy

When an End of Life policy is in place, devices with the major OS version designated will fail policy. To use patch settings detection, choose the “End of Life” sub-tab and select the OS versions to mark to treat as End of Life along with the enforcement level. Once complete, click on the “Save” button.

Block Access

The Block Access policy is useful for creating catch groups where users will not be allowed access until they have authenticated. After authentication, they will move to another policy group based on their end user role. To use an always block policy, choose the “Block” sub-tab and select the web message from the dropdown. Once complete, enter a name and click on the “Save” button.

Block access policies should only be used in situations where a remediation path is available, and an appropriate remediation page is going to be displayed to blocked users. SafeConnect is not intended as a solution to block unwanted users in masse but to ensure that users are in compliance with an organization’s AUP. The two most common scenarios where a block access policy can be used are as follows:

• WPA2 Enterprise On-Ramping – When using WPA2 enterprise wireless, there is often a need to have an open SSID with instructions directing the end user to set up their system for WPA2 enterprise. The block policy will have a custom block message containing the on-ramping instructions.

• Device Enrollment – Gaming and media devices will be placed in a device blocking policy group upon accessing the network. This Policy Group will use IP as the qualifier. As users register their devices, they will be moved to another Policy Group specifically for enrolled devices.

Custom policies can also be edited from the “Custom” sub-tab. Custom policies will be covered in more detail in the Custom Policies Deep Dive section of this document.

Policy Containers

A Policy container includes one or more policies. In general, a policy container should not contain more than one of each policy type (for example, Authentication, Policy Key, Antivirus, NAT or Windows Updates) except for custom policies. A Policy container can have any number of custom policies.

When building a policy container, policies will be assessed in the order they appear on the selected side. Because of this, policies that block should be placed highest in the list, followed by warning policies and ending with audit only policies.

A policy container can be created by choosing “Policies Menu” > “Policies Container”. From here, click “New” enter a name and select one or more policies. When the container is built, click the “Save” button.

Policies Menu Building a Policy Container

Policy Groups

A Policy Group contains one Qualifier Container and one Policy Container. To create a Policy Group, choose the “Group” tab, enter a name and choose both a Qualifier Container and a Policy Container. When the group is built, click the “Save” button.

Five Policy Groups are reserved for system use. These policy groups are described in more detail in the SpecialPurposePolicy section of this document.

Group Priority

When creating policy groups with overlapping qualifiers, the group priority matters. If a device matches the qualifiers of multiple groups, it will always be placed in whichever group has the highest priority. In production scenarios, it is common for one policy group to have machine type, IP and role qualifiers and a second policy group with machine type and IP qualifiers. Because the first policy group is more specific, it should have a higher priority. For this reason, groups with 3 or more qualifier archetypes, should generally be given a higher priority than groups with only 2 qualifier archetypes. Likewise, groups with a very specific set of qualifiers should also be given higher priority than a group with less specific qualifiers.

The Free Access group specifically, can be extremely useful in production. It provides the flexibility to easily mitigate or defuse potentially troublesome issues with a few keystrokes. This group is covered in more detail in the SpecialPurposePolicy section, including specific use cases.

Creating Remediation Steps

When creating remediation steps, items will be listed with numbers if they are in the proper format. If numbers are preferred, steps should be listed between <li></li> html tags.

If numbers are not needed, no additional html tags should be used. Special attention should be used if sections are repeated multiple times. For messages like this, javascript is likely being used. For help on editing these messages, please consult your organization’s web team or contact OPSWAT support at support@impulse.com.

Antivirus web messages include a generic list of options users can install. These pages should be updated to include preferred Antivirus packages.

Create a New Web Message

To create a copy of an existing page, select the page from the list and click the “Copy to new Web Message” button. This will use the existing page as a template for the new page.

To create a new blank page, click the “New” button. This will create a generic page with basic information as a guide for the new message.

When finished editing web messaging, click on the “Apply and Use” button to save all changes to the SafeConnect appliance.

Custom Policies Options

Custom Policies are configured to check for a specific condition based on the following list:

Process, Service Scan, Registry Key and File Search can be mixed and matched in a single policy. Version Check, DNS Check and MITM Check should only be used in their own policy. Always Fail policies will cause all users in a Policy Group to be blocked.

When creating custom policy conditions, if there is no condition for a given OS, machines with that OS will not be assessed for compliance with the custom policy. For example, when looking for registry key conditions only when only the Windows XP box is checked, Windows Vista, Windows 7 and Windows 8 machines will not be assessed. Similarly, configuring a policy to only look for conditions on Macintosh machines will cause the policy to not assess Windows machines.

The Relationships between Conditions section will be set based on whether a condition is required for network access, or a condition will cause a user to be out of compliance and consequentially be warned or quarantined from network access. Custom Policies can be set to pass or fail based on a single condition, or all conditions being met.

Exporting and Importing a Custom Policy

SafeConnect has the ability to import/export custom policies right from the custom policy builder. Exported policies are XML formatted files and provide an easy way for OPSWAT to distribute custom policies to customers, or for customers to exchange or archive custom policies.

To export a custom policy, first, select the policy from the left panel and then click the “Export” button. At this point, you will be prompted for the location to save the resulting XML file.

To import a custom policy, click on the “Import” button and locate the XML file to be imported. Once the file is selected, click the “Upload” button and the imported policy will be created in the custom policy builder. After importing a policy, a web message and enforcement level will need to be selected.

Creating a New Custom Policy

To create a new policy, click on the “New” button. This example will create a policy to check for the Windows firewall running.

Enter and name and optionally enter a description. From this point, what makes up a custom policy will vary.

Custom Peer to Peer Sharing

By default, SafeConnect includes a custom policy that watches for a small number of peer to peer applications. A peer to peer policy is useful for presenting users with legal download alternatives, educating users about the risks of file sharing, tracking P2P usage or blocking users from using unauthorized P2P software. The included P2P policy can be edited to add or remove programs as new file sharing applications are discovered, or based on the organization’s requirements. To access this custom policy, choose “Peer to Peer Sharing Programs” from the Custom Policies drop-down menu. In this example, multiple BitTorrent clients will be added. Click on the “Add Process” button.

In this example, we will not look for an exact match. Any process with “torrent” in the name will match the policy. Click “OK” when done. Click “Save” to save changes.

The process condition will look in the “Processes” tab of the Windows task manager or the “Activity Monitor” and “ps” command on Macintosh machines. When adding items and NOT selecting the “Exact Match” checkbox, it is important to understand that any process containing the string will trigger a match. For example, if there is a desire to check for users running “The Onion Router”, looking for “tor” will trigger a match against any process with “tor” in the name including “monitor”. Entering “tor.exe” with the “Exact Match” box checked would be the proper way to check for “The Onion Router”.

When the peer to peer policy is in use, a user that is quarantined can simply turn off their peer to peer software to regain network access.

Custom File Search

One possible use case for file searches is with domain machines that need to have updated startup scripts. By checking for the presence of a specific startup file, an administrator can determine which domain machines need to be updated. Using this kind of policy, end users can be messaged to contact the IT department to get the latest updates.

After creating a new custom policy, choose all the Windows versions from the “Applied Operating Systems” Section.

Click on the “Add File Search” button.

The “File Name” field may or may not need to include a directory based on what “File Path” is chosen. Setting a “Seconds before failing the policy” value will wait the specified number of seconds before returning a fail. Click “OK” when done.

File Path Options:

Choose the option “If ANY Conditions are met, the policy passes” and then click the “Close button”.

Choose a web message, followed by an enforcement level. When the Custom Policy is completely configured, click the “Save” button. This policy is now ready to be added to a Policy Container. When finished, remember to click on the “Apply and Use” button to save the new policy settings to the SafeConnect appliance.

Custom Internet Explorer Version Check

After creating a new custom policy choose all the Windows versions from the “Applied Operating Systems” Section.

Click on the “Add Version Check” button.

Version checks have two options:

• App Search: Looks for the version of a program that is associated with the given file type (such as .pdf or .doc). The "Program name substring" field should include the name of the program used to open the files with the designated extension.

• File Search: Looks for the version of a specified file, such as an .exe file. This check will examine the specific file that is specified.

The Internet Explorer check will use the file search option. The app search option would be more applicable when looking for minimum PDF reader version for multiple PDF applications such as Adobe Reader and Foxit reader.

For the version numbers, the “From” field should contain the minimum allowed version. The “To” field should be a high version number that does not exist yet. This will prevent the need to constantly update the custom policy. In cases where a specific program version is required, both fields should contain the same value. Click “OK” when done.

Choose the option “If ANY Conditions are met, the policy passes” and then click the “Close" button.

Choose a web message, followed by an enforcement level. When the Custom Policy is completely configured, click the “Save” button. This policy is now ready to be added to a Policy Container. When finished, remember to click on the “Apply and Use” button to save the new policy settings to the SafeConnect appliance.

Custom DNS Check

After creating a new custom policy choose all the “All PK Enabled Devices” option from the “Applied Operating Systems” Section. For DNS checks, it is recommended to always select “All PK Enabled Devices”.

Click on the “Add DNS Check” button.

Enter the IP address(es) of the DNS servers to check for and then click “OK”.

Choose the option “If ANY Conditions are met, the policy passes” and then click the “Close" button.

Choose a web message, followed by an enforcement level. When the Custom Policy is completely configured, click the “Save” button. This policy is now ready to be added to a Policy Container. When finished, remember to click on the “Apply and Use” button to save the new policy settings to the SafeConnect appliance.

Custom Man-in-the-Middle Check

After creating a new custom policy choose all the “All PK Enabled Devices” option from the “Applied Operating Systems” section. For MITM checks, it is recommended to always select “All PK Enabled Devices”.

Click on the “Add MITM Check” button.

Enter the MAC addresses for any valid gateway devices on the network.

Choose the option “If ANY Conditions are met, the policy passes” and then click the “Close button”.

Choose a web message, followed by an enforcement level. When the Custom Policy is completely configured, click the “Save” button. This policy is now ready to be added to a Policy Container. When finished, remember to click on the “Apply and Use” button to save the new policy settings to the SafeConnect appliance.