Administering Websense Databases

A dmi nis t er in g Web se ns e D at a ba se s
We bsense TRI TON E nte rpr ise
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.
Administering Websense Databases

Websense software makes use of several database systems. This paper is designed to help database administrators understand the requirements of Websense databases across all Websense TRITON modulesWeb Security, Email Security, and Data Security. In this document, you will learn: What are the various databases? What database versions does Websense support? What hardware and operating systems are recommended? How will my database size? How big will my reporting database be? Can I use SQL Server 2008 R2 Express? What determines the size of my database? What affects the performance of my reporting system? Which database tools does the reporting database require or use? Which permission sets does Websense require? Which database jobs are run by the databases? What is involved in database setup? How big should the database partitions be? How many partitions can be accessed at the same time? How do I configure partition rollover? What if I need more partitions to run reports? (reports get split) Does Websense utilize database instances? How do I and how often should I backup and restore the database?
Overview of Websense databases

There are several databases used by Websense software.
Database Websense TRITON Reporting Database Websense TRITON Settings Database Websense Data Security Fingerprint Database Websense Data Security Forensics Database Websense RTM Database Websense Master Database Description Stores reporting and logging data for all TRITON modules. Also stores Data Security configuration data. Stores global TRITON configuration settings. Stores Data Security fingerprints. Stores details about each DLP incident, such as the email message or attachment that breached policy and the rules were breached. Holds and organizes filtering data for display in RealTime Monitor. Contains URL categories and protocol definitions, as well as supporting information (like risk class groupings).
Websense TRITON Reporting Database
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.
2 Administering Websense Databases
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.
Local database system

For smaller deployments, the TRITON Reporting Database can be installed on the TRITON management server. This is considered a local database. The TRITON Unified Security installer automatically installs SQL Server 2008 R2 Express (32-bit) for use as the local TRITON Reporting Database when you select Install SQL Server Express on this machine during installation. SQL Server 2008 R2 Express is the only version of SQL Server that should be used as the local TRITON Reporting Database. If you are upgrading form a previous version of Web Security and you have a different version of SQL Server installed on the same machine as the TRITON management server, you can reuse that database by selecting Use existing SQL Server on another machine but specifying the local machines IP address or host name. This is not recommended, however. For best practices, you should move your TRITON Reporting Database to a different machine for improved performance and a better overall product experience. The 32-bit version of SQL Express can be installed on several different operating system platforms. In the table below, youll see that Web Security supports 4 platforms for the TRITON Reporting Database. Data Security, however, supports only
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).
Remote database system

The TRITON Reporting Database can also be installed on a remote machine. This is best practice for medium to large deployments that require a more robust version of Microsoft SQL Server, such as SQL Server Standard or Enterprise. When installing Websense software, you need to provide the IP address or host name of the remote machine where SQL Server is located. The following databases are supported. Note that you cannot use SQL Server 2005 for the reporting database if you plan to run Data Security or Email Security.
SQL Server 2005* Data Security Web Security Email Security x SQL Server 2008** x x x SQL Server 2008 R2 Express x x x SQL Server 2008 R2*** x x x
*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.
System configuration recommendations

The performance of Websenses reporting solutions can be heavily dependent on the the server machine and the configuration of its underlying resources. The more you invest in the system where your Websense reporting system runs, the better the reporting system will perform. For optimal results, use Microsoft Windows Server 2008 R2 64-bit Enterprise Edition and SQL Server 2008 R2 Enterprise Edition for the TRITON Reporting Database. Consider the following factors when designing your database system.
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
TRITON Reporting Database sizing

The following sections provide information that will help you estimate the data storage requirements for your TRITON Reporting Database. They cover all 3 Websense modulesWeb Security, Email Security, and Data Securityand provide information on the features of each Websense module that affect the performance and scalability of that system. How big will my reporting database be? Can I use SQL Server 2008 R2 Express? Factors that affect database size Other factors that affect the performance of Websense reporting TRITON Reporting Database FAQs
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.
How big will my reporting database be?

When estimating the size of your TRITON Reporting Database, keep the following factors in mind: Data Security logs only data violations, which typically represent a small fraction of your total Web and email volume. Email security logs detected spam and quarantined email messages, which typically represent up to 90% of your email volume. Web security logs all Web transactions, which typically represent about 40% of your total Web traffic volume, after Websense applies its proprietary data reduction algorithm, enabled by default. See Websense Web Security data reduction algorithms, page 11 for details. Warning These are averages calculated across a large number of Websense customers with widely varying deployments. While these numbers are useful for estimation, it is best practice to analyze the systems actual performance once it has been in place for a few days or weeks and reassess database sizing needs at that time.
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
25 MB per user per month
33 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.
33 MB * 7500 users * 4 months = 967 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 (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
The grand total required in our example, then, is:

225 GB + 67 GB + 450 GB + 135 GB = 877 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
100 million 304 GB 260 GB 290 GB 290 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.
Can I use SQL Server 2008 R2 Express?

Microsoft SQL Server 2008 R2 Express is the free version of Microsoft SQL Server 2008 R2. Websense TRITON Enterprise embeds SQL Server 2008 R2 Express into the installer for optional use as the TRITON Reporting Database. In order to provide an explicit incentive to its customers to purchase a paid version of SQL Server, Microsoft limits the amount of hardware resources that SQL Server 2008 R2 Express can utilize, no matter what the underlying hardware provides. These limits are: 1 GB of RAM 1 physical CPU 10 GB of data per database This results in practical limits on the amount of data that can be stored in SQL Server 2008 R2 Express, while still maintaining acceptable performance when generating reports and processing log data. For best performance, no more than 30 GB of data should be stored in SQL Server 2008 R2 Express across all Websense modules. The sizing recommendations below are based on this assumption. For an explanation of particular demands that Websense reporting places on available memory, see Other factors that affect the performance of Websense reporting, page 15. Use the charts below to see how much data you can store using SQL Server Express based on the Websense module or modules you are using. You can then determine if
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
45 days 60 days 90 days 4 months 6 months 1 year More than 1 year
30 days 45 days 60 days 3 months 4 months 8 months 1 year
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.
Factors that affect database size

Web Security
Websense Web Security data reduction algorithms
Websense Web Security uses proprietary algorithms to reduce the volume of log data in order to achieve a balance between visibility into users Web browsing activity and the size and performance of the TRITON Reporting Database. The data reduction algorithms focus on narrowing the amount of data logged so that a single log record represents just the site that the end user browsed to, instead of generating records for
Administering Websense Databases 11
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.
Logging URL host names versus full URLs

By default, Websense Web Security logs only the URL host name for each request, instead of the full URL. Storing the full URLs provides more visibility into where users are going within a particular Web site, but increases the data storage demands of the TRITON Reporting Database. Note that many major Web sites use sub-domain as a way to identify a particular part of their sitefor example, finance.yahoo.com, mail.yahoo.com, and jobs.yahoo.com. Websense Web Security logs the sub-domain portion of a URL host name by default; you do not need to enable full URL to have visibility into sub-domains that your users browse. Enabling full URL logging can increase the size of each record in Web Security by 33%. Accordingly, this reduces the amount of data that can be stored in any particular log database system by as much as 25%. 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.
Above average email traffic: recipients, quarantined messages, or spam

The sizing guidelines above are based on the following assumptions about the email traffic handled by Email Security Gateway. These assumptions are derived from the average email traffic pattern of Websense customers over time. There are an average of 5 recipients for each email message. The message volume is one message per user per minute. Under non-hybrid mode, there is a ratio between spam messages, infected messages, and clean messages of 85-to-1-to-14. The hybrid service scans only inbound email traffic, and it can block 25 percent of spam. All inbound and internal email messages are clean.
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.
Rate of network and endpoint incidents

The rate of network and endpoint incidents detected varies widely across Websense customers. The sizing guidelines above are based on an average incident rate of 1 per user every 10 days (an incident is a policy violation). For best practice, periodically review the actual incident rate in the database to gauge how closely your environment matches this average, and then adjust your database storage requirements based on the actual data in your environment. Do this by examining the Incident Trends report found in TRITON - Data Security under Main > Reporting. Note Data Endpoint 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.
Size of user directory import

To support user-based policy and reporting, Websense Data Security imports entries from your user directorysuch as Active Directory or Dominointo the Data Security Configuration Database. Depending on the size and design of your user directory, this can result in database space being consumed by entries that are not needed by Data Security. To reduce the number of imported user directory entries: Configure Data Security to import entries from a more specific root context that is deeper in the tree than the directorys root context. Restrict the user attributes that are imported by specifying specific attributes to import; or eliminate them altogether by disabling the import of user attributes. To configure user directory settings: 1. Log onto TRITON Console. 2. Select the Data Security tab. 3. Select Settings > General > System. 4. Select the User Directories option from the System pane. 5. Select the user directory to edit. 6. Modify or add a root naming context. 7. Modify the user attributes settings.
Refer to the TRITON - Data Security Help section, Add a new user directory server, for information on configuring these settings.
Other factors that affect the performance of Websense reporting

TRITON Console location
The Websense TRITON Console can be deployed on the same machine as SQL Server and the TRITON Reporting Database. For smaller enterprises and SQL Express, this is appropriate. For larger enterprises using SQL Server Standard or Enterprise, however; best practice is to deploy SQL Server on a separate physical machine from the TRITON Console.
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.
Use of Detail Reports over long time periods

Reports of Web browsing activity over long time periods (weeks and or months) require much more memory, processor time, and disk I/O to generate. For better performance, run summary reports across long time periods on a regular schedule, then use detail reports only for investigating specific users in shorter time periods. If you have business requirements that demand generating detail reports across a large
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.
Number of scheduled reports or number of delegated reporting administrators

If you have more than 10 delegated reporting administrators that use reporting each day or create more than 10 scheduled reports to run each night, this can degrade the performance of your Websense reporting system. 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.
Geo-location of user populations

If you have users distributed among multiple physical locations and your business does not require unified reporting across all users, consider deploying separate Websense reporting systems in each location.
Calculation of Internet browse time

By default, Websense Web Securitys reporting system calculates Internet browse time each night at 2 a.m. for the previous days activity, though this is configurable. This is a memory-, processor-, and disk I/O-intensive activity. If you dont use Internet browse time to manage your users Web browsing activity, consider disabling Internet browse time to improve the performance of your reporting system. For information on configuring Internet browse time in Websense Web Security, refer to the TRITON - Web Security Help topic, Configuring Internet browse time options.
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
TRITON Reporting Database FAQs

Which database tools does the reporting database require or use?
Websense TRITON connects to the SQL Server database engine as a client and performs standard Transact-SQL commands and stored procedures. Web Security and Email Security Gateway use 2 database utilities: bcp - to bulk insert logs into database. osql - to run SQL scripts during Web Security Log Database and Email Security Log Database installation.
Which permission sets does Websense require?

The product should be given an account to access the database-instance with the sysadmin server role. This account is used to create specific databases for the product during installation. After installation is complete, the account privileges can be reduced to the db owner of the newly created databases, and no access to any other user database except system databases such as master, tempdb, and model. When using a remote database, backup database permission on the master database is required for the period of installation only. To install the Web Security Log Server and Email Security Log Server successfully, the user account that owns the Websense database must have membership in one of the following roles in the msdb database: SQLAgentUserRole SQLAgentReader Role SQLAgentOperator Role It must also: Have membership in the db_datareader role in the msdb database Be a member of the dbcreator fixed server role If youre using SQL Express 2008 R2, SQL Server 2008 R2 or 2005 (Standard or Enterprise), the installation account must have the following in order to create the Log Database correctly: dbcreator server role SQLServerAgentUser permission or above sysadmin permissions (for Email Security) If youre using SQL Server Express, it must have: sysadmin permissions
Which database jobs are run by the databases?

The following database jobs are installed with the Web Security Log Database and Email Security Log Database:
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.
What is involved in database setup?

The TRITON Reporting Database should allow TCP and trusted-mode connections from the TRITON management server, the Email Security Gateway log server, and the Web Security Gateway log server, as well as from the any email-capable V-10K appliance, whether email mode or email and Web dual mode. By default, the Web Security Log Databases includes one catalog database and one partition, though they usually have more. The catalog database provides a single connection point for the various components that need to access the Log Database: Log Server, presentation reports, and investigative reports configuration. It also contains definitions for the following: Category names Risk classes Users User-to-group mapping Database jobs The catalog database also maintains a list of all the database partitions. Database partitions store the individual log records of Internet activity. New partitions are created based on size (5 GB, by default) or date interval. The Email Security Log Database also includes one catalog database and one partition. However they contain different information.
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.
How big should the database partitions be?

For Data Security, see Rate of network and endpoint incidents, page 13. For Web Security, see Partitioning, page 16. For Email Security, see Partitioning, page 17.
How many partitions can be accessed at the same time?

Data Security maintains incident partitions independently of the database engine, based on quarters (3-month periods). By default, 8 partitions are online simultaneously on the SQL Express edition, and 12 are online on other editions of SQL Server. You can choose to move any number of partitions online simultaneously as long as your disk space and SQL Server database permit it. See Number of concurrent partitions and partition archiving configuration, page 17 for more information. With Web Security Gateway and Email Security Gateway, you can access all partitions at the same.
How do I configure partition rollover?

In Data Security, this is done by selecting Settings > Archive in TRITON - Data Security. On this screen, you configure when to create an archive partition and when to restore it. For instructions, refer to the TRITON - Data Security Help section, Archiving incidents. In Email Security and Web Security, when partitions are based on size, all log records are inserted into the most recent active partition that satisfies the size rule. When the partition reaches the designated maximum size, a new partition is created for inserting new log records. When the partitions are based on date, new partitions are created according to the established cycle. For example, if the rollover option is monthly, a new partition is created as soon as any records are received for the new month. Log records are inserted into the appropriate partition based on date.
What if I need more partitions to run reports? (reports get split)

When you want to run a report and some or all of the data youre interested in is in a partition, you must bring the partition online, or you wont get the entire report. If reports are still getting split, the limit is likely your SQL Server license and disk limits. You can purchase more hardware or a more generous SQL Server license.
Does Websense utilize database instances?

You can run multiple instances of SQL Server on the same hardware platform, and Websense uses SQL Server for its reporting databases. If you have installed SQL Server Standard or Enterprise on a remote SQL Server machine, you have 3 options: The Email Security Log Database, Web Security Log Database, and Data Security Incident and Configuration Database can each be in its own database instance pointing to one TRITON management server (3 database instances). The Web Security Log Database can be on its own database server (in one instance) and the Email Security Log Database and Data Security Incident and Configuration Database can be on another server (in 1 or 2 instances.) or You can have all 3 applications (Email Security Log Database, Web Security Log Database, and Data Security Incident and Configuration Database) in the same SQL Server instance, pointing to one management server. For scalability, you can add another database instance with secondary Data Security and Web Security databases, and these can point to a second management server.
Do we need failover to be enabled or disabled?

Websense software does not support failover settings.
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.
Websense TRITON Settings Database

The TRITON Settings Database is embedded in Websense software. It is used to store global TRITON configuration and infrastructure settings. TRITON settings are not stored in SQL Server; they are in a PostgresSQL open source database for all topologies. Web Security and Email Security policy data is also stored in Postgres. The TRITON Settings Database is always installed on the TRITON management machine and it is transparent to end users.
Websense Data Security Fingerprint Database

One of the ways that you can classify data in Websense Data Security is by fingerprinting it. This lets Data Security detect sensitive information despite manipulation, reformatting, or other modification. Fingerprints enable the protection of whole or partial documents, antecedents, and derivative versions of the protected information, as well as snippets of the protected information whether cut and pasted or retyped. When you fingerprint data, the fingerprints are stored in the Data Security Fingerprint Database on the TRITON management server and pushed to other Data Security components for fast analysis on those machines. To tune performance, you can configure the disk space and cache size of the database on the management server in TRITON - Data Security. To do so: 1. Log onto the TRITON Console. 2. Select the Data Security tab. 3. Select Settings > Deployment > System Modules. 4. Select Primary Fingerprint Repository under the management server. 5. Adjust the maximum disk space and cache size as needed. Secondary repositories are stored on other Data Security components such as Websense Content Gateway and Email Security Gateway. You can configure Data Security to detect fingerprints from repositories local to those machines (best practice) or from a remote machine, such as the management server. Periodically, you must synchronize the fingerprints on the Data Security components with the ones on the management server. How often you synchronize depends on your business needs. For best performance, select a time with low traffic volume.
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.
Websense Data Security Forensics Database

The Data Security Forensics Database contains information about DLP and discovery transactions that resulted in incidents, such as the contents of an email body: From:, To:, Cc: fields; and actual attachments. Transactions can also include Web posts, endpoint operations, and discovered as well as other events. For transactions that occurred on a Web channel, the forensics might include the URL category property. For discovery transactions, forensics might include the host name and file name. You can configure the size and location of the forensics repository in TRITON - Data Security. Navigate to Settings > Deployment > System Modules and click Forensics Repository on the management server.
Websense RTM Database

The Websense RTM Database holds and organizes filtering data for display in RealTime Monitor. This is an independent database, not hosted by SQL Server, installed with an RTM Client and RTM Server instance. If multiple instance of Real-Time Monitor are installed, each has its own RTM Database. The RTM Database is completely transparent to end users and requires no maintenance.
Websense Master Database

The Websense Master Database contains URL categories and protocol definitions, as well as supporting information, such as risk class groupings. Its hosted on the Filtering Service machine (one copy for each instance of Filtering Service). By default, a full update is performed daily. Incremental updates can occur much more frequently if enabled, most typically by the security administrator.
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.

Administering Websense Databases

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Administering Websense Databases

Загружено:

Авторское право:

Доступные форматы

A dmi nis t er in g Web se ns e D at a ba se s

We bsense TRI TON E nte rpr ise