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.
Note: If necessary, you can collect data into an audit database, but in this case you must precisely select the events you need to store, because database size grows rapidly.
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:
The related topics provide you with several recommendations on deploying and configuring the InTrust gathering workflow, including:
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.
Note: Detailed recommendations on setting up your auditing can be found in Windows Auditing References.
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).
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.
Caution: Disabling indexing for the duration of the replication procedure is required so that the index data is copied correctly. Indexing is enabled and disabled in InTrust Manager in the repository properties, on the Indexing tab.
After you have made a copy of the repository in the location of your choice, do the following:
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:
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.
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:
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:
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.
InTrust uses the following two types of data storages:
You need to plan for the following special databases:
In accordance with your company’s data retention policy and administrative needs, you need to plan for the following:
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.
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:
You may require more than one repository, for example, for the following reasons:
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.
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.
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:
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.
Note: If you create a task of your own, the Keep sessions value is set to Last 10 sessions by default.