Secure Configuration Verification

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-VirusClosed Check Point Software Blade on a Security Gateway that uses real-time virus signatures and anomaly-based protections from ThreatCloud to detect and block malware at the Security Gateway before users are affected. Acronym: AV., 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 PolicyClosed Collection of rules that control network traffic and enforce organization guidelines for data protection and access to resources with packet inspection., 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:

  • Get reports on the configuration of remote clients.

  • Make sure that clients comply with the organization's security policy.

  • Block connectivity from clients that do not comply.

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 ServerClosed Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain 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 GatewayClosed Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. decides whether to allow or block connections from the client to the LAN.

  • If the client passes all the SCV checks, the client is compliant.

  • If the client fails one of the checks, it is not compliant.

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 ruleClosed Set of traffic parameters and other conditions in a Rule Base (Security Policy) that cause specified actions to be taken for a communication session. 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 ServerClosed Check Point Single-Domain Security Management Server or a Multi-Domain 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 DLLs 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 (see Installing SCV Plugins on the Client).

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 client is securely configured, the Security Gateway allows the connection.

  • If the client is not securely configured, the Security Gateway either drops the connection, or accepts and logs it (this behavior is configurable).

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:

  • OS Monitor - Verifies Operating System version, Service Pack, and Screen Saver configuration (activation time, password protection, etc.).

  • HotFix Monitor - Verifies that operating system security patches are installed, or not installed.

  • Group Monitor - Verifies that the user logged into the operating system and is a member of specified Domain User Groups.

  • Process Monitor - Verifies that a process is running, or not running, on the client machine (for example, that a file sharing application is not running, or that Anti-Virus is running).

  • Browser Monitor - Verifies Internet Explorer version and configuration settings, such as Java and ActiveX options.

  • Registry Monitor - Verifies System Registry keys, values, and their contents.

  • Anti-Virus Monitor - Verifies that an Anti-Virus is running and checks its version. Supported: Norton, Trend Office Scan, and McAfee.

  • SCVMonitor - Verifies the version of the SCV product, specifically the versions of the SCV DLLs installed on the client's machine.

  • HWMonitor - Verifies CPU type, family, and model.

  • ScriptRun - Runs a specified executable on the client machine and checks the return code of the executable. For example, a script can check if a certain file is present on the client machine. It can perform additional configuration checks that you choose.

  • Windows Security Monitor - Verifies that components monitored by Window Security Center are installed and enforced (for example, check if there is Anti-Virus installed and running). You can define which components you want to check.

Third Party SCV Checks

SCV checks can be written by third party vendors using Check Point's OPSEC SCV SDK.

Additional Script Elements

  • SCVpolicy - SSCV checks out of the ones defined in SCVNames that run on the user's desktop (see The "SCVNames" section).

  • SCVGlobalParams - Defines general SCV parameters.

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:

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 on the Server Side:

  1. From SmartConsoleClosed Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on. 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. From the left navigation tree, below Access Control, click Access Control Policy. In the Access Control Policy, make sure that all connections where you configure SCV match a rule that is explicitly defined for Remote Access VPNClosed An encrypted tunnel between remote access clients (such as Endpoint Security VPN) and a Security Gateway..

    Example Access Rules:





    Services & Applications


    1 (Management Rule - Not relevant for this example)



















    For an HTTP connection from MP_Role to Host_10.10.0.10, SCV policy is not enforced. This is because the connection matches Rule 2. Rule 2 is for any VPN, and is not explicitly for Remote Access VPN.

    For an SSH connection from MP_Role to Host_10.10.0.10, SCV policy is enforced. This is because the connection matches Rule 3, which is explicitly for Remote Access VPN.

    For more information, see the R81.10 Security Management Administration Guide > chapter Creating an Access Control Policy.

  5. 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. 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:

    :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 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:


:browser_major_version (5)

:browser_major_version (6)


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 "AND"-ed. The end of this section is marked by the end (andX) or the end (orX) label. As mentioned earlier, simple subsequent expressions are automatically "AND"-ed. The reason that this label exists is to allow nested "AND"-ed sections inside "OR"-ed 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, the administrator can configure these 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 "OR"-ed. 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:

  • begin_admin (admin) - this label starts a section defining several actions which are performed only if the client is considered as one that does not meet SCV by previous expressions in the subset (i.e. if previous expressions in the subset have returned a value of false). The end of this section is marked by the end (admin) label.

  • send_log (type) - This expression is used as part of the begin_admin (admin) - end (admin) section, and determines whether to send a log to the Security Management Server (and the client's diagnostic tool) specifying that the client does not meet SCV.

    The word type should be replaced by the type of log to send, such as log/alert. Alert means sending a log to the Security Management Server, while log means sending the log to the remote client's diagnostic tool.

  • mismatchmessage ("Message") - This expression is used as part of the begin_admin (admin) - end (admin) section, and specifies that a popup message should be shown on the remote user's desktop, indicating the problem. The text in the inverted commas (Message) should be replaced by a meaningful text which should instruct the client about the possible sources of the problem and the action he should perform.

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


: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.

SCVObject has these subsets:

  • SCVNames - This section is the main SCV policy definition section, in which all of the SCV checks and actions are defined. This is the definition part of the SCV policy, and doesn't actually determine the SCV checks that will be performed. In this section sets of tests are defined. Later on, the administrator will choose from these sets those he wants to run on the user's desktop.

  • SCVPolicy - This section specifies the names of the SCV checks that should actually be performed on the client's machine, from the SCV checks defined in SCVNames.

  • SCVGlobalParams - This section contains some global SCV parameters.

The Difference between SCVNames and SCVPolicy

  • The "SCVNames" section defines the different parameters for the checks.

  • The "SCVPolicy" section states which checks are enforced.

To enforce a specific SCV check:

  • Configure the check's parameters in the "SCVNames" section.

  • Include the name of the check in the "SCVPolicy" section.

The "SCVNames" section

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).

The "SCVPolicy" section

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 (


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)

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