Print Download PDF Send Feedback

Previous

Next

Secure Configuration Verification

In This Section:

The Need to Verify Remote Client's Security Status

The Secure Configuration Verification Solution

Overview of the SCV Workflow

SCV Checks

Considerations regarding SCV

Configuring SCV

The information and procedures in this section are relevant for Endpoint Security VPN and Check Point Mobile for Windows remote access clients.

The Need to Verify Remote Client's Security Status

Network and Firewall administrators can use different tools to control computers inside their organization. For example, to disable dangerous components such as Java and ActiveX controls in browsers, install Anti-Virus, and make sure they are run correctly.

For remote users who access the organization from outside of the LAN, the administrator cannot enforce control of the computer with the same tools. For example, suppose the remote user has ActiveX enabled, and connects to a website containing a malicious ActiveX control which infects his or her computer. When the remote user connects to the organization's LAN, the LAN becomes vulnerable as well.

A properly configured Desktop Security Policy, cannot protect against this type of attack, because the attack does not target a vulnerability in the access control to the user's machine. Instead it takes advantage of the vulnerable configuration of applications on the client.

The Secure Configuration Verification Solution

Secure Configuration Verification (SCV) ,makes sure that remote access client computers are configured in accordance with the enterprise Security Policy. Use SCV to:

SCV does not replace the Desktop Security Policy, but works with it.

SCV uses SCV checks, which are DLLs (plug-ins) on the client, that are invoked and enforced according to the policy that you configure on the Security Management Server. SCV checks include sets of conditions that define a securely configured client system. Checks can include, for example, the user's browser configuration, the version of the Anti-Virus software installed on the desktop computer, and the operation of the personal firewall policy. These security checks are performed at pre-defined intervals by the remote access client. Based on the results of the SCV checks, the Security Gateway decides whether to allow or block connections from the client to the LAN.

Check Point's SCV solution comes with many predefined SCV checks for the operating system and user's browser, and also allows OPSEC partners, such as Anti-Virus software manufacturers, to add SCV checks for their own products.

Overview of the SCV Workflow

Installing SCV Plugins on the Client

SCV checks are performed through special DLLs which check elements of the client's configuration and return the results of these checks. An SCV application registers its SCV DLLs in the system registry.

The first step in configuring SCV is for the administrator to install the applications that provide the SCV checks on the client. During installation, these applications register themselves as SCV plug-ins and write a hash value of their SCV DLLs to prevent tampering.

Configuring an SCV Policy on the Security Management Server

An SCV Policy is a set of rules or conditions based on the checks that the SCV plug-ins provide. These conditions define the requested result for each SCV check, and on the basis of the results, the client is classified as securely configured or non-securely configured. For example, an administrator who wishes to disallow a file-sharing application would define a rule in the SCV Policy verifying that the file-sharing application process is not running.

Note - The SCV check described in this example is among the pre-defined SCV checks included with Security Management Server. This check must be configured to test for the specific process.

Downloading the SCV Policy to the Client

When the client downloads its Desktop Policy from the Policy Server, it downloads its SCV Policy at the same time.

Verifying the SCV Policy

After downloading the SCV Policy, the client confirms that the SCV DLL's specified in the SCV Policy have not been tampered with by calculating their hash values and comparing the results with the hash values specified for the DLLs when they were installed.

Runtime SCV Checks

At regular intervals (default is every 15 seconds), the client performs the SCV checks specified in the SCV Policy by invoking the SCV DLLs, and compares the results to the SCV Policy. The SCV Policy can be configured to display a popup notification on non-securely configured clients and/or send a log to the Security Management Server.

Making the Organizational Security Policy SCV-Aware

The client can determine whether the client is securely configured. Once all the organization's clients have been configured according to the previous steps, the administrator specifies the actions to be taken on the Security Gateway based on the client's SCV status. For example, the administrator can specify that non-securely configured clients cannot access some or all of the resources on the corporate LAN, protecting the organization from the dangers associated with the client's poor security configuration.

The administrator can choose whether to enforce SCV for remote clients. If SCV is enforced, only securely configured clients are allowed access under the rule. If SCV is not enforced, all clients are allowed access under the rule.

In simplified mode, this is configured globally. In traditional mode, this is configured individually for each rule.

When the client connects to a Security Gateway, an IKE negotiation takes place between the client and the Security Gateway. If the Security Gateway Security Policy requires an SCV check to be made, the Security Gateway holds the connection while it checks if the client is securely configured (checked by SCV). If the Security Gateway already knows the client's SCV status (i.e., the SCV status was checked in the last 5 minutes), then:

If the Security Gateway does not know the client's SCV status, it initiates an SCV check by sending an ICMP unreachable error message containing an SCV query to the client. When a client gets this SCV query, it tries to determine its SCV status. In Connect mode, the client also connects to a Policy Server to download an updated SCV Policy. In parallel, when the client gets the SCV query, it starts sending SCV status replies to the Security Gateway via UDP port 18233 every 20 seconds for 5 minutes. These replies are used as a keep-alive mechanism, in order to keep the user's connection alive in the Security Gateway state tables while the client is trying to determine its SCV status. The keep alive packets also allow the user to open subsequent connections in the 5 minute period in which they are sent without a need for further SCV queries. When the client determines its SCV status, it sends an SCV reply containing the status back to the Security Gateway via UDP port 18233. When the Security Gateway receives the SCV status of the user, it decides how to handle the user's connection.

SCV Checks

Check Point SCV Checks

The default SCV checks (plug-ins) are part of the Endpoint Security VPN and Check Point Mobile for Windows installation:

Third Party SCV Checks

SCV checks can be written by third party vendors using Check Point's OPSEC SCV SDK. For details, see the Remote Access Clients for Windows Administration Guide.

Additional Script Elements

A network administrator can easily enable a set of specific SCV checks (e.g. only check that the user's client is enforcing a security policy) or as many SCV checks as required (e.g. all of the above SCV checks). The SCV checks are performed independently by the SCV Dynamic Link Libraries, and the client checks their status through the SCV plugins every 15 seconds, and determines whether the user is securely configured or not. If one or more of the tests fails, the client is considered to be non-securely configured.

Note - To enforce a specific SCV check, set the parameters of the check in the SCVNames section, and include the name of the check in SCVPolicy.

Considerations regarding SCV

The following sections describe things that are important to know before configuring SCV.

Planning the SCV Policy

The file $FWDIR/conf/local.scv on the Security Management Server contains a sample of a basic SCV policy for checks that are supplied with any SCV installation. You can review this file to help you decide which SCV tests to perform. If you need additional SCV checks for OPSEC products, such as Anti-Virus and Endpoint Security SCV checks, visit: http://www.opsec.com.

User Privileges

To implement SCV effectively, it is suggested that you consider not to allow your remote users to have administrative privileges on their desktops. Giving the users administrative privileges can allow them to change system settings and cause SCV tests to fail. A desktop which fails an SCV check is a potential security threat to the organization.

For example, as an administrator you may want to configure the user's browser not to allow him to download Java applets from websites. A normal user will not be able to download these applets, but a user with administrative privileges can override the browser's configuration. A properly defined SCV policy can indicate that the browser's configuration had changed and trigger a proper action on the Security Gateway side. However, if the user is allowed by the Security Gateway to pass to the LAN - either by a wrong configuration of the SCV policy or lack of enforcement of the user's SCV status on the Security Gateway side - then the user's desktop will become a potential security risk to the LAN.

The SCV policy itself is protected. Users can not change the SCV policy definition files they receive, even if they have administrative rights. The SCV policy files supplied to the client are signed before arriving to the client and checked against their signature by the client. If the signatures do not match, the SCV check fails.

Configuring SCV

Configuring SCV involves setting it up on the server, setting it up on the client, and configuring SCV policy.

Configuring SCV - Server Side

To configure SCV settings in Global Properties:

  1. From Menu, click Global Properties.
  2. From the navigation tree, click Remote Access > Secure Configuration Verification (SCV).
  3. Configure the settings:
    • Apply Secure Configurations on Simplified Mode - Specifies if SCV is applied to all remote access rules in the simplified policy mode.
    • Upon Verification failure - Specifies the action that is performed when the client fails one or more SCV checks. The options are to Block the client's connection or to Accept it and send a log about the event.
    • Basic configuration verification on client's machine - Specifies whether the Remote Access Client performs SCV checks to determine if the policy is installed on all network interfaces cards on the client's desktop, and if only TCP/IP protocols are installed on these interfaces.
    • Configurations Violation Notification on client's machine - Specifies if a log record is saved on the Security Management Server machine indicating that a remote user is not verified by SCV (this is a general indication, without a specification of a certain SCV check the user's desktop had failed).
  4. Click OK and publish the changes.

Client Side Configuration

  1. If you intend to use an OPSEC SCV application, install the application on the client and enable the application's integration with SCV (see the application's documentation for information on how to do this).
  2. Start the client and connect to the Security Gateway to receive the SCV Policy.

SCV Policy Syntax

The SCV Policy is configured by the administrator in the text file $FWDIR/conf/local.scv. This file can be edited either manually by the administrator using a text editor or using a tool called SCVEditor, available at: http://www.opsec.com. The local.scv file is a policy file, containing sets, subsets and expressions.

Note - In general, you can use the pre-defined checks (in the SCVNames section of the local.scv file) as templates and list the modified checks in the SCV Policy section, without writing new SCV subsets.

Sets and Sub-sets

Each set has a certain purpose which was predefined for it. For example, one set can be used to define certain parameters, another could specify certain actions that should take place in a certain event etc. Sets are differentiated by their names and hierarchy in a recursive manner. Each set can have a sub-set, and each sub-set can have a sub-set of its own and so on. Subsets can also contain logical expressions. Sets and sub-sets with more than one sub-sets/conditions are delimited by left and right parentheses (), and start with the set/sub-set name. Differentiation between sub-sets/expressions with the same hierarchy is done using the colon :. For example:

(SetName
   :SubSetName1 (
      :ExpressionName1_1 (5)
      :ExpressionName1_2 (false)
   )
   :SubSetName2 (
      :ExpressionName2_1 (true)
      :SubSetName2_1 (
         :ExpressionName2_1_1 (10)
      )
   )
)

In the example above the set named SetName has two subsets: SubSetName1 and SubSetName2. SubSetName1 has two conditions in it (ExpressionName1_1 and ExpressionName1_2). SubSetName2 has one condition (ExpressionName2_1) and one subset (SubSetName2_1) in it. SubSetName2_1 has one condition as well (ExpressionName2_1_1).

Expressions

Expressions are evaluated by checking the value of the expression (which corresponds to an SCV check) and comparing it with the value defined for the expression (the value in the parentheses). For example, in the browser monitor SCV check provided with the client, you can specify the following expression:

:browser_major_version (5)

This expression checks whether the version of the Internet Explorer browser installed on the client is 5.x. If the (major) version is 5, this expression is evaluated as true, otherwise it is evaluated as false. The name of the expression (e.g. "browser_major_version") is determined by the SCV application and is supplied by manufacturer.

If several expressions appear one after the other, they are logically ANDed, meaning that only if all expressions are evaluated as true, then the value of all of them taken together is true. Otherwise (if even one of the expressions is false), the value of all of them is false. For example:

:browser_major_version (5)
:browser_minor_version (0)

These expressions are ANDed. If the version of Internet Explorer is 5 AND the minor version is 0 (i.e. version 5.0), then the result is true, otherwise it is false. If the version of Internet Explorer is, for example, 4.0, then the first expression is false and the second one is true, and the result of both of them is false.

Sometimes, some expressions can influence the way in which others are evaluated. For example:

:browser_major_version (5)
:browser_minor_version (0)
:browser_version_operand (">=")

These expressions are ANDed, but the third expression influences the way that the first and second ones are evaluated. In the example above, if the version of Internet Explorer is greater than or equal to (">=") 5.0, then the result is true, otherwise it is false. If the version of Internet Explorer is, for example, 4.5, then the result is false, if the version is 5.1 or higher than the result is true.

Logical Sections

As mentioned earlier, subsequent expressions are automatically ANDed. However, sometimes it is necessary to perform a logical OR between expressions, instead of logical AND. This is done by using labels:

The begin_or (orX) label - this label starts a section containing several expressions. The end of this section is marked by the end (orX) label (X should be replaced with a number which differentiates between different sections OR sections). All of expressions inside this section are logically ORed, producing a single value for the section. For example:

:begin_or(or1)
:browser_major_version (5)
:browser_major_version (6)
:end(or1)

This section checks whether the version of Internet Explorer is 5 OR 6 - if it is then the result is true, otherwise it is false.

The begin_and (andX) label - this label is similar to the begin_or (orX) label, but the expressions inside are evaluated and logically ANDed. The end of this section is marked by the end (andX) or the end (orX) label. As mentioned earlier, simple subsequent expressions are automatically ANDed. The reason that this label exists is to allow nested ANDed sections inside ORed sections. For example, if an administrator considers old browsers as secure since they do not have a lot of potentially unsafe components, and new browsers as secure, since they contain all the latest security patches, he can define the following SCV rules:

:begin_or (or1)
:begin_and (and1)
:browser_major_version (5)
:browser_minor_version (0)
:browser_version_operand (">=")
:end (and1)
:begin_and (and2)
:browser_major_version (3)
:browser_minor_version (0)
:browser_version_operand ("<=")
:end (and2)
:end (or1)

In the example above, the first AND section checks whether the version of IE >= 5.0, the second AND section checks whether the version of IE is <=3.0 and they are ORed. The entire example is evaluated as true only if the version of IE is larger than (or equal to) 5.0 OR lower than (or equal to) 3.0.

Expressions and Labels with Special Meanings

There are several expressions and labels which have special meaning:

For example:

:browser_major_version (5)
:browser_minor_version (0)
:browser_version_operand (">=")
:begin_admin (admin)
:send_log (alert)
:mismatchmessage ("The version of your Internet Explorer browser is old.
For security reasons, users with old browsers are not allowed to access
the local area network of the organization. Please upgrade your Internet
Explorer to version 5.0 or higher. If you require assistance in upgrading
or additional information on the subject, please contact your network
administrator.")
:end (admin)

In this example, if the user's IE browser's version is lower than 5.0, an alert is sent to the Security Management Server machine and a popup message is shown to the user with indication of the problem.

The local.scv Sets

The local.scv policy files contains one set called SCVObject. This set must always be present and contains all the subsets which deal with the SCV checks and parameters. Currently SCVObject has 3 subsets:

SCVNames

In this section the administrator specifies the names and different checks for the SCV products. Here is a general definition of an SCV check subset of SCVNames:

 : (SCVCheckName1
         :type (plugin)
         :parameters (
           :Expression1 (value)
           :Expression2 (value)
           :begin_admin (admin)
           :send_log (alert)
           :mismatchmessage ("Failure Message")
           :end (admin)
         )
      )

The test section begins with the name of the SCV check (SCVCheckName1). SCVCheckName1 defines the name of the set of tests. It is defined in the SCV application and should be provided by the SCV manufacturer. The type (plugin) expression specifies that the test is performed by an SCV DLL plugin. The parameters subset is where the SCV rules and actions are defined. The type (plugin) expression and the parameters subset should always be specified when defining a subset of SCV checks (such as SCVCheckName1).

SCVPolicy

This section defines the names of the SCV checks that should be enforced (the names are part of the SCV check names specified in SCVNames). This section's general structure is:

 :SCVPolicy (
      :(SCVCheckName1)
      :(SCVCheckName2)
   )

Note - there is a space between the colon (:) and the opening brace.

The Difference between SCVNames and SCVPolicy

To enforce a specific SCV check:

SCVGlobalParams

This section includes global parameters for SCV.

:SCVGlobalParams (
	:disconnect_when_not_verified (false)
	:block_connections_on_unverified (false)
	:not_verified_script ("myscript.bat")
	:not_verified_script_run_show (true)
	:not_verified_script_run_admin (false)
	:not_verified_script_run_always (false)
	:allow_non_scv_clients (false)
)

An Example of a local.scv File

Common Attributes

Typically, an administrator might need to change only a few of the common parameters (SCV checks) contained in the SCV policy file.

SCV Checks

Anti-Virus monitor

Parameters:

BrowserMonitor

Parameters:

This SCV check does not support the “begin admin/end admin” parameter section.

The (type) section should be replaced by (log) or (alert)

Mismatch message for the Internet Explorer settings.

BrowserMonitor can be configured to check only Internet Explorer’s version, or only the browser’s settings for a certain zone. For example, if none of the following parameters appear:

then BrowserMonitor will not check the restricted zones’ security settings. In similar fashion, if the parameter “browser_major_version” does not appear or is equal to zero, then IE’s version number is not checked.

BrowserMonitor does not support the “begin_or” and the “begin_and” syntax, and does not support the admin parameters.

For the script for checking Internet Explorer Service Pack, see Script for Internet Explorer Service Pack below.

Groupmonitor

Parameters

HotFixMonitor

Parameters

Not all the mentioned fields for HotFixMonitor need to appear in the local.scv file. Some of them may not appear at all, or may appear more than once. These fields may also be ORed and ANDed. In this way, multiple Hotfixes can be checked, and the results ORed or ANDed for extra flexibility.

HWMonitor

Parameters

HWMonitor does not support the “begin_or” and the “begin_and” syntax.

OsMonitor

Parameters

OsMonitor can be configured to check only the screen saver’s configuration, or only the operating system’s version and service pack. For example, if none of the following parameters appear:

then OsMonitor will not check the system’s version and service pack on Windows XP platforms.

Similarly, if the parameter “enforce_screen_saver_minutes_to_activate” does not appear, then the screen saver’s configuration is not checked.

OSMonitor does not support the “begin_or” and the “begin_and” syntax.

ProcessMonitor

Parameters

ProcessMonitor can also be used to check for the existence/exclusion of more than one process. The fields may be ANDed or ORed for flexibility.

RegMonitor

Parameters

To configure a check for HKEY_CLASSES_ROOT, use HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes.

: (RegMonitor
         :type (plugin)
         :parameters (
                 :keyexist ("HKEY_CURRENT_USER\Software\CheckPoint")
                 :allow_no_user (true)
                 :begin_admin (admin)
                         :send_log (alert)
                         :mismatchmessage ("mismatch message ")
                 :end (admin)
         )
 ) 

Not all the mentioned fields for RegMonitor need to appear in the local.scv file. Some of them may not appear at all, or may appear more than once. These fields may also be ORed and ANDed. In this way, multiple registry entries can be checked, and the results ORed or ANDed for extra flexibility.

You can use these logical comparison operators when working with RegMonitor in the SCV policy. Other logical operations are not supported:

Logical Operator

Meaning

 

=

Equals

 

!=

Does not equal

 

>

Greater than

 

<

Less than

 

>=

Greater than or equal to

 

<=

Less than or equal to

 

Script for Internet Explorer Service Pack

RegMonitor can be configured to check the version and service pack of Internet Explorer. The script looks as follows:

: (RegMonitor
            :type (plugin)
            :parameters (
                        :begin_or (or1)
                                    :keynexist ("Software\Microsoft\Internet Explorer")
                                    :string ("Software\Microsoft\Internet 
Explorer\Version>=6")
                                    :begin_and (and1)
                                                :string 
("Software\Microsoft\Internet Explorer\Version>=5.5")
:string ("Software\Microsoft\Windows\CurrentVersion\Internet 
Settings\MinorVersion>=SP2")
                                                :string ("Software\Microsoft\Windows\CurrentVersion\Internet Settings\MinorVersion<=SP9")
                                    :end_and (and1)
                                    :begin_and (and2)
                                                :string ("Software\Microsoft\Internet Explorer\Version>=5.5")
                                                :string ("Software\Microsoft\Windows\CurrentVersion\Internet Settings\MinorVersion>=;SP2")
                                                :string ("Software\Microsoft\Windows\CurrentVersion\Internet Settings\MinorVersion<=;SP9")
                                    :end_and (and2)
:end_or (or1)
                        :begin_admin (admin)
                                    :send_log (alert)
                                    :mismatchmessage ("Your IE must be at least 
version 5.5 with SP2.")
                        :end (admin)
            )
) 

SCVMonitor

Parameters

The string is an operator followed by the DLL’s version number in the format “vvshhhbbb”. For example, if you want the DLL version to be at least 54.1.0.220, the syntax should be:

scv_version (“>=541000220”)

SCVMonitor does not support the “begin_or” and the “begin_and” syntax.

ScriptRun

Parameters

ScriptRun does not support the “begin_or” and the “begin_and” syntax.

user_policy_scv

Parameters

SCVGlobalParams

Parameters

For all boolean parameters (true or false), the values should not be enclosed in quotation marks.

Note - This parameter, if true, blocks all connections to the machine, not just those connections to and from the VPN site.