Lumension Endpoint Security with Device Control (LDC) 4.5
File Type Filtering is a feature of HEATsoftware Device Control which allows Administrators to control the types of files which can be transferred from endpoints to devices and from devices to endpoints. This feature is used as part of a data loss prevention strategy by limiting the data which users can move out of the managed environment. It is also used as part of a strategy to limit the introduction of malware into the environment by preventing specific files such as executables from being propagated from devices into the managed environment.
HEATsoftware Device Control includes a number of file type filters for popular file formats. Beginning with the HEATsoftware Endpoint Security 4.5 release,
Administrators can build their own file type filters for additional enforcement options.
The File Type Filtering feature analyzes the content of files for a specific structure in order to determine what file type the file attempting to be transferred is. File Type Filtering does not rely, or even consider, the file name, file extension, or other file metadata. These data are easily changed by the user and relying on them would not constitute a secure solution.
File Format Specifications
In order to create a custom file type filter, therefore, it is necessary to know the specification for the file format in question. The file format specification describes the underlying structure within the file. From this, it is possible to identify which elements will be consistent in all instances of the specific file type. The ideal source for the details of the file format is documentation from the file format intellectual property owner. This should be considered the authoritative source. As an example, Adobe has published the file format specifications for several of their Adobe Photoshop® file types at the following location:
For file formats which are not documented by the IP owner or publishing committee, there may exist online third-party reference material which describe the format. Since this documentation is not directly from the IP owner, it should not be considered to be 100% accurate. This documentation is typically the result of a reverse engineering analysis and may not consider all possible variations, or may have missed key information about the format. Reverse engineering file formats is complex and error prone. Also, the file format owner is free to change the format at will and without announcing any change.
Brief Video Introduction
For a brief video-based introduction to custom file type filtering, please see the following:
[VIDEO 1] – Shows an example of how to determine rules for a particular file type (Webex video files).
[VIDEO 2] – Shows how HEATsoftware Device Control can be configured to recognize the patterns from Webex video files in Video 1.
Note that the examples in the videos above do not make use of a file format specification, so it would be risky to use them in a production environment. They are primarily useful as examples of how one might go about recognizing patterns in a file and "teaching" HEATsoftware Device Control to recognize those patterns.
For a detailed explanation of custom file type filtering concepts and the steps you can take to implement custom file type filtering, please read the remaining sections of this article.
Concepts in Building File Type Filters
Viewing File Content
In order to understand the structure of the file at the byte level, it’s best to view some examples of the file type at that level. In order to do that, use a file hex viewer utility. There are several commercial and free file hex viewers available. The utility will allow a file to opened to view the actual bytes which comprise the file. The bytes are typically displayed in hexadecimal format, with an accompanying ASCII representation of the bytes. The Offset indicates the position of the byte, starting with Offset 0 as the first byte in the file.
Figure 1: Typical view of a file in a file hex viewer (.CER file shown)
In order to analyze specific locations, or offsets, in the file for specific data, the concept of Current Position is necessary. When a file is initially opened, there is an imaginary pointer which is pointing to the first byte of the file (Offset 0). There are several techniques in HEATsoftware Device Control when creating a custom file type filter to move this pointer to various offsets in the file. It can be moved to an absolute location, a location relative to its current location, or to a location relative to the beginning or end of the file. The current location of the pointer is referred to as the Current Position in the file.
In the figure below, the red box symbolizes the Current Position in the file, at offset 0x2C (2C hexadecimal). The Current Position could have been set here through any number of possible routes, including moving directly to: the beginning of the file + 0x2C bytes.
Figure 2: The concept of Current Position
Steps in File Type Filters
File Filters execute a series of specified steps in order. If each step succeeds, then the file is considered a match for that type. Enforcement is then based on the Permissions settings for that file type, Import or Export.
- The Search for Bytes step looks for a specified series of bytes within the file.
- The Read a Variable step reads data from the file into a temporary variable to be used in subsequent steps.
- Change Current Position moves the logical pointer within the file
- Check End of File succeeds if the Current Position is the end of the file.
Figure 3: Steps available for creating custom file type filters in HEATsoftware Endpoint Security
Common techniques used in File Formats
When developing a file format, a few common techniques are used. HEATsoftware Device Control allows for validation of files using these techniques with a variety of steps. File formats typically use multiple occurrences of these techniques throughout the file. Each individual occurrence should be validated to create a reliable filter.
Block of constant values
Almost every file format includes some block of fixed data at a fixed location. These bytes are used to help identify the type of file. In some cases, these bytes are ASCII text which actually reflects the file type. In other cases, these bytes are not an ASCII representation, but simply a unique string of bytes unlikely to occur in the same location and order in another file type. When creating custom file type filters, use the Search for Bytes step to check for a block of data.
Often times file formats will include a block of fixed data at a variable location instead of at a fixed location. In these cases, there is typically another number in the file which “points to” that data block, or indicates its offset from a certain location.
For example, a file format specifies that 100 bytes from the beginning of the file is a 4 byte number. The specification indicates that this number is the number of bytes prior to the end of the file at which the ASCII data “OURTYPE” will be present in the file. To check for this:
- Move the Current Position 100 bytes from the beginning of the file
- Read in a 4 byte variable called “Find OURTYPE”
- Move the current position to the end of file minus the value in “Find OURTYPE”
- Search for the bytes representing “OURTYPE” (4F 55 52 54 59 50 45).
Each of the steps (except Check End of File) can use a Reference Point. The Reference Point can be the Current Position, the beginning of the file, or the end of the file.
In order to change the Current Position to, or Search for Bytes at, a location which is specified relative to the beginning or end of the file, use these reference points.
Offsets are used to specify a distance from the Reference Point. Fixed Offsets can be specified as a number, positive to move to the right (or later) in the file, and negative to move to the left (or earlier) in the file.
Variable offsets can be used in cases where the offset itself is a number contained somewhere in the file. The number must be read into a Variable, then that Variable can be used as an Offset in any step.
When searching for bytes, a Range Length of 0 means that the data must start exactly at the specified location. If a range length of 10 is used, then the data must start at the specified location or within the next 10 bytes in order for the step to succeed.
Here is a simple example step to check for the bytes in the beginning of the .CER certificate file shown in the file hex viewer above. The file starts with the ASCII string “-----BEGIN CERTIFICATE-----“ at the beginning byte of the file. To check for this condition:
- Use Search for Bytes to find the specific bytes representing that ASCII string
- The Reference Point is the beginning of the file, since their position is relative to that point and not relative to the end or some other point in the file
- The Offset is 0 since we want to use the exact beginning of the file as our Reference Point
- The Range Length is 0 since the bytes always start at the first byte of the file, and not within some range from the beginning of the file
- The Search for Bytes dialog would be configured as pictured below:
Figure 4: Search for Bytes dialog
Adobe Photoshop Example
Here is an example, using the Adobe Photoshop® file format specification at http://www.adobe.com/devnet-apps/photoshop/fileformatashtml/PhotoshopFileFormats.htm
The specification indicates the file consists of 5 high-level sections:
The File Header contains specific information which can be validated. Some of the content is fixed, and some is variable. The first 3 entries in the table describing the header are constant data and can be validated. The remaining information varies with each instance of the file and therefore is not used for validation:
Signature: always equal to '8BPS' . Do not try to read the file if the signature does not match this value.
Version: always equal to 1. Do not try to read the file if the version does not match this value. (**PSB** version is 2.)
Reserved: must be zero.
The number of channels in the image, including any alpha channels. Supported range is 1 to 56.
The height of the image in pixels. Supported range is 1 to 30,000.
(**PSB** max of 300,000.)
The width of the image in pixels. Supported range is 1 to 30,000.
(*PSB** max of 300,000)
Depth: the number of bits per channel. Supported values are 1, 8, 16 and 32.
The color mode of the file. Supported values are: Bitmap = 0; Grayscale = 1; Indexed = 2; RGB = 3; CMYK = 4; Multichannel = 7; Duotone = 8; Lab = 9.
- The first 4 bytes in the file are always ASCII ‘8BPS’, or ’38 42 50 53’ in hexadecimal.
- The next 2 bytes are equal to 1 if the file is a PSD, or ‘00 01’ hex (It is noted in the specification that values are stored in big endian byte order). If the file is a PSB type, these bytes are ’00 02’.
- The next 6 bytes are zeroes.
Therefore, for PSD files, the file data from the beginning of the file is:
38 42 50 53 00 01 00 00 00 00 00 00
For PSB files, the file data from the beginning of the file is:
38 42 50 53 00 02 00 00 00 00 00 00
Two filters should be created, one for each subtype (PSD and PSB). Only one step is needed for each since the bytes are fixed and sequential:
Figure 5: Search for Bytes step for Adobe Photoshop PSD file type
Figure 6: Search for Bytes step for Adobe Photoshop PSB file type
A single filter could be created to validate only the matching values between the two types.
- Search for Bytes to find ’38 42 50 53’ at the beginning of the file. As above, but using a shorter data string to search for. (Note that the Current Position moves to the byte after the found data.)
- Change the Current Position, 2 bytes forward (positive) to skip the Version attribute in the file since we want to allow either value here.
Figure 7: Change Current Position to skip the Version info
- Search for Bytes again to validate the six bytes of 0’s (00 00 00 00 00 00)
Both of these approaches will validate the header of a PSD/PSB file. The strategy of using two filters, one for each type, is slightly more secure. This is because it allows ONLY a 1 or a 2 in the Version value, whereas the second approach of not checking the version value means any value could be there, and we know anything other than a 1 or a 2 is not a valid PSD or PSB file.
Remaining Sections of Photoshop File
The next 3 sections in the file (Color Mode Data, Image Resources, Layer and Mask Information) begin with a number indicating the length of that section in the file. Unfortunately the last section in the file, Image Data, does not include the length of that section. If that information were in the file, then steps could be created to move the Current Position to the beginning of a section, read the length, move the current position by that length, read in the length of the next section, etc until the Current Position would be at the end of the file, then perform a check for the end of the file. Because the length of the last section is not specified, this final check can’t be performed.
In this case, we will rely on the file header information alone to identify the file.
Usage in the product
Once created, custom File Type Filters can be used in the same manner as the built-in File Type Filters. Refer to the product documentation for information on the use of File Type Filters.
Validating Custom Filters
After creating a File Type Filter, you can validate its operation. Assign specific permissions allowing the import and/or export of the new file type to a specific user or endpoint. Transfer a variety of files between the endpoint and a device. Ensure the enforcement matches the permission settings. Attempt to transfer a variety of matching and non-matching file types.
If you need assistance in creating custom file type filters, please contact your account team and inquire about a Professional Services engagement.