InTrust 11.4.2 - Auditing Guide

Auditing Recommendations

Generally, InTrust gathering workflow is organized as follows: data from the audit trails is gathered from across the network with or without agents, processed by the InTrust server, and placed to the specified repository in a compressed form.

A repository is a file-based structure intended for long-term data storage. For further analysis and reporting, the necessary data is imported to an audit database on a SQL server.

Usually, reports are generated automatically on schedule and saved to network shares, from where they become available to users. The reports can also be sent by email. Reports can also be processed interactively using Knowledge Portal.

To deploy InTrust gathering in the way that best fits your auditing needs and network environment, you need to identify:

• Which events need to be archived
• Where they are to be stored
• How often they must be gathered
• What reports you need, and how they must be scheduled and distributed

The related topics provide you with several recommendations on deploying and configuring the InTrust gathering workflow, including:

• Data sources to be processed, and data collection scheduling—see Data Sources
• Required data stores, their location, capacity assessment and recommended data retention periods—see Data Stores
• Optimizing tasks—see Tasks and Sessions

Data Sources

What to Collect?

First, decide what data you want to collect from which sources. For example, in order to be HIPAA-compliant, organizations need to archive logon attempts, so they need to collect and store events from server security logs. On the other hand, to comply with external regulations, usually there is no need to process logs on a large number of workstations (perhaps with the exception of the application log to troubleshoot new software). However, domain controllers, servers, computers with business-critical resources and computers storing confidential information need to be audited extensively.

To simplify planning and adjustment of the audit data gathering process, InTrust offers predefined gathering policies which specify audit trails to be collected from specific sources. Also, you can create gathering policies of your own.

How Often?

Next, you need to determine how often data needs to be gathered. Gathering is best scheduled for off-peak hours, such as at night, when user activity is at a minimum. You will need to consider time differences if you have computers in different time zones, and log overwriting timeframe (especially on domain controllers).

How to Improve Repository Viewer Experience?

Use a Short-Term Repository and an Archive Repository

The entire auditing workflow should not use a single repository. The recommended minimal setup is to have one repository for recent audit data (short-term repository) and another for data that is older (archive repository).

First, temporarily disable indexing of your existing repository, and then clone this repository. Do not use conventional file copying or regular file managers. These methods may fail, because the hierarchical file structure in InTrust repositories uses very long names. Instead, use specialized replication software such as Microsoft Robocopy, which has been shipped with Windows since Vista and was available as part of the Windows Resource Kit before Vista.

After you have made a copy of the repository in the location of your choice, do the following:

1. Enable indexing of the original repository again.
2. Create a new repository in InTrust. In the New Repository wizard, specify the location of the cloned repository.

The resulting repository is ready to be used for audit data archival, and the original repository is ready for regular data extraction and cleanup.

To organize archival of repository data, first decide on the retention period in the short-term repository—for example, 90 days. To make the decision, take into account how far back the events you view usually date. Then create a task with the following jobs:

1. A repository cleanup job that clears from the short-term repository all data older than your preferred retention period
2. A consolidation job that copies the entire Windows network-related contents of the short-term repository to the archive repository; make this job the successor of the repository cleanup job
3. If applicable, a consolidation job that copies the entire Unix network-related contents of the short-term repository to the archive repository; make this job the successor of the repository cleanup job

Schedule the task to run at intervals equal to your retention period.

If your current repository setup is different from this configuration, consider converting your current production repository to a short-term repository and setting up a separate archive repository.

Use Specialized Audit Databases

In a default configuration, all best-practice scenarios use the same audit database. If you implement two or more scenarios at once, the data in the audit database becomes less specialized, and your reports may show data that is not strictly relevant to a given scenario, because it was gathered for a different scenario.

If you want to avoid this, take the following steps:

1. Create a separate audit database for each scenario that you use.
2. For each scenario, switch all the import and reporting jobs in the daily, weekly and ad-hoc reporting tasks to the correct database.
3. In the Best Practices | Daily Audit Database Cleanup task, make a copy of the existing job, and switch the new job to the correct database.

Enable Agent-Side Log Backup for Gathering

Use agent-side log backup to speed up gathering. For details about agent-side log backup, see the Keeping Event Data on the InTrust Agent Side topic.

Turn on the Enable log backup and use it to gather events option for all data sources included in the following gathering policies:

• Auditing Domain Controllers: Events from DCs
• Auditing Exchange Servers: Events from Exchange Servers
• Auditing File Servers: Events from File Servers
• Auditing Workstations: Events from Workstations

You should not enable the related Clear the backup after gathering option for these data sources, because gathering occurs on multiple schedules, and one gathering job clearing the backup may interfere with another job's operation.

What Else to Consider?

• Using agents helps to minimize network impact when communicating data from target computer to InTrust server.
• If any network segments are located behind a firewall, InTrust agents in these segments have to be installed manually, for example, to collect data from the Web farm and monitor suspicious activities in the DMZ.
• Data from untrusted domains can be collected with or without agents (if you specify appropriate credentials in the site properties).
• Repositories can be consolidated through the firewall.

Data Stores

What Will You Need?

InTrust uses the following two types of data storages:

• Repositories, which are used to store data for long periods in a compressed form
• SQL server databases, which are used for analysis and reporting, and for storing real-time monitoring alerts and configuration data

You need to plan for the following special databases:

• An InTrust configuration database
• One or more InTrust audit databases for analyzing and reporting on the audit data collected by InTrust
• An InTrust alert database where the alerts generated by InTrust real-time monitoring will be stored (one alert database is recommended for an InTrust server)

In accordance with your company’s data retention policy and administrative needs, you need to plan for the following:

• The number and locations of your repositories and databases
• Data retention periods for repositories and databases

Typically, a SQL server hosting the audit database features a quad-core 3GHz processor with plenty of RAM and hard disk space. In particular, it is recommended that database size should be kept under 100GB; data retention period depends on your reporting needs.

How Many Repositories and Databases?

To plan how many repositories and databases you need to create, first estimate how much data you need to gather, even though your initial estimates may not be accurate. If you know approximately how many events per day are generated on your servers, you can plan the storage volumes. When calculating, consider the following:

• In a repository, data is stored in a compressed form with a compression ratio near 1:15 compared to EVT format. If stored directly in the database, each event takes about 5 times more space than the original format.
• While you can keep practically unlimited amount of data in a repository, it is recommended that you store only about 2–4 weeks' worth of the recent logs in the database for reporting, and import older data from repository when needed, as described later in this document.

You may require more than one repository, for example, for the following reasons:

• Company departments need to collect data separately.
• Security boundaries make centralized collection difficult.
• Network bandwidth, particularly slow links between sites, imposes limitations on centralized collection.

You can have as many repositories as you need. For centralized data analysis, reporting and backup on external media, data from several repositories can be consolidated into a central location.

For local reporting, data needs to be imported from the local repository into the local database. Consider this recommendation when estimating the number of databases required.

InTrust supports for both file-based and Centera-based repositories. File-based repositories are the structures of folders and compressed files secured by traditional NTFS permissions (or not secured if repositories are located on the FAT32 file system). Centera-based repositories use EMC Centera™ devices for storage and offer content-addressed storage system where data cannot be modified if once recorded. This native feature helps you to secure the archived data stored on EMC Centera. Note that if you have EMC Centera device operating in your environment, you can organize corresponding InTrust repository as described in Understanding InTrust Repositories.

Generally, you can have more than one audit database—for example, one for ongoing reporting tasks, keeping the latest data (for example, for the last month), and other—for historical data analysis and reporting when necessary.

How Long to Keep?

There are no strong limitations on how long you can keep data in your repository. In accordance with your organization's data retention policy, you can periodically back up your repositories to magnetic tape or other external media. Also, you can automatically clean up your repositories and databases to get rid of obsolete data by configuring a special cleanup job and scheduling it to run as frequently as you need. Typically, a repository stores data collected during the last 6–12 months.

If you need to generate reports from data in a repository, for example, in case of internal investigation, then you can import the necessary data from the repository to the database, and generate the reports. Since the importing process copies information from repository to database, the events records will still be kept in the repository, allowing you to clean up the copies from the database.

Where to Locate?

It is recommended that you locate your repositories within one network area with an InTrust server to minimize network impact when communicating data between repository and server.

Audit databases must be located on a Microsoft SQL server with a reliable broadband connection (100Mbps+) with the InTrust server.

To provide for data integrity and availability, it is recommended to locate the default repository on a dedicated, well-protected file server (in case you plan to use a file-based repository).

Alternatively, you can locate an InTrust server, its configuration database, repository, and the audit and alert databases on one computer. Pros and cons of the solution are as follows:

• You ensure fast and reliable access to InTrust configuration data
• Data import takes less time than in any other case
• However, the hosting computer must be a high-powered server with fine-tuned resource allocation (considering that InTrust server requires 4 GB of RAM). Generally, to co-locate an InTrust server, repository and all databases, a hosting computer should have a multiprocessor (for example, 4GHz processor), plenty of RAM (8GB+ recommended) and hard disk space (100GB+ recommended).

Tasks and Sessions

Generally, it is recommended that you use copies of predefined InTrust objects, in particular, tasks, modifying them to fit your auditing needs. It is also recommended that when configuring such a task (copy), you set the Keep sessions option to the Last <number_of_sessions> or During <time_interval>, rather than All. This will prevent from performance loss that may occur if too much session data is stored to the database.