Manual Chapter : Configuring Endpoint Security Client-Side

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 11.4.1, 11.4.0
Manual Chapter
In BIG-IP® Access Policy Manager® access policies, you use client-side checks to collect and verify system information. In the visual policy editor, you can use the information collected by client-side checks in an access policy, to enforce a specific security level before granting access to network resources. You can also use this information to perform remediation and protect your network resources. The Access Policy Manager provides these checks as a set of access policy actions that you can use to construct an access policy to evaluate client systems.
Access Policy Manager uses ActiveX controls or browser plug-ins to collect information about client systems. For those clients that do not support browser add-ons or that do not allow browser software installation, the client-side security process can inspect HTTP headers to gather information on the client operating system, including the client operating system and browser type. You can check that a client supports client-side checks with the client-side check capability action. If a client does not support client-side checks, that client can follow a different access policy branch.
While Access Policy Manager provides checks for many client devices, some client-side checks may not be supported on all supported operating systems.
For a complete list and brief descriptions of endpoint security (client-side) checks, see Understanding available actions. The basic process for adding an action to an access policy is the same for each action. Properties and branch rules differ, however, from action to action.
You use the file check action for Windows, Macintosh, or Linux to verify the presence of one or more files on a client system. On all supported platforms, the file check action can verify one or more file properties, including the file name, size, date, and MD5 checksum. In addition, the Windows version of the file check action can verify version and signer information.
If a file with the described properties exists, the client is passed to the successful branch. If the file does not exist, or a file exists but one or more properties are not correct, the client is passed to the fallback branch.
Add a file check action to an access policy in a situation where verifying the presence of a certain file can increase confidence in the security of the client system.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
For Windows, select Windows File and click Add Item to add the action to the access policy.
For Macintosh, select Mac File and click Add Item to add the action to the access policy.
For Linux, select Linux File and click Add Item to add the action to the access policy.
5.
Click Add new entry to add a file entry to the action.
a)
In the FileName box, type the name for the file you want to check.
Note that this is the only setting that is required.
b)
If you want to verify that the MD5 checksum matches, in the MD5 box, type or paste the MD5 checksum.
c)
If you require an exact size for the file, in the Size box, type the size in bytes.
Note that if you type a 0 in this box, no file size check occurs. To check for a 0-byte file, you must instead type the MD5 checksum in the MD5 box. The MD5 checksum for a 0-byte file is always d41d8cd98f00b204e9800998ecf8427e.
d)
If you want to specify the file creation date, in the Date box, type the file creation date. The default date of 1970-01-01 00:00:00 is the same as specifying no date.
You can determine the file creation date by right-clicking the file in Windows, and selecting Properties. The file creation date must be translated to a 24-hour clock, if your system is not on 24-hour time. For example, you would type the file creation date
Wednesday, February 27, 2008, 1:23:37 PM
in this box as 2008-02-27 13:23:37. The file creation date is set in UTC, or Greenwich Mean Time (GMT), so the server and client timezones are not the same as the file time, and you must adjust the file time you specify accordingly.
e)
For Windows file check only, if you require that the file be signed, in the Signer box, type the signer.
f)
For Windows file check only, in the Version box, type the version of the file, if you want to specify a version, or greater than or less than a version of the file.
g)
For Windows file check only, from the Version Comparison list, select the version comparison operator. Select = if you want the file to be the exact version you specify, select < if you want the checked file version to be greater than the version number you specify, and select > if you want the checked file version to be less than the version number you specify.
8.
Click Save to complete the configuration.
In this example, the administrator adds a Windows file check action, with the requirement that a system file, wininet.dll, be present on the client system. The file must be version 6.0.2900.2904, be 658,432 bytes in size, and have an MD5 checksum of 38ab7a56f566d9aaad31812494944824.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access resource, portal access resources, app tunnels, remote desktops, and a webtop. For a web access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Windows File and click Add Item to add the action to the access policy.
The File action popup screen opens.
5.
Click Add new entry to add a file entry to the action.
In the File Name box, type C:\Windows\System32\wininet.dll.
In the MD5 box, type the MD5 checksum a4f6142caba8d9aaad31812494944824.
Many MD5 checksum utilities include a copy function to simplify this step.
In the Size box, type 1392128.
In the Version box, type 9.0.8112.2904.
From the Version Comparison list, select =.
7.
Click Save to complete the configuration.
You use the machine certificate authentication check action to check for the presence of a machine certificate on the client computer. You can configure the action to check for a certificate in a specific location, and to require matches with particular certificate fields to pass.
On a Windows client, the Machine Cert Auth action accesses the machine certificate private key; admin privilege is required to do this. A user that runs without admin privilege cannot successfully run this check unless the machine certificate checker service is installed on the machine.
To install the machine certificate checker service, you must customize the Windows client package to include the service and download and run the customized client package on the machine. (You can customize and download the Windows client package from the Secure Connectivity area of Access Policy Manager.)
On a Mac client, the Machine Cert Auth action accesses the machine certificate private key. If the certificate is stored in a keychain other than users own keychain, such as the system keychain, then you must set an ACL on the Mac for non-admin users to be able to access this private key.
Certificate Store Name
Specifies the certificate store name that the action attempts to match. The certificate store can be a system store with a predefined name like MY, or a user-defined name. The store name can contain alphanumeric characters. The default store name is MY.
For a Mac client, if you do not want to use the default location, you must type the name of a keychain file. Type only the file name, which is case-sensitive, without a file path. To view keychains, use the security list-keychains command from the terminal.
Certificate Store Location
Specifies the type and location of the store that contains the certificate, either the local machine or the current user.
For a Windows client, the store locations are in the following registry locations:
LocalMachine - searches in HKEY_LOCAL_MACHINE for the machine certificate.
CurrentUser - searches in HKEY_CURRENT_USER for the machine certificate.
LocalMachine Searches for the machine certificate in the keychain specified in Certificate Store Name in the system available preference domain.
CurrentUser - Searches for the machine certificate available in the keychain specified in Certificate Store Name in the user preference domain.
If Certificate Store Name = System.keychain and Certificate Store Location = LocalMachine, APM searches for the machine certificate in /Library/Keychain/System.keychain.
If Certificate Store Name= login.keychain and Certificate Store Location = CurrentUser, APM searches for the machine certificate in /Users/<username>/Library/Keychains/login.keychain.
If Certificate available Store Name=MY, APM searches for the machine certificate in the default available keychain of the Certificate Store Location.
CA Profile
Specifies the certificate authority profile for the machine certificate. To configure a certificate authority, on the navigation pane, expand Local Traffic, click Profiles, from the SSL menu select Certificate Authority, and click Create.
OCSP Responder
Specifies the Online Certificate Status Protocol responder configured to provide certificate status. The OCSP responder is used to check the status of the machine certificate configured in the machine cert auth check action.
Certificate Match Rule
Specifies how the machine cert auth check action identifies the certificate. The following match rules are supported:
SubjectCN Match FQDN - Specifies that the common name in the machine certificate matches the computers fully qualified domain name (FQDN).
SubjectAltName Match FQDN - Specifies that the content extracted from the Subject Alternative Name field, using a specified regular expression, must match the computers FQDN.
When this option is selected, the SubjectAltName box appears. This box is required for the SubjectAltName match value only. The regular expression is used to extract content from the first subgroup matched in the Subject Alternative Name, and then to compare the extracted content with the machines FQDN.

Note that the order of RDNs is the same as is displayed; the required separator is a comma ( , ). Subcases for regex extraction follow:

Partial extraction. For example,
".*DNS Name=([^,]+).*"
or
".*Other Name:Principal Name=([^,]+).*".
For a regular expression
'.*DNS Name=([^,]+).*', the value of the DNS Name field is extracted for matching.

Whole extraction. Leave this field empty or use "(.*)", in order to allow the entire SubjectAltName content to be extracted for matching.
Any - Specifies that the first certificate in the specified certificate store is sent to the server for further validation. Any other certificates are ignored.
Issuer - Specifies that the content from the Issuer field matches the pattern specified by the regular expression.
When this option is selected, the Issuer box appears. This box is required for the Issuer match, as well as Issuer and Serial Number match. The regular expression is used to match the Issuers content against the specified pattern.

Note that the order of RDNs is the same as is displayed; the required separator is a comma ( , ).

Subcases for the regex match are as follows:

Partial match. For example,
"CN=.*, OU=FP, O=F5, L=San Jose, S=CA, C=US"

Exact Match. For example,
"CN=Root, OU=FP, O=F5, L=San Jose, S=CA, C=US"
Issuer and Serial Number - Specifies that the content from the Issuer field matches the pattern specified by the regular expression, and that the serial number precisely matches your input.
When this option is selected, the Issuer box appears. This box is required for the Issuer match, as well as Issuer and Serial Number match. The regular expression is used to match the Issuers content against the specified pattern.
When this option is selected, the Serial Number box appears. The serial number must be an exact match (for example, the hex string must be typed in the same order as it is displayed by OpenSSL and Windows cert tools). For example,
0102030405060708090a.
Save Certificate in a session variable
Select Enabled to save the complete encrypted text of the machine certificate in a session variable, session.windows_check_machinecert.<name>.cert.
Allow User Account Control right elevation prompts
Set this option to No to suppress the UAC prompt during private key checking for non-admin users.
Use the machine cert auth check action to check for the existence of fields in a machine cert, to ensure that client systems comply with your security policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Machine Cert Auth and click Add Item to add the action to the access policy.
The Machine Cert Auth action popup screen opens.
5.
In the Certificate Store Name box, type the certificate store name, or use the provided value, MY.
6.
From the Certificate Store Location list, select the certificate store registry location.
7.
From the CA Profile list, select the certificate authority.
8.
From the OCSP Responder list, select an OCSP responder, if required, or None.
9.
10.
From the Save Certificate in a session variable list, select Enabled to save the certificate in a session variable, or Disabled to not save the certificate as a session variable.
11.
Click Save to complete the configuration.
In this example, the machine certificate checks the fully qualified domain name for www.siterequest.com against the Subject Alternative Name field.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access resource, portal access resources, app tunnels, remote desktops, and a webtop. For a web access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Machine Cert Auth and click Add Item to add the action to the access policy.
The Machine Cert Auth action popup screen opens.
5.
From the Certificate Match Rule list, select SubjectAltName match FQDN.
6.
In the Subject Alternative Name box, type *.siterequest.com.
8.
Click Save to complete the configuration.
You use the Windows info check action to verify the presence of Windows operating system versions, Windows patches, or Windows updates.
Use the Windows info action to determine if the user is using the correct version of Windows, has applied specific patches or updates to Windows, or meets other Windows requirements.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Windows Info and click Add Item to add the action to the access policy.
The Windows Info action popup screen opens.
6.
Click the Add Branch Rule button.
7.
In the Name box, type a name for the rule.
8.
Next to Expression: Empty, click change.
The Add Expression popup screen opens.
9.
Click the Add Expression button.
10.
From the Agent Sel list, select Windows Info.
11.
From the Condition list, select Windows platform or Windows update.
If you selected Windows platform, from the Windows Platform is list, select the Windows version.
If you selected Windows update, in the Windows patch box, type the update name. The format for this can be a KB patch or a Windows service pack, for example KB869074 or SP2.
12.
Click Save to complete the configuration.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access resource, portal access resources, app tunnels, remote desktops, and a webtop. For a web access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Windows Info and click Add Item to add the action to the access policy.
The Windows Info action popup screen opens.
6.
Click Add Branch Rule.
7.
Type the name XP SP2 for the rule.
8.
Next to Expression: Empty, click change.
The Expression popup screen opens.
9.
Click the Add Expression button.
The popup screen displays new information.
10.
From the Agent Sel list, select Windows Info.
11.
From the Condition list, select Windows platform.
12.
From the Windows Platform is list, select Windows XP.
13.
Click the Add Expression button.
14.
To add the next expression, next to AND, click Add Expression.
The popup screen displays new information.
15.
From the Agent Sel list, select Windows Info.
16.
From the Condition list, select Windows update.
17.
From the Windows Platform is list, select Windows XP.
18.
In the Windows Patch box, type SP2.
19.
Click the Add Expression button.
The Expression popup screen shows the expression configured as shown in Figure 7.2.
To view the rule you have created, click the Advanced tab. You see the expression
expr { [mcget {session.windows_info_os.last.platform}] == WinXP && [mcget {session.windows_info_os.last.updates}] contains SP2 }
20.
Click Finished.
21.
Click Save to complete the configuration.
The Machine Info check collects the following information, and creates session variables with it. You can then detect for these session variables using a session variable, or by configuring an expression with the expression builder pull-down menu item Machine Info. Note that in the session variable value, any special characters are represented by ASCII characters. For example, a space character is represented by the value %20. Leading and trailing white space characters are removed.
CPU Name - collects the CPU name from the client system and stores it in the session variable session.machine_info.cpu.name.
Example return value: Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz
CPU Vendor ID - collects the CPU vendor from the client system and stores it in the session variable session.machine_info.cpu.vendor.
CPU Description - collects the CPU name from the client system and stores it in the session variable session.machine_info.cpu.description.
Example return value: x86 Family 6 Model 15 Stepping 2
CPU maximum clock - collects the CPU maximum clock speed from the client system and stores it in the session variable session.machine_info.cpu.max_clock.
Motherboard manufacturer - collects the motherboard manufacturer from the client system and stores it in the session variable session.machine_info.motherboard.manufacturer.
Motherboard serial number - collects the motherboard serial number from the client system and stores it in the session variable session.machine_info.motherboard.sn.
Motherboard product - collects the motherboard product name from the client system and stores it in the session variable session.machine_info.motherboard.product.
BIOS manufacturer - collects the BIOS manufacturer from the client system and stores it in the session variable session.machine_info.bios.manufacturer.
BIOS serial number - collects the BIOS serial number from the client system and stores it in the session variable session.machine_info.bios.sn.
BIOS version - collects the BIOS version from the client system and stores it in the session variable session.machine_info.bios.version.
Number of network adapters - collects the number of network adapters from the client system and stores it in the session variable session.machine_info.net_adapter.count.
(First/Second) network adapter name - collects the name of the first or second network adapter name from the client system and stores it in the session variable session.machine_info.net_adapter.list.[number].name. For example, the variable session.machine_info.net_adapter.list.[0].name retrieves the name of the first network adapter on the system.
Example return value: Broadcom NetXtreme 57xx Gigabit Controller
(First/Second) network adapter MAC address - collects the MAC address of the first or second network adapter from the client system and stores it in the session variable session.machine_info.net_adapter.list.[number].mac_address.
For example, the variable session.machine_info.net_adapter.list.[0].mac_address retrieves the MAC address of the first network adapter on the system.
Example return value: 00:AA:11:BB:33:FF
Number of hard drives - collects the number of hard drives from the client system and stores it in the session variable session.machine_info.hdd.count.
(First/Second) hard drive model number - collects the model of the first or second hard drive on the client system and stores it in the session variable session.machine_info.hdd.list.[number].model. For example, the variable session.machine_info.hdd.list.[1].model retrieves the model of the second hard drive on the system.
(First/Second) hard drive serial number - collects the hard drive serial number from the first or second hard drive on the client system and stores it in the session variable session.machine_info.hdd.list.[number].sn. For example, the variable session.machine_info.hdd.list.[0].1 retrieves the serial number of the second hard drive on the system.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Machine Info and click Add Item to add the action to the access policy.
The Machine Info action popup screen opens.
6.
In the Name field, type a name for the Branch Rule.
7.
Next to Expression: Empty, click change.
The Expression popup screen opens.
8.
Click the Add Expression button.
The popup screen displays new information.
9.
From the Agent Sel list, select Machine Info.
10.
From the Condition list, select the condition.
12.
Click the Finished button.
For this example, you add a machine info check action that contains a branch rule that checks for a machine with an Intel processor and a Broadcom NetXtreme 57xx Gigabit Controller.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access resource, portal access resources, app tunnels, remote desktops, and a webtop. For a web access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Window Machine Info and click Add Item to add the action to the access policy.
The Machine Info action popup screen opens.
6.
Click Add Branch Rule.
7.
Type the name Machine check for the rule.
8.
Next to Expression: Empty, click change.
The Expression popup screen opens.
9.
Click the Add Expression button.
The popup screen displays new information.
10.
From the Agent Sel list, select Machine Info.
11.
From the Condition list, select CPU Vendor ID.
12.
In the CPU Vendor ID field, type GenuineIntel.
13.
Click the Add Expression button.
14.
To add the next expression, next to AND, click Add Expression.
The popup screen displays new information.
15.
From the Agent Sel list, select Machine Info.
16.
From the Condition list, select First network adapter name.
17.
In the First network adapter name field, type Broadcom NetXtreme 57xx Gigabit Controller.
18.
Click Add Expression.
19.
Click Finished.
20.
Click Save to complete the configuration.
You use the process check action with a Boolean expression to check for processes that are running on the client system.
The Boolean expressions you specify can use the wildcards * and ?, parentheses ( ) to combine values, and the logical operators AND, OR, and NOT.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select the Process Check for the operating system you are checking, and click Add Item to add the action to the access policy.
The Process Check action popup screen opens.
5.
In the Expression box, type the expression.
6.
Click Save to complete the configuration.
In this example, you use the process check action to determine the presence of the running Windows processes winlogon.exe and GoogleDesktop.exe. You also determine that no process with gator in the name is running.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access resource, portal access resources, app tunnels, remote desktops, and a webtop. For a web access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Windows Process and click Add Item to add the action to the access policy.
The Process Check action popup screen opens.
5.
In the Expression box, type the process check expression as follows:
6.
Click Save to complete the configuration.
You can set up the Windows registry action or verify the existence or absence of certain keys and values in the Windows system registry database. Both key values or Boolean expressions evaluate the existence or absence of registry entries.
key
Represents a path in the Windows registry.
value
Represents the name of the value.
comparison_operator
Represents one of the comparison operators (< available <= available > available >= available =) or ISPR. ISPR is used to verify that a key or value is present.
For equality use =. The operator == is not valid here.
data
Represents the content to compare against.
Note: Quotation marks (") are required around key and value arguments. Quotation marks are used in data if the content contains spaces, commas, slashes, tabs, or other delimiters. If quotation marks exist as part of the registry path or value name, they should be doubled (use two sets of quotation marks). data is treated as a version number if it is entered in the format d.d[.d][.d] or d,d[,d][,d] (where d is a number), and as a date if it is entered in the format mm/dd/yyyy.
"HKEY_CURRENT_USER\Software\Microsoft\Windows\
CurrentVersion\XP"
Checks for the presence of the specified path in the registry.
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
Internet Explorer.Version">= "6.0.2900.2180"
Checks that the Internet Explorer version is greater than or equal to the value specified.
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InternetExplorer.Version" >= "5.0.2800.0" AND "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
InternetExplorer.Version" <= "6.0.2900.0"
Checks for the presence of Internet Explorer. With this registry check, the Internet Explorer version must be greater than or equal to 5.0.2800.0, and less than or equal to 6.0.2900.0.
On 64-bit Windows systems, you can check for registry keys in either the 64-bit registry or the 32-bit registry. To specify the registry to check, append a number to the registry root key name. The following key names are supported:
HKEY values specified with a 32 allow you to check values in the 32-bit view of a 64-bit registry. This is the perspective used by 32-bit applications running on a 64-bit operating system.
HKEY values with a 64 appended allow you to check values in the 64-bit view of the registry. This is the perspective used by native 64-bit applications.
Keys without a bit value specified use the default Windows registry redirectors, as specified by Microsoft in the following article.
Registry Redirector (Windows) (http://msdn.microsoft.com/en-us/library/aa384232(VS.85).aspx)
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Windows Registry and click Add Item to add the action to the access policy.
The Registry action popup screen opens.
5.
In the Expression box, type:
"HKEY_LOCAL_MACHINE\Software\Google\Google Desktop.ResourceDLL"
6.
Click Save to complete the configuration.
Use the cache and session control action to provide a higher level of security to systems that are logged on to your network. The cache and session control agent deletes browser cache and other session-related information, and can be configured to clean various settings from the users system after a session is closed.
In an access policy, the cache and session control action is considered successful when the browser add-on starts successfully on the client computer. A failure indicates that the cache and session control action was unable to start.
Note: You can use the cache and session control action to clean cache and related session information from the Internet Explorer browser only. The action does not clear browser cache and session-related items from Firefox, Safari, or any other browser. However, other items you configure in the action are cleaned on all Windows systems.
Note: Windows Cache and Session Control is not compatible with Windows Protected Workspace. You should not use a Windows Protected Workspace action in a session that includes the Windows Cache and Session Control action.
Add a cache and session control action anywhere in the access policy, as long as it is used on a branch for Windows clients.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Windows Cache and Session Control and click Add Item to add the action to the access policy.
The Cache and Session Control action popup screen opens.
For the option Clean forms and passwords autocomplete data option, select Enabled or Disabled.
Enabled removes autocomplete data from web forms, and deletes saved passwords from the system after the user logs out.
For the option Empty Recycle Bin, select Enabled or Disabled. Enabled ensures that the Recycle Bin is emptied on the system after the user logs out.
For the option Force session termination if the browser or Webtop is closed, select Enabled or Disabled.
Enabled forces the session to close when the user closes the web browser or the network access webtop.
For the option Remove dial-up entries used by Network Access client, select Enabled or Disabled.
Enabled removes the VPN connection from the users Network Connections Dial-up Networking folder.
From the Terminate session on user inactivity list, select a setting in minutes or hours to force the session to close if the user is inactive for the specified time.
Select Custom to specify a custom setting, in seconds.
Select Disabled to not terminate the session on user inactivity.
User inactivity is the period of time during which the user has not input any data using the keyboard or mouse on the client system. This is not traffic inactivity over the VPN.
From the Lock workstation on user inactivity list, select a setting in minutes or hours to force the users workstation to lock if the user is inactive for the specified time.
Select Custom to specify a custom setting, in seconds. Select Disabled to not lock the users workstation because of user inactivity.
User inactivity is the period of time during which the user has not input any data using the keyboard or mouse on the client system. This is not traffic inactivity over the VPN.
6.
Click Save to complete the configuration.
In this example, the administrator adds a cache and session control that removes stored passwords and autocomplete data, forces the user to log out if the Webtop or browser is closed, locks the workstation after 5 minutes of inactivity, and closes any session that is inactive after 30 minutes. All other settings are left disabled.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access resource, portal access resources, app tunnels, remote desktops, and a webtop. For a web access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Windows Cache and Session Control, and click Add Item to add the action to the access policy.
The Cache and Session Control action popup screen opens.
For the option Clean forms and passwords autocomplete data, select Enabled.
For the option Force session termination if the browser or Webtop is closed, select Enabled.
From the Terminate session on user inactivity list, select 30 minutes to force the session to close after 30 minutes of inactivity.
From the Lock workstation on user inactivity list, select 5 minutes to lock the users workstation after 5 minutes of inactivity.
6.
Click Save to complete the configuration.
Protected workspace configures a temporary Windows user workspace for the secure access session that prevents external access, and deletes any files created before leaving the protected area. The protected workspace allows you to restrict end users from printing and saving files on a client accessing the Access Policy Manager. Protected workspace reduces the risk of unintentional or accidental information leaks, but does not eliminate it. For example, EXE, DLL, and IME files are not encrypted. It restricts users to a temporary workspace on the remote system, which is newly created at the beginning of each new session. This workspace contains temporary Desktop and My Documents folders. In protected mode, the user cannot unintentionally or accidentally write files to locations outside the temporary folders. The protected workspace control deletes the temporary workspace and all of the folder contents at the end of the session.
Note: Windows Cache and Session Control is not compatible with Windows Protected Workspace. You should not use a Windows Protected Workspace action in a session that includes the Windows Cache and Session Control action.
Note: You cannot assign a Windows group policy template after a session is in the protected workspace. To use Windows group policies with protected workspace, you must place the Windows group policy action before the protected workspace action in the access policy.
Use the protected workspace action to assure that clients who connect to network access are placed in a protected workspace for the duration of the session.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Windows Protected Workspace and click Add Item to add the action to the access policy.
The Protected Workspace action popup screen opens.
Enable or disable the option to Close Google Desktop Search when the user starts the protected workspace session.
Note that selecting Enabled in this option is more secure.
Enable or disable the option to Allow user to temporarily switch from Protected Workspace when the user is in the protected workspace session.
Enable or disable the option to Allow user to use printers.
Select the option for the setting Allow write access to USB flash drives. In addition to the Disabled option and the option to allow write access to All USB flash drives, this setting provides a third option, Only IronKey Secure Flash Drives, which allows a user to write only to specialized, highly secured flash drives created by IronKey, Inc.
Enable or disable the option to Allow user to burn CDs.
Enable or disable the option to Allow user to choose storage location. This specifies whether a user can choose the storage location for Protected Workspace files. Enabled allows users to select a storage location. Disabled stores files in the Document and Settings directory.
Select whether to Enable persistent storage. This specifies whether data is saved on the system after the protected workspace session is closed. Enabled allows users to save encrypted data from the protected workspace session on the local system after the session exits. The files are automatically decrypted and available in the next protected workspace session. Disabled prevents users from storing protected workspace data in persistent storage.
Select whether to Password protect new storage. Specifies whether protected workspace requires a password to access data in persistent storage. Enabled requires the user to set a password to access persistent storage data. Disabled uses the default encryption and decryption, which is based on the server group name and storage device volume serial number.
Specify a Server group name. This specifies a group name for the server. This name is arbitrary, but limits the persistent storage to that group name. For example, if a user connects to Protected Workspace on a server with group name GroupA, and persistent storage is enabled, the user data is available when reconnecting to a protected workspace session with the group name GroupA. However, if the user then connects to a server with persistent storage enabled and the server group name GroupB, persistent data from the GroupA protected workspace session is not available in the new session, and a new persistent storage is defined.
6.
If you want to allow protected workspace users to have write access to a specific server, click the Add new entry button and type the name of the server under Allow write access to these servers.
To add more servers, repeat this step. To remove a server, click the X button next to the name of the server.
7.
Click Save to complete the configuration.
In this example, the administrator adds protected workspace to an access policy branch. The security policy is very strict, so the only option allowed is for a user to write to an IronKey USB flash drive, and a server called Quarantine. Persistent storage is not enabled.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access resource, portal access resources, app tunnels, remote desktops, and a webtop. For a web access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Windows Protected Workspace and click Add Item to add the action to the access policy.
The Protected Workspace action popup screen opens.
From the Close Google Desktop Search list, select Enabled.
From the Allow user to temporarily switch from Protected Workspace list, select Disabled.
From the Allow user to use printers list, select Disabled.
From the Allow write access to USB flash drives list, select Only IronKey Secure Flash Drives.
From the Allow user to burn CDs list, select Disabled.
From the Allow user to choose storage location list, select Disabled.
From the Enable persistent storage list, select Disabled.
From the Password protect new storages list, select Enabled.
Leave the Server group name list blank.
6.
Click Add new entry to add a server to which a user can write.
In the box that appears, type Quarantine.
Note that new entries are added above previously configured entries, by default.
7.
Click Save to save the access policy.
The Windows group policy action allows you to assign a Windows group policy, which changes security settings for the Windows client environment for the duration of the network access session.
Note: You cannot assign a Windows group policy template after a session is in the protected workspace. To use Windows group policies with protected workspace, you must place the Windows group policy action before the protected workspace action in the access policy.
Windows group policy templates allow you to configure and assign group policies for Windows machines dynamically per user session in the access policy. Using Windows group policy templates, you can make configuration changes to client systems that exist for the duration of a session. The system applies Windows group policy changes after the Windows group policy check is successful, and before resources are assigned. After the user terminates the session, all Windows group policy changes are rolled back, and the client system reverts to its previous state.
You can use predefined Windows group policy templates with Access Policy Manager. To define your own Windows group policy templates, you must purchase a license for the GPAnywhere product from Full Armor.
Table 7.1 lists the predefined Windows group policy templates included with Access Policy Manager, and their functional descriptions.
Access Policy Manager settings for enabling the users firewall. This policy is used to ensure that the users Microsoft firewall is configured and running.
Based on the Gramm-Leach-Bliley GLBA standard. This policy is used for desktop and laptops to help prevent access to unauthorized information.
Based on the HIPAA (Health Insurance Portability and Accounting Act) standard. This policy is used for desktop and laptops to help prevent access to unauthorized information.
Microsoft Common Usage (high) for desktops and laptops. This policy is used in managed environments and provides high restrictions on user access to devices, configuration, and applications.
Microsoft Common Usage (light) for desktops and laptops. This policy is used in managed environments, and provides light restrictions on user access to devices, configuration, and applications.
Based on the PCI (Payment Card Industry) standard. This policy is used for desktop and laptops to help prevent access to unauthorized information.
Microsoft Specialized Security (Limited Functionality) for desktops and laptops. This is a more focused security policy, with greater restrictions on configuration access.
Terminal Services for client terminal services. This policy is used in environments where the primary use is terminal services.
The Enterprise Client (EC) and Specialized SecurityLimited Functionality (SSLF) templates are based on Microsoft security profiles for Enterprise Client and Specialized SecurityLimited Functionality environments.
Microsoft uses the EC and SSLF environment classifications as the basis for making recommendations on how to configure a variety of server, workstation, and laptop settings. The EC Domain Template is applicable to most enterprise environments. It balances security with usability concerns. The Group Policy settings suggested for users in EC Domain-classified environments focus on addressing the basics at a moderate level, so it is not intrusive to the user.
The SSLF Domain Template is applicable to environments where concerns about security are paramount. In such an environment, some usability is sacrificed in order to further secure the systems. The Group Policy settings suggested for users in SSLF Domain-classified environments expand upon the settings recommended for the EC Domain.
Microsoft common scenarios classify client machines into categories such as mobile, multi-user, app-station, task-station, or kiosk. These scenarios are intended to provide common starting scenarios for group policy management.
The highly- and lightly-managed templates are based on Microsoft Common Scenarios. To standardize the implementation of the scenarios, Microsoft defined the highly-managed and lightly-managed Group Policy settings as the base set of settings on top of which the scenarios would be implemented.
Both the lightly-managed and highly-managed policies are intended for use with devices that work in a centrally managed environment. As such, both templates restrict the options to which a user has access. The distinction between the two is a matter of degree.
In the case of the lightly-managed template, the users retain some ability to customize their desktop environment. Examples of settings that are applied as part of the lightly-managed template are:
In the case of the highly-managed template, the user is given very little leeway to customize the desktop environment. Examples of settings that are applied as part of the highly-managed template are:
The terminal services task station template is specific to terminal server users. It prevents users from reverting back to the default security policy but more importantly, it controls which file types (.exe, .bat, and .msi) can be used. While there are no restrictions on shortcuts (.lnk), restrictions are placed on the actual path of executables.
The firewall settings template enables a users firewall. This policy is used to ensure that the users Microsoft firewall is configured and running. If the Microsoft Windows Firewall is not enabled, group policy starts it.
The final three pre-configured templates help address certain regulatory requirements. They are all based on a basic security policy with their own nuances.
Gramm-Leach-Bliley Act (GLBA), also known as the Financial Services Modernization Act, enabled investment banks to merge with commercial banks and permitted insurance services to merge with securities companies. As part of this act, privacy policies are required to protect sensitive information from security threats. With GLBA, financial institutions must inform consumers, through a privacy notice, how the company collects, stores, shares, and safeguards the data. Compliance with the GLBA is mandatory for any financial services company.
The Health Insurance Portability and Accountability Act (HIPAA) protects people with continued health insurance coverage if they lose or change jobs, and also establishes guidelines for the exchange of patient data, including electronic transmission. There are privacy rules for the use and disclosure of this patient information.
The Payment Card Industry Data Security Standard (PCI DSS) was designed by the major credit card companies as a guideline for any organizations that process credit card transactions. Like GLBA and HIPAA, it establishes procedures for processing, storing, and transmitting sensitive data, and offers some protection against security vulnerabilities that may expose that information. Companies using PCI must also go through an outside audit to validate their compliance. There are 12 requirements within 6 major areas of concern: network security monitoring, network security testing, protecting cardholder data, vulnerability management, access control, and policy maintenance. You can find the specifics of PCI DSS at:
In addition to the preinstalled group policy templates explained above, you can add custom group policy templates, you can download templates installed on the Access Policy Manager, and you can view the configuration of installed templates.
2.
Hover your mouse pointer over Access Profiles, and click the Windows Group Policy link that appears.
The Windows Group Policy List screen opens.
3.
Click Create.
The New Windows Group Policy screen opens.
4.
In the Name box, type a name for the group policy.
5.
In the Description box, type an optional description of the group policy.
This description appears on the Windows Group Policy List screen, in the Description column.
6.
In the Configuration File box, click Browse to locate the file.
Configuration files are created by the FullArmor GPAnywhere product, and are Windows executable files with an EXE extension.
7.
Click Finished when the configuration is complete.
2.
Hover your mouse pointer over Access Profiles, and click the Windows Group Policy link that appears.
The Windows Group Policy List screen opens.
3.
4.
Next to Configuration File, click the Download link.
The web browser pops up a Save file dialog.
5.
Click the Save button to save the file.
2.
Hover your mouse pointer over Access Profiles, and click the Windows Group Policy link that appears.
The Windows Group Policy List screen opens.
3.
4.
Next to Configuration Details, click the View link.
The web browser pops up a save file dialog.
Use the Windows group policy action to assure that clients who connect to network access have their computers configured to conform to the security policy required for the duration of the session.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Windows Group Policy and click Add Item to add the action to the access policy.
The Windows group policy action popup screen opens.
5.
From the Windows group policy list, select the group policy to apply to client computers.
You can add your own group policy templates that you create with the FullArmor GPAnywhere add-on. For more information on group policy templates, see Understanding Windows group policy templates.
6.
Click Save to complete the configuration.
In this example, the administrator adds the predefined Gramm-Leach-Bliley Act (GLBA) Windows group policy template to clients that connect through this branch on the access policy. The Gramm-Leach-Bliley Act requires financial institutions to inform consumers, through a privacy notice, how the company collects, stores, shares, and safeguards the data. GLBA is mandatory for any financial services company.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access resource, portal access resources, app tunnels, remote desktops, and a webtop. For a web access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
4.
On the Endpoint Security (Client-Side) tab, select Windows Group Policy and click Add Item to add the action to the access policy.
The Windows group policy action popup screen opens.
6.
Click Save to save the access policy.
You can check a client system for the presence and condition of software using these access policy actions that perform software checks:
When you configure properties for these endpoint security software checks, you can specify what you want to check from the presence of any software to particular vendors and versions.
Not all software checks are available on all supported platforms. The properties screen for a software check provides a Platform setting when multiple platforms are supported.
When you configure a software check, you can generally select from lists of supported vendors and products. The contents of these lists depend upon the version of the EPSEC package that you have installed on your BIG-IP system. To view the currently supported software, click the OPSWAT application integration support charts link on the BIG-IP system start page.
Software checks include this setting: Continuously check the result and end the session if it changes. It is disabled by default. Set it to Enabled to continuously check the software on the client endpoint and terminate the session if the result changes.