Professional Documents
Culture Documents
v7. 6
2011, Websense Inc. All rights reserved. 10240 Sorrento Valley Rd., San Diego, CA 92121, USA Published 2011 Printed in the United States of America and Ireland. The products and/or methods of use described in this document are covered by U.S. Patent Numbers 6,606,659 and 6,947,985 and other patents pending. This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form without prior consent in writing from Websense Inc. Every effort has been made to ensure the accuracy of this manual. However, Websense Inc., makes no warranties with respect to this documentation and disclaims any implied warranties of merchantability and fitness for a particular purpose. Websense Inc. shall not be liable for any error or for incidental or consequential damages in connection with the furnishing, performance, or use of this manual or the examples herein. The information in this documentation is subject to change without notice.
Trademarks
Websense, the Websense Logo, Threatseeker and the YES! Logo are registered trademarks of Websense, Inc. in the United States and/or other countries. Websense has numerous other unregistered trademarks in the United States and internationally. All other trademarks are the property of their respective owners.
Related topics: System configuration recommendations, page 5 TRITON Reporting Database sizing, page 6 How big will my reporting database be?, page 7 Can I use SQL Server 2008 R2 Express?, page 10 Factors that affect database size, page 11 Other factors that affect the performance of Websense reporting, page 15 TRITON Reporting Database FAQs, page 18 The TRITON Reporting Database stores reporting and logging data for all TRITON modules: Web Security, Data Security, and Email Security. It includes: Web Security Log Database - Stores Internet request data collected by Log Server for use by Web Security reporting tools. Email Security Log Database - Stores records of email traffic and the associated filtering actions on that traffic.
Data Security Incident and Configuration Database - Stores information about email, Web, and other traffic that resulted in data loss prevention (DLP) policy breaches, such as the source, destination, time, status, and severity of each breach. Also stores Data Security policy configuration and system settings. The TRITON Reporting Database is based on Microsoft SQL Server. Each of the databases listed above is comprised of a separate SQL Server database, all of which can be stored within the same SQL Server instance. Microsoft SQL Express is packaged with Websense software at no extra cost, however enterprises with high transaction volume should purchase Microsoft SQL Server Standard or Enterprise. (See Can I use SQL Server 2008 R2 Express?, page 10 for guidance.) When you install Websense software, you can select a local or remote location for the reporting database. If you select local, SQL Express is installed locally, meaning on the TRITON management server. If you select a remote location for the database, you must install and maintain SQL Server Standard or Enterprise separately on the remote machine.
2. And if you plan to run all 3 TRITON modules, you must install SQL Express on a machine running Windows Server 2008 R2 64-bit.
Windows Server 2003 R2 32-bit* Data Security Web Security Email Security x x x Windows Server 2008 32-bit Windows Server 2008 R2 64-bit x x x x V-series appliance
*Windows 2003 is supported for a single TRITON module (Web Security or Data Security) but not for a combination of modules. This is primarily for upgrade scenarios. If the standard or enterprise version of SQL Server is better suited to your organization, you should install it on a separate, remote database server for best performance. (see Remote database system, page 4 below).
*All editions except Web, Express, and Compact; all service packs; 32- and 64-bit, excluding IA64. ** All editions except Web, Express, and Compact; all service packs, 32- and 64-bit, excluding IA64.
***All editions except Web and Compact; all service packs, 32- and 64-bit, excluding IA64. Note Clustering is supported for all supported versions of SQL Server noted above.
Hardware specifications
Use hardware that meets or exceeds Microsofts recommended (not minimum) hardware requirements for SQL Server. Microsoft SQL Server 2008 R2: http://msdn.microsoft.com/en-us/library/ms143506.aspx Microsoft SQL Server 2008: http://technet.microsoft.com/en-us/library/ms143506%28SQL.100%29.aspx Microsoft SQL Server 2005: http://www.microsoft.com/sqlserver/2005/en/us/system-requirements.aspx http://msdn.microsoft.com/en-us/library/ms143506%28v=sql.90%29.aspx
RAM
Websense reporting and logging systems require that SQL Server be capable of loading, summarizing, and processing large amounts of data across multiple physical databases. This places demands on RAM usage and disk. Keep in mind that the operating system version and/or the version of SQL Server may limit the amount of physical RAM that can be used by the system. For example, Windows Server 2003 Standard Edition can only use 4 GB of RAM no matter how much is available in hardware. Consult your operating system and SQL Server documentation to ensure that you utilize the maximum physical RAM possible in your chosen system. Microsoft SQL Server limitations are documented in the links provided under Hardware specifications, page 5.
Administering Websense Databases 5
See Other factors that affect the performance of Websense reporting, page 15 for guidance on how the memory demands of Websense reporting may increase or decrease based on how you use it.
Disk speed
Database applications are I/O-intensive, so the faster the underlying disks with memory, the more responsive your database system will be. Use the highest SAS disks whenever possible for the best performance.
Disk isolation
Databases perform better when their I/O does not need to compete with regular operating system I/O. For peak performance, place tempdb, ldf, and mdf on separate physical drives with dedicated controllers. Follow SQL Server recommendations for installing and configuring SQL Server.
RAID
RAID controllers provide disk redundancy and can increase disk throughput by spreading I/O activity across multiple physical disks. For peak performance, use a RAID 10 configuration managed by a hardware-based RAID controller.
Virtualization
Websense products can be deployed on virtualized systems. Be aware that the use of virtualization can affect system performance. For specifics on Websenses support for virtualization, see the knowledge base article, Virtual Machine Support. Note that Microsoft has its own support guidelines for SQL Server, which can be found here: http://support.microsoft.com/?id=956893
These sections also provide guidance on when SQL Server Express 2008 R2 Express, the free version of SQL Server, can be safely used as the database platform for the Websense reporting system.
Web Security
Use the following table to help estimate the size of your Websense Web Security Log Database.
If You Are Logging URL Host Names (default) If Data Reduction is Enabled (default) If Data Reduction is Disabled 10 MB per user per month If You Are Logging Full URLs 13 MB per user per month
Always allow for one more month of data retention than required. For example, if you must retain data for 3 months, size for at least 4. (To ensure you have 3 full months stored, the system does not drop the first month until the end of the fourth is reached.) So if you have 7500 users, full logging, data reduction disabled, and you want to store data for 3 months, you need 967 GB available to start.
In addition, you need to calculate space for the following: The databases transaction logs - The size depends on the recovery model you choose. If it is full recovery, you need to allow for the same size as the data itself (967 GB in our example). If it is a simple recovery model, allow roughly 30 percent of that number. In our example:
0.3 * 967 GB = 290 GB
Temp DB storage - The system uses temporary storage heavily during reports generation, and the size required for the Temp DB depends on the reports requirement. For best practice, allow twice the data size for Temp DB. In our example:
2 * 967 GB = 1.9 TB
Transaction logs of the Temp DB - As with the databases transaction logs, allow 30 percent of the Temp DB storage size. In our example:
0.3 * 1.9 TB = 580 GB
The total space required for the Web Security Log Database in our example, then, is:
967 GB + 290 GB + 1.9 TB + 580 GB = 3.7 TB
Tip For best practice, enable data reduction, because the amount of storage space required drops significantly. In our example, it reduces the size required by more then by half to 1.45 TB total. See the section below, Factors that affect database size, page 11, for an explanation of the Websense Web Security data reduction algorithms and the URL logging setting, including how to change their default configurations.
Email Security
For best practice, allow 5-10 MB per user per month when estimating the size of your Websense Email Security Log Database, and allow for one more month of data retention than required. For example, if you must retain data for 3 months, size for at least 4. (To ensure you have 3 full months stored, the system does not drop the first month until the end of the fourth is reached.) For illustration, assume you will provide 7.5 MB per user per month. If you have 7500 users, an average of 10 recipients per email message, and you want to store data for 3 months, you would need 225 GB to start.
7.5 MB * 7500 users * 4 months = 225 GB
In addition, you need to calculate space for the following: The databases transaction logs - The size depends on the recovery model you choose. If it is full recovery, you need to allow for the same size as the data itself
(225 GB in our example). If it is a simple recovery model, allow roughly 30 percent of that number. In our example:
0.3 * 225 GB = 67 GB
Temp DB storage - The system uses temporary storage heavily during reports generation, and the size required for the Temp DB depends on the reports requirement. For best practice, allow twice the data size for Temp DB. In our example:
2 * 225 GB = 450 GB
Transaction logs of the Temp DB - As with the databases transaction logs, allow 30 percent of the Temp DB storage size. In our example:
0.3 * 450 GB = 135 GB
In the following table, you can estimate storage space based on email volume. The same requirements for partitions, logs, and Temp DBs apply.
Total messages per month Inbound without hybrid Inbound - with hybrid Outbound Internal
25 million 76 GB 65 GB 73 GB 73 GB
10 million 30 GB 26 GB 29 GB 29 GB
5 million 15 GB 13 GB 15 GB 15 GB
2 million 6 GB 5 GB 6 GB 6 GB
1 million 3 GB 3 GB 3 GB 3 GB
Note that Websense Email Securitys hybrid mode drops email that comes from known bad (blacklisted) sources and blocks email with a very high spam score in the cloud before it ever reaches the Email Security Gateway. This reduces the amount of data stored in the log database for reporting by 30 MB per user (per month). See the section below, Factors that affect database size, page 11, for an explanation of the assumptions built into this estimate.
Data Security
The Websense Data Security Incident and Configuration Database is different from the email and Web log databases in that it stores both configuration and log data, and it logs only policy violations, not all events. In order to estimate the potential size of
Data Security Incident and Configuration Database, you need to estimate your usage patterns of the following features:
Feature Discovery incidents (not standard with Websense TRITON Enterprise) Network and endpoint incidents User directory import data Configuration data Impact on Database Size 14 KB per incident Typically, no more than 3.5 GB total 10 KB per incident Typically, 30 KB per user per month 8 KB per record Typically, no more than 1 GB total 200 MB
As a general guideline, it is unlikely that your Data Security Incident and Configuration Database will require more than 9 GB of storage total, no matter how many users are in your environment. The volume of configuration and incident data varies based on your use of Data Security features as explained in Factors that affect database size, page 11.
that limit still meets your data retention requirements. If so, you can use SQL Server 2008 R2 Express. Note Data Security alone can support up to 5000 users with SQL Server 2008 R2 Express.
Users Over 2000 users 2000 1500 1000 750 500 250 100 Web* Not recommended Web and Data Not recommended Email** and Data Not recommended Web, Email and Data Not recommended
Not recommended Not recommended Not recommended Not recommended 30 days 60 days 5 months
Not recommended Not recommended Not recommended Not recommended Not recommended 30 days 3 months
* For Web Security, actual sizing is based on total Web requests processed per day, which can be extrapolated from the peak requests per second in your network. If you are not able to determine these numbers, Websense has found that the ratio of users to their peak number of Web requests per secondas opposed to average number per secondis 10 to 1. This is an acceptable ratio to use for the purposes of estimating the number of users that this traffic represents in the average network. Note that this calculation is based on a standard curve distribution of traffic throughout the day, where the peak is mid-day and there is almost no traffic throughout the night. ** For Email Security, actual sizing is based on total email messages sent and received per day, including spam. Websense has found that an estimate of 1 message per user per minute (including spam) is an acceptable estimate for the purposes of estimating the email volume generated for any given number of users.
every HTTP request that the browser sent to the Internet in order to build a site in the browser window. For information on data reduction algorithms, refer to the TRITON - Web Security Help topic, Log Server Configuration Utility. Disabling the data reduction algorithms can increase the total amount of data stored in the database for Web Security by a factor of 2.5. Accordingly, this could reduce the amount of data that can be stored in any particular log database system by as much as 60%. This affects how many months of data you can keep.
Email Security
Hybrid mode
Websense Email Securitys hybrid mode drops email that comes from known bad (blacklisted) sources and blocks email with a very high spam score in the cloud before it ever reaches the Email Security Gateway appliance. This reduces the amount of data stored in the Email Security Log Database for reporting by 30 MB per user per month.
Note that Email Security counts the number of recipients for each message rather than the number of messages sent. Each recipient is counted as a transaction. If the pattern of email traffic in your organization exceeds these averages, your storage capacity will vary.
Data Security
Number of discovery incidents
Websense Data Security limits the number of discovery incidents that can be stored in the Data Security Incident and Configuration Database in order to prevent improperly configured discovery policies from flooding the database. By default this limit is set to 1 million incidents. If you are using SQL Server Express, you should reduce this number to 250 thousand. To do this: 1. Log onto TRITON Console. 2. Select the Data Security tab. 3. Select Settings > General > System. 4. Select the Reporting option from the System pane. 5. Select the Discovery tab. 6. Adjust the Maximum Discovery Incidents field. Refer to the TRITON - Data Security Help section, Setting preferences for discovery incidents, for more information. Note Data Discovery is not included in Websense TRITON Enterprise. It is an add-on feature that requires a separate subscription.
13
The Data Security database stores data in partitions per each calendar quarter. You can have 1 active partition for the current quarter. If you are using Microsoft SQL Server Standard or Enterprise for your TRITON database, you can have a up to 8 online partitions (approximately 2 years), but if you are using SQL Server Express, you can have only 4 (approximately 1 year). (Online partitions are partitions that can be used to show reports and log data). For both databases, you can have up to 12 archived partitions representing 3 years of records, and 4 restored partitions (1 year).
Partition type Active Online Restored Archived Total available managed partitions
Microsoft SQL Server Standard or Enterprise 1 partition (current quarter) up to 8 partitions (2 years) up to 4 partitions (1 year) up to 12 partitions (3 years) 25
SQL Server Express 1 partition (current quarter) up to 4 partitions (1 year) up to 4 partitions (1 year) up to 12 partitions (3 years) 21
Refer to the TRITON - Data Security Help section, Archiving incidents, for more information on archiving. For instructions on setting the maximum disk space allowed for the incident archive, refer to the section, Configuring the incident archive.
Refer to the TRITON - Data Security Help section, Add a new user directory server, for information on configuring these settings.
Web Security
Your users Web browsing behavior
Web browsing behavior varies widely among Websense customers. For best practices, periodically review your database performance, your reporting needs, and the actual data in the database so you can identify ways to reduce the demands on your reporting system.
Selective logging
Websense Web Security allows you to reduce the demands on your reporting system by not logging traffic to Web sites in certain categories. For example, online retailers might disable logging for Shopping categories. This can result in a large reduction in the amount of data that has to be stored and managed by the Websense reporting system. This results in a smaller database with a longer storage capacity. It also improves its performance and scalability. For best practice, use Selective Logging to disable logging for categories that are typically not necessary for supporting your business requirements, like the Productivity: Advertisements category. Disabling logging for the Productivity: Advertisements category in particular can reduce the amount of data in your database by one third. For information on configuring Selective Logging in Websense Web Security, refer to the TRITON - Web Security Help topic, Configuring how filtered requests are logged.
15
time window, invest in more hardware resources for your reporting systemmore RAM, faster disks, faster CPUs, and higher-end versions of SQL Server and Windows that support more hardware.
Partitioning
Websense Web Security reporting segments data into partitions for easier data management. Depending on the time period covered by a report, Websense may need to query across multiple partitions. If you store a lot of data in your reporting solution and have many partitions, it may be inefficient to run such reports. By default, Websense creates a new partition within the Web Security Log Database after storing 5 GB of data in a single partition. For best practice, review the size and content of the partitions in the database after your system has been installed and receiving data for a few days, then tune the partitioning configuration accordingly. For information on managing partitions in Websense Web Security, refer to the TRITON - Web Security Help topic, Configuring database partition options.
Hybrid users
The sizing guidelines in this document include logs generated by users that are going through the Hybrid Service of Web Security. When sizing your reporting system, do not forget to include those users.
Configuration options that affect log database sizing, like Selective Logging, the data reduction algorithms, and logging full URLs, also apply to logs imported into the Web Security reporting system from the Hybrid Service, so no special consideration needs to be made for those users.
Email Security
Number of scheduled or custom presentation reports
If you create a large number of scheduled reports to run each night (more than 10) or use a large number of custom presentation reports (more than 10) each day, this can affect the performance of your Websense reporting system. In particular, the following 3 reports place high demands on system resources: Top n External Recipients by Message Volume Top n External Recipients by Message Size Top n External Recipient Data Security Policy Violations by Volume If you meet these usage profiles, invest in more hardware resources for your reporting systemmore RAM, faster disks, faster CPUs, and higher-end versions of SQL Server and Windows that support more hardware.
Partitioning
Websense Email Security Gateway reporting segments data into partitions for easier data management. Depending on the time period covered by a report, Websense may need to query across multiple partitions. If you store a lot of data in your reporting solution and have many partitions, it may be inefficient to run such reports. By default, Websense creates a new partition within the Email Security Log Database after storing 5 GB of data in a single partition. For best practice, review the size and content of the partitions in the database after your system has been installed and receiving data for a few days, then tune the partitioning configuration accordingly. For information on managing partitions in Email Security Gateway, refer to the TRITON - Email Security Help topic, Configuring Log Database Options.
Data Security
Number of concurrent partitions and partition archiving configuration
Websense Data Security automatically archives database partitions containing older data to reduce storage requirements and maintain a high performance reporting experience. To further reduce the data storage requirements of Data Security, you can choose to create archive partitions sooner and keep fewer concurrent restored archives. Refer to the TRITON - Data Security Help section, Archiving incidents, for more information on archiving.
17
The Extract, Transform, and Load (ETL) job runs continually, receiving data from Log Server, processing it, and then inserting it into the partition database. The ETL job must be running to process log records into the Log Database. The database maintenance job performs database maintenance tasks. This job runs nightly, by default. The Web Security Log Database also installs: The Internet browse time (IBT) job analyzes the qualified data received and calculates browse time for each user. The IBT database job is resource intensive, requiring significant server resources. This job runs nightly, by default. When configuring the start time for the maintenance job and the Internet browse time job, consider system resources, network traffic, and IT maintenance schedule. These jobs are resource intensive and time consuming, so they can have a negative impact on logging and reporting performance. Both Log Database applications require the SQL SERVER AGENT service to be running when a Standard or Enterprise edition of Microsoft SQL Server is used. ETL jobs are run, then re-run 20 seconds after they finish for these editions. Maintenance jobs are run once every night by default. The jobs are run automatically. For SQL Express databases, Websense uses Service Broker rather than SQL SERVER AGENT to run database jobs.
19
The catalog database provides a single connection point for the various components that need to access the Log Database: Log Server, the Email Security Gateway quarantine daemon, and TRITON - Email Security (presentation reports, dashboard, log database configuration page). It also includes definitions for the following: Email Security Gateway action s Mail direction Message type DLP severity-level Email Security Gateway appliance mapping Email Security Gateway policies Rules Viruses DLP policy names IP addresses Email addresses Domains Database jobs The catalog database also maintains a list of all the database partitions. Database partitions store the individual log records, including connection log, message log, policy log, delivery log, status log, hosted status log. New partitions are created based on size (5 GB, by default) or date interval.
21
How do I and how often should I backup and restore the database?
Each enterprise should govern its own backup/restore policy. You can schedule full backups or run them manually at any time. For best practice, you should run backup at least weekly.
To configure these settings: 1. Select Settings > Deployment > System Modules. 2. Select Secondary Fingerprint Repository under the Data Security component of interest. 3. Choose the repository from which to detect fingerprints. 4. Set the maximum cache size and synchronization frequency as needed. See the TRITON - Data Security Help section, Configuring the fingerprint repository, for instructions on configuring these settings.
23
The Master Database is completely transparent to end users and requires no maintenance. See the TRITON - Web Security Help section, The Websense Master Database, for further details.