Creating an SDCS/SCSP Policy to Block USB-drive Access
search cancel

Creating an SDCS/SCSP Policy to Block USB-drive Access

book

Article ID: 180630

calendar_today

Updated On:

Products

Critical System Protection Data Center Security Server Data Center Security Server Advanced

Issue/Introduction

 

Resolution

The way to get the Prevention policy to monitor removable drives at all times is to enter the underlying device names into the policy, rather than the drive letters.  If the Null prevention policy is being used, Symantec  recommends using the Core prevention policy (sym_win_protection_core_sbp) for monitoring removable drives to minimize events not related to the drives they are monitoring.  If a different prevention policy is already in place, this technique will work as well.

Due to the way a Prevention policy works, if you put a path like "F:\*" into the Prevention policy and apply the policy when the drive is not attached to the system, the policy will not monitor the drive. This is because the Prevention policy uses the underlying device names of the drives, not the drive letters. When the policy is applied, the system maps any existing drive letters to the device names. But if the device is not attached, then the Prevention policy doesn't see the mapping.   With the approach described in this article, the drive does not have to be mounted with a drive letter assignment at the time the policy is applied.

You can use the “WinObj” tool from Microsoft http://technet.microsoft.com/en-us/sysinternals/bb896657.aspx to find the mappings of drive letters to underlying device names. Mount/map the drive, run WinObj, and look for the drive letter under the “Global??” or “??” folder in WinObj.

Below is an example of the mappings for a desktop system system that has two floppy drives, one hard disk with two partitions, a CDROM, an external USB hard drive and an USB pen drive/thumb drive:

    A: -> \Device\Floppy0 (internal floppy drive)
    B: -> \Device\Floppy1 (external USB floppy drive)
    C: -> \Device\HarddiskVolume1 (a partition on an internal hard drive)
    D: -> \Device\HarddiskVolume2 (a partition on an internal hard drive)
    E: -> \Device\CdRom0 (an internal CD/DVD drive)
    F: -> \Device\HarddiskVolume3 (an external USB hard drive, not a thumb drive)
    G: -> \Device\Harddisk2\DP(1)0-0+10 (a USB thumb drive)

This is an example for drive mappings from a laptop:

    C: -> \Device\HarddiskVolume1 (a partition on an internal hard drive)
    D: -> \Device\HarddiskVolume2 (a partition on an internal hard drive)
    E: -> \Device\CdRom0 (an internal CD/DVD drive)
    F: -> \Device\HarddiskVolume3 (an external USB hard drive, not a thumb drive)
    G: -> \Device\Harddisk2\DP(1)0-0+10 (a USB thumb drive)

The way to get the Prevention policy to monitor and disallow access to removable drives at all times is to enter the underlying device names into the policy, rather than the drive letters.  As shown in the above list, there isn't a way to distinguish between an internal hard drive (volumes 1 & 2) and an external (USB) hard drive (volume 3) simply by the underlying device name. If there were 3 partitions on an internal drive, then the external drive would have become volume 4.


Below is a sample policy, assuming the system environment always has 2 disk partitions already defined (C and D) and you monitor changes to all other storage volumes added (assuming they are removable, or at least are non-standard).  The following paths could be added to the global read-only access list:

    \device\HarddiskVolume3\*
    \device\HarddiskVolume4\*
    \device\HarddiskVolume5\*
    \device\HarddiskVolume6\*
    \device\HarddiskVolume7\*
    \device\HarddiskVolume8\*
    \device\HarddiskVolume9\*
    \device\HarddiskVolume??\*

You need to list volumes 3-9 individually (since we don't want to monitor 1 & 2 because they're internal). Then you can use the wildcard "??" to handle all the double-digit volume numbers. Thus no matter how a drive was attempted to be attached (USB, FIREWIRE, SCSI, IDE internal, FIBER, etc) the additional hard drive device would be monitored.  As you can see from the above list, there isn't a way to distinguish between an internal hard drive (volumes 1 & 2) and an external hard drive (volume 3) simply by the underlying device name. If there were 3 partitions on an internal drive, then the external drive would have become volume 4.

The wild cards take care of all the variable numbers in the device name.  Also, in Windows, most USB storage thumb drives are assigned a device name that looks like drive G: from the previous laptop example. Thus to monitor such like-named devices, add the following to the global readonly access list:

    \device\harddisk*\DP*\*

If monitoring a large number of systems is required, you need to know whether the enterprise has a consistent hardware configuration, with respect to internal hard drive partitions, on the workstations (or a small number of configurations and the exact knowledge of which agents have which configurations). This affects the specific underlying device names used in the policy.  Several policies may be needed to address several different hardware configurations. In other words, a policy that blocks USB access for a system with a C: and D: drive would also block access to drives E:, F:, and G:.   This same policy would also allow access to any USB drive labeled as D: (if the system had a single-partition harddisk).    If monitoring on a large number of systems, it must be determined whether the enterprise has a consistent hardware configuration, with respect to internal hard drive partitions, on the workstations.

Note – when plugging in a USB device, drive letters will appear in the windows GUI but will not be accessible.

Before applying any policy to any machine it is recommended to disable prevention first and see what kind of events are being shown.