ironkey enterprise file audit admin guide · 2016-03-01 · file audit admin guide page 1 thank you...

IronKey Enterprise File Audit Admin Guide

Last Updated July 2015

FILE AUDIT ADMIN GUIDE

Thank you for choosing IronKey™ Enterprise Management Service by Imation.

Imation’s Mobile Security Group is committed to creating and developing the best security technologies and making them simple-to-use and widely available. Years of research and millions of dollars of development have gone into bringing this technology to you.

We are very open to user feedback and would appreciate hearing about your comments, suggestions, and experiences with this product.

Feedback:

[email protected]

NOTE: Imation is not liable for technical or editorial errors and/or omissions contained herein; nor for incidental or consequential damages resulting from the furnishing or use of this material. The information provided herein is subject to change without notice.

The information contained in this document represents the current view of Imation on the issue discussed as of the date of publication. Imation cannot guarantee the accuracy of any information presented after the date of publication. This document is for information purposes only. Imation makes no warranties, expressed or implied, in this document. Imation, the Imation logo, IronKey and the IronKey logo are trademarks of Imation Corp. and its subsidiaries. All other trademarks are the property of their respective owners.

© 2015 Imation Corp. All rights reserved. IK-EMS-ADM03-1.0

mailto:securityfeedback%40imation.com?subject=Feedback%20for%20Imation%20Basic%20


CONTENTS

About File Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Auditing work flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Audit message details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

File information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Event details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Configuring File Audit in Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Configuring the Report server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8File Audit syslog-ng message details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Modifying the syslog-ng configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Defining a source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Defining destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Defining message filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Defining message parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Defining log path statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Analyzing audit data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14


About File AuditOnce purchased and enabled for your IronKey Enterprise Service account, the File Audit feature allows your organization to capture and report a list of the files and directories on the secure partition of managed devices. Devices report the audit data to a supported log server, or Report server.

This guide is written for administrators and provides an overview of the File Audit feature and requirements. It also explains how to configure device policies in Service to use the File Audit feature and describes how to configure the Report server to receive audit data from IronKey devices.

RequirementsIronKey Enterprise Management ServiceFile Audit is licensed as a separate feature in Service. Please contact Imation customer service for details on activating it for your account. Once purchased and enabled in Service, you can configure the device policy to enable the feature for supported devices.

Report serverThis is the syslog-ng server to which the IronKey device will send file audit data. File Audit supports the following versions of syslog-ng:

» Open-source version: debian 7u2 version 3.3.5-4 or higher. Other supported open source versions of syslog-ng 3.3.5 may work but verification of these versions was beyond the scope of this release.

» Enterprise version: syslog-ng Premium Edition 5.0.10b or higher https://www.balabit.com/network-security/syslog-ng If you are sending audit data from syslog-ng to a back-end database, make sure that the PE version supports database access for the platform and database you are using. See, https://www.balabit.com/network-security/syslog-ng/central-syslog-server/specifications.

NOTE: Installing and setting up syslog-ng is outside the scope of this guide. For more information, consult the documentation for the syslog-ng distribution you are running. The examples cited in this guide configure syslog-ng to send audit data to a back-end database (MySQL). Configuring databases to work with syslog-ng is outside the scope of this guide.

IronKey Enterprise storage deviceFile Audit is available with S250 and D250 devices running version 3.5.0.0 or higher. The secure partition requires a minimum of 75 MB of free space to store the file audit list before sending it to the Report server.


Host operating systemDevices must be able to connect to the Report server from the host computer in order to send audit data. File Audit is supported on the device with the following host operating systems:

» Windows® 8.1 » Windows® 7 » Windows® Vista » Windows® XP (SP2+) » Mac OS® X (10.9, 10.10)

Auditing work flowSupported devices are configured for File Audit through the device policy. Once devices receive the updated policy, a device will automatically perform an audit of the secure partition each time the user unlocks the device. The audit process runs in the background and does not require interaction or configuration by the user. The audit creates a listing of the files and directories on the device and saves this list to a local database log file. When the audit process finishes, the device connects to the Report server, for example syslog-ng, and uploads the data. Upon successful completion of the upload, the device deletes the local log data.

When the Report server receives audit messages, it processes the messages and sends the data to a defined destination, such as a back-end database. Messages contain the file information from the audit as well as event data about the audit process. Once added to the database, administrators can create queries or analyze the data according to the auditing requirements of your organization.

There may be situations where a device is unable to connect to the Report server or the audit process is unexpectedly interrupted. The following describes how File Audit will handle these situations.

Device audit is complete but device cannot connect to Report serverIf the first attempt to connect to the Report server fails, the device will attempt to connect every 15 minutes for as long as the device remains unlocked. If the user locks the device before the device is able to connect, the data remains on the secure partition and will be uploaded the next time the device connects to the Report server.

Not enough space on the secure partitionIf the device detects that the space on the secure partition is less than the minimum required amount (75 MB), the device will not perform the audit and an error will be reported in the event log.

Drive is unlocked in Read-Only modeRead-Only mode protects devices from potential malware by preventing files from being edited on or written to the secure partition, including File Audit data. Users will typically unlock the


device in this mode (or Administrators may force this setting) when the device is unlocked on an untrusted or unknown computer. If the drive is unlocked in Read-Only mode, the device cannot save the audit information to the local database file on the secure partition.

Audit interrupted before completionIf the device is unplugged, locked, either automatically by the auto-lock feature or by the user, or updated during the audit process, the audit will stop and no data will be uploaded. Data that was captured by the audit before the interruption, will be uploaded the next time the device connects to the Report server. An error in the event message will indicate that the audit was interrupted.

syslog-ng or database not receiving audit dataFor general issues regarding errors with syslog-ng or your database, consult the syslog-ng and/or database log files.

Audit message detailsThe audit process collects two types of data: File Information and Event details. Both are stored on the secure partition until the device connects to the Report server to upload the data. Once uploaded, the audit data is deleted from the device.

FILE INFORMATIONThe file information collected during an audit includes a list of the files and directories on the secure partition. The content of the files is not captured. The list includes system and hidden files, as well as files that are specific to the device, such as installed applications. The audit does not capture data for empty directories. File information is stored as a lightweight file-based database on the device until it is uploaded. If set in the device policy, the audit process will also report a file hash of each file, using the MD5 hash algorithm.

The file information collected includes the following details:

» device serial number » audit time stamp » file name / path » file size » time/date created » time/date modified » time/date last accessed » crytographic hash of file content (if specified in policy)


EVENT DETAILSDuring an audit, the device records event details, such as the time stamp when an audit starts and finishes and any errors that may have occurred. Event log messages are sent to the same Report server as the file information. The log file includes the following details:

» device serial number » audit time stamp » event type » error code » event detail

The following table lists some common error codes that will be captured in the event messages when an unexpected scenario occurs during a device audit.

File Audit Error CodesError code

Description

1 Unspecified error2 Local database invalid format

Database file on the device is corrupt. 8 Server connect failure11 Audit interrupted by device lock, device unplug, or device update operation12 Audit skipped due to insufficient space on secure volume15 Server connection TLS not established. Note: possible that report server is

not configured for TLS


Configuring File Audit in ServiceYou must update your Enterprise account to license the File Audit feature before you can configure File Audit in IronKey Enterprise Service. Once purchased and enabled, the device policy controls whether the File Audit feature is turned on or off for devices. By default, the File Audit policy setting is Inactive. Once active and configured in the policy, the device will receive the policy update the next time it connects to the Service. The first file audit will start the next time the user unlocks the device after receiving the updated policy.

The File Audit policy option includes the following parameters:

» Report Server Type—Only syslog-ng is currently supported » Report Server IP—The address of the log server (IPv4) and port number. » File Hash—Default setting: Off. Uses the MD5 hash algorithm. When enabled, the audit

process will create a hash of the files on the secure partition. This is included as part of the file information uploaded to the Report server.

NOTE: Enabling the File Hash setting will significantly increase the time required for a device to complete an audit.

To set the File Audit policy parameters1. In the Admin Console, open the device policy (either a new or existing policy).

2. In the Device Audit section, under File Audit, click “Inactive”. The policy setting will change to “Active”.

3. For “Report Server IP”, type the IP address for the log server. This is the syslog-ng server to which devices will upload audit data.

4. For Port, type the port number for the Report server.

5. If you want to enable the File Hash option, select “On” from the “File Hash” list box.

6. Save the new policy settings.


Configuring the Report serverThe audit data captured during a file audit is sent as syslog-ng messages from the device to the syslog-ng server address set in the device policy. The messages contain file information and event information. You must configure syslog-ng server to accept these messages from IronKey devices (or relay them as required).

This section assumes a basic understanding of how to configure syslog-ng servers. The information in this chapter describes how to configure syslog-ng specifically for use with the File Audit feature. See the syslog-ng documentation for general information about syslog-ng, command syntax and so on.

File Audit syslog-ng message details Messages are sent over a secure channel using TLS. The following values are defined in the fields of the syslog-ng File Audit message. The important fields to note are the PROGRAM and MSGID fields. These fields are referenced when you add File Audit parameters in the syslog-ng configuration file.

» PRI: Facility = user-level message; Severity = informational » VERSION: 1 » HOST: client ip address where the device is plugged in (not DNS resolved) » PROGRAM: ‘ironkey’ » PROCID: NILVALUE (‘-’) » MSGID:

• ‘fileinfo’—This is the file information gathered during the device audit of the secure partition.

• ‘event’—This is the log message generated during a file audit. It contains information about the audit, such as start and end time and any errors encountered.

https://www.balabit.com/network-security/scb/support/documentation


Modifying the syslog-ng configuration fileYou must configure the syslog-ng application for use with File Audit by editing the syslog-ng configuration file—syslog-ng.conf. If you currently use syslog-ng for other logging requirements in your organization, you will modify this file to handle log messages received from devices that use File Audit. The syslog-ng.conf file is typically located in the following directory:

» Linux and UNIX systems—/opt/syslog-ng/etc/

You must define the following settings in the configuration file:

» Source—This is the location where syslog-ng receives log messages from File Audit. » Destination—This is the location where syslog-ng sends log messages after verifying that

the filtering rules match. » Message filter—Filters are rules that you define to select only certain messages. For

example, to receive syslog-ng messages from File Audit, you must create a filter to specify the File Audit program and to allow only messages with file information or event data. When you include the filter in the log path, syslog-ng sends only those messages that meet the criteria of the filter rule to the destination.

» Message parser—Parsers help to process message data. They allow you to define rules to break down messages into named fields or columns. For a list of the columns available with File Audit for both file information and event messages, see “Defining message parsers” on page 12.

» Log path—Connects sources to destinations. The log statement tells syslog-ng what to do with a message. syslog-ng sends messages that it receives from a defined source to all defined destinations included in the log path. You can also include filters and parsers in the log path. The File Audit feature requires that you define filters and parser statements to ensure that syslog-ng can receive file information and event messages and send it to the appropriate destinations.

NOTE: For more information about the syslog-ng configuration file, see the documentation for syslog-ng server.

DEFINING A SOURCEYou must configure a source to receive messages sent from any host computer used by the IronKey device. The device must be able to connect to the syslog-ng server. The following code defines a network source ‘s_net’ and uses TLS to ensure a secure communication channel.

https://www.balabit.com/network-security/syslog-ng

https://www.balabit.com/network-security/syslog-ng


# Sourcesource s_net {# - Networktcp(ip(0.0.0.0) port(514) max-connections(200) flags(syslog-protocol)log_iw_size(50000)# - Certificates# IronKey devices use a secure connection therefore syslog-ng must be # configured to use a certificate and key. The certificate can be self-signed.tls (key_file(“/etc/syslog-ng/cert/iksyslogng.key”)cert_file(“/etc/syslog-ng/cert/iksyslogng.crt”)# - Client cert optionpeer-verify(optional-untrusted) ) ); };

DEFINING DESTINATIONSYou must configure a destination to specify where syslog-ng will send or store messages that it receives from devices. The destinations that you define will be used when you define the log path statement.

You can configure syslog-ng server to send messages to a back-end database, such as MySQL or Microsoft SQL. Messages are encoded in UTF-8 format. Therefore, you must configure your database table to handle UTF-8-encoded strings. This will typically affect only the ‘filePath’ field for fileinfo messages, as it is the only field with extended characters.

NOTE: MS SQL server does not have native support for UTF-8 character encoding. If using an MS SQL server, you should configure the database columns with extended characters, for example the ‘filePath’ column, as ‘varbinary’. For more information about MS SQL and UTF-8, see https://support.microsoft.com/en-us/kb/232580.

The destination statements in the following examples, will send fileinfo messages and event messages to a MySQL database running on the 192.168.1.84 host. The message data will be added to the ikaudit database.

1. Destination Statement for file messagesThe first destination statement, named d_mysql_fileinfo, sends fileinfo messages to the ikaudit database table. The table name includes the exact date when the messages were sent. If the user account that connects to the database has the necessary privileges, the syslog-ng application will automatically create (or add to) the table and columns. The following columns are available with fileinfo messages:

» ‘datetime’ » ‘host’ » ‘deviceSerialNumber’ » ‘auditTimestamp’ » ‘filePath’ » ‘size’ » ‘created’ » ‘modified’


» ‘accessed’ » ‘hash’

NOTE:The following sample destination statement includes the column format. With MySQL, column formats defined as (MAX) will not work. You must define specific values for the varchar parameter.

# Destinations# MySQLdestination d_mysql_fileinfo {sql( type(mysql)# The host address, username and password must match your database settings # and credentials set by your DBA host(“192.168.1.88”) username(“user”) password(“dbpassword”) database(“ikaudit”) table(“iklogfile_${R_YEAR}${R_MONTH}${R_DAY}”) columns(“datetime varchar(32)”, “host varchar(64)”, “deviceSerialNumber varchar(64)”, “auditTimestamp varchar(128)”, “filePath varchar(64096)”, “size varchar(128)”, “created varchar(128)”, “modified varchar(128)”, “accessed varchar(128)”, “hash varchar(256)” ) values(“$DATE”, “$HOST”, “$deviceSerialNumber”, “$auditTimestamp”, “$filePath”, “$size”, “$created”, “$modified”, “$accessed”, “$hash” ) indexes(“datetime”, “host”, “deviceSerialNumber”));};

2. Destination statement for event messages The second destination statement, named d_mysql_event, sends event messages to the iklogevnt database table. The table name includes the exact date when the messages were sent and when the audit was performed. If the user account that connects to the database has the necessary privileges, the syslog-ng application will automatically create (or add to) the table and columns. The following columns are available with event messages:

» ‘datetime’ » ‘host’ » ‘deviceSerialNumber’ » ‘auditTimestamp’ » ‘event’ » ‘errorCode’ » ‘eventDetail’

NOTE: The sample destination statement includes the column format. With MySQL, column formats defined as (MAX) will not work. You must define specific values for the varchar parameter.


destination d_mysql_event {sql( type(mysql) host(“192.168.1.88”) username(“user”) password(“dbpassword”) database(“ikaudit”) table(“iklogevnt_${R_YEAR}${R_MONTH}${R_DAY}”) columns(“datetime varchar(32)”, “host varchar(64)”, “deviceSerialNumber varchar(64)”, “auditTimestamp varchar(128)”, “event varchar(32)”, “errorCode varchar(16)”, “eventDetail varchar(64096)” ) values(“$DATE”, “$HOST”, “$deviceSerialNumber”, “$auditTimestamp”, “$event”, “$errorCode”, “$eventDetail” ) indexes(“datetime”, “host”, “deviceSerialNumber”) );};

DEFINING MESSAGE FILTERSYou must create message filters to allow syslog-ng to receive fileinfo and event messages from the ironkey program on the device. The log statement must also include these filters to ensure that only data that meets the message filter criteria is sent to the destination.

The following example creates two message filters: ikaudit_fileinfo and ikaudit_event. The filter looks at the MSGID of an incoming message from the program “ironkey”. The two valid MSGID values for these filters are: fileinfo and event.

# Message Filtersfilter ikaudit_fileinfo { program(ironkey) and match(“fileinfo” value(“MSGID”)) };filter ikaudit_event { program(ironkey) and match(“event” value(“MSGID”)) };

DEFINING MESSAGE PARSERSYou must define two message parsers to segment the data from the incoming messages into the available columns for file information or event messages. The log path statement must include these two parsers to ensure that the message data is segmented properly.

The following table lists the columns that are available for fileinfo and event messages.

Columns for fileinfo Columns for event• ‘deviceSerialNumber’• ‘auditTimestamp’• ‘filePath’• ‘size’• ‘created’• ‘modified’• ‘accessed’• ‘hash’

• ‘deviceSerialNumber’• ‘auditTimestamp’• ‘event’• ‘errorCode’• ‘eventDetail’


The following example creates two message parsers, one for file information messages (p_ikaudit_fileinfo) and the other for event messages (p_ikaudit_event). # Message Parsers parser p_ikaudit_fileinfo {cvs-parser( columns(“deviceSerialNumber”, “auditTimestamp”, “filePath”, “size”, “created”, “modified”, “accessed”, “hash”), delimiters(“,”), quote-pairs(‘””’));};parser p_ikaudit_event {cvs-parser( columns(“deviceSerialNumber”, “auditTimestamp”, “event”, “errorCode”, “eventDetail”), delimiters(“,”));};

DEFINING LOG PATH STATEMENTS Log paths determine what syslog-ng will do with incoming log messages. The path is defined by a log statement that must include a message source and destination as well as any filters or parsers relative to the message. syslog-ng processes log statements in the order in which they are listed in the configuration file.

You must create two log statements to define a log path for both fileinfo messages and event messages. The statements must include the s_net source, the fileinfo and event destinations as well as the filters (ikaudit_fileinfo and ikaudit_event) and parsers (p_ikaudit_fileinfo and p_ikaudit_event) that were defined for each message.

Log path statement for fileinfo messagesThis log statement filters fileinfo messages received by syslog-ng and parses and sends the data to d_mysql_fileinfo destination in MySQL.

# Log Actionslog {source(s_net);filter(ikaudit_fileinfo);parser(p_ikaudit_fileinfo);destination(d_mysql_fileinfo);};

The second statement filters event messages received by syslog-ng and parses and sends the data to d_mysql_event destination in MySQL.


log {source(s_net);filter(ikaudit_event);parser(p_ikaudit_event);destination(d_mysql_event);};

Analyzing audit dataThe syslog-ng setup that is described in this chapter was configured to send audit data to database tables in a MySQL database. Once you set up your syslog-ng configuration to receive audit information and send it to a specified destination or database, administrators can perform queries or reports of the data according to your organization’s requirements.

For example, a user lets his manager know that his Ironkey device has been stolen while he was travelling on business. The database administrator can query the database to view the most recent audit information that was captured for stolen device. The resulting data is sent to the manager to review and identify any critical files that were stored on the secure partition.

The following screen image shows the most recent file audit data in the database for the stolen device (serial number 12345680).

ironkey enterprise file audit admin guide · 2016-03-01 · file audit admin guide page 1 thank you...

Documents