Creating Applet and ActiveX Security Policies

Applet and ActiveX Security lets you create and enforce security policy for all users of the LAN, rather than relying on each user to correctly configure the security settings in his or her Web browser.

To create an applet and ActiveX security policy:

From the IWSVA menu, click HTTP > Applets and ActiveX > Policies and then click the Add button.
In the Add Policy screen that appears, type a name for the policy, and then define to whom the policy will apply and click Next. (The User ID method—LDAP, IP address, host name—is defined in the Administration > IWSVA Configuration > User Identification | User Identification page).

Note: If you want the policy to apply to all users in the organization, edit the pre-existing "global" policy. The global policy, by default, takes the lowest priority—all other policies in the list will supersede it.

In the Applets and ActiveX Policy: Add Policy page, under Java Applet Security, choose either:

Block all Java applets—IWSVA will prevent all clients from accessing Java applets on the Web. Users will be notified when a Java applet on a Web page is blocked.

Process Java applets using the following settings—There are four conditions, and you can have IWSVA take one of four actions (explained below).

Conditions:

Valid signature, trusted certificate—Means the CA appears in the IWSVA Digital Certificates list, and has not been blacklisted or deactivated.
Valid signature, blacklisted certificate—Means the CA appears in the IWSVA Digital Certificates list, but has been blacklisted, for example because it was found to be counterfeit.
No signature—Means the Java applet was not signed. Whatever action you specify for this condition will also apply to applets whose signature has been stripped via Settings page rule.
Invalid signature—Means the Java applet signature is problematic; for example, the applet has been tampered with.
Note: IWSVA will invalidate applet signatures during the process of instrumentation. You can have IWSVA re-sign applets using a new signature, strip the signature, or send it on as invalid. In any case, the applet will be processed as specified here.

Actions:

Pass—Although scanned and possibly instrumented, no action against any Java applets will be taken.
Instrument and re-sign—Java applets will be opened (signature broken), and, depending on the Applet Instrumentation Settings configuration, preemptory code inserted before re-signing the applet with the signature specified in the Settings page.
Instrument and strip signature—Java applets will be opened (signature broken), and depending on the Applet Instrumentation Settings configuration, preemptory code inserted, after which the (now invalid) signature will be stripped—the applet will be unsigned.
Block—Java applets that meet the condition specified above will be blocked.

Choose which actions you want IWSVA to allow or to preempt, as explained below.

Note: During the process of "instrumentation" IWSVA will open each Java applet and examine the nature of the code inside. If IWSVA detects code of the kind configured below, it will insert preemptive commands to prevent the applet from running the original code. Of course, the signature, if any, will be invalidated.

Allow applets to perform the following file operations:

Destructive operations—MORE>>
A "destructive" operation is considered to be any command that can change the state of a file or directory.

Potentially destructive operations include:
Non-destructive operations—MORE>>
A "nondestructive" operation is considered to be any command that leaves the state of a file or directory as-is:
Write—MORE>>

Disable this option to prevent applets from performing any Write operations on the LAN client's machine.
Read—MORE>>

Disable this option to prevent applets from performing any Read operations on the LAN client's machine.

Allow applets to perform following network operations:

Bind local ports—MORE>>

Disable this option to prevent applets downloaded to your LAN clients from being able to bind to those clients' local ports.
Connect to their originating servers—MORE>>

Disable this option to prevent applets downloaded to your LAN clients from being able to contact the server from which the applet was downloaded.
Host connections—MORE>>

Disable this option to prevent applets downloaded to your LAN clients from being able to create a host connection to those client machines.

Allow applets to perform following thread and windows operations:

Create new thread groups—MORE>>

Clear this option to prevent any malicious applets downloaded to your LAN clients from being able to start a bunch of threads and lock up the browser.
Create active threads, maximum threads—MORE>>

Clear this option to prevent applets downloaded to you LAN clients from being able to create active process threads, or select it and enter the limit.
Create active windows, maximum windows—MORE>>

Clear this option to prevent applets downloaded to you LAN clients from being able to open, or pop-up new browser windows, or select it and enter the limit. This trick of a "browser storm" is fairly common.

In the Note: field, for example, type the justification, intent, or authorization for the policy, or just to keep a record of changes.
Click Next to open the ActiveX Security page, and then choose whether to block Windows CAB and/or Portable Executable files.

Block all cabinet files—Select this option to prevent LAN clients from downloading Windows .CAB files. (.CAB files are not included in the virus scan policy option to block compressed files).
Allow all cabinet files—Select this option to have IWSVA ignore Windows .CAB file downloads.
Verify signatures—Select this option to prevent LAN clients from downloading Windows .CAB files if:

Block invalid—The IWSVA Signature Validation (HTTP > Settings > ActiveX Executables) check finds that the ActiveX file's certificate is not valid.
Block unsigned—The IWSVA Signature Validation check finds that the ActiveX file's certificate is not signed.

Portable executable (PE) files—If you have a virus scan policy that enables file blocking (Java, Executables), that policy will take precedence over PE file blocking (a sub-set of the "Executables" category).
Block PE format files—Select this option to prevent LAN clients from downloading Windows COM objects, including .ocx, .exe, and .dll files.
Allow PE format files—Select this option ignore PE file downloads.
Verify signatures—Select this option to prevent LAN clients from downloading PE files if:

Block invalid—The IWSVA Signature Validation check finds that the PE file's certificate is not valid.
Block unsigned—The IWSVA Signature Validation check finds that the PE file's certificate is not signed.
Enforce policy for all signed PE format executables (not just ActiveX/COM objects)—When selected, all PE files will be scanned, not just COM objects of which ActiveX controls are a subtype. Note that this may affect performance.

Click Next to open the Exceptions to Applet and ActiveX Restrictions page, and then choose the approved URL list.
Click Save to add the policy to the list.
Finally, in the Applets and ActiveX Policies list page, click Deploy Policies to upload the policy to the IWSVA database.