Administering Websense Databases

v7.6

Administering

Websense Databases

Websense® TRITON Enterpr ise

©2011, Websense Inc.All rights reserved.10240 Sorrento Valley Rd., San Diego, CA 92121, USA

Published 2011Printed 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.

1

Administering Websense Databases � 1

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 modules—Web 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?

Administering Websense Databases

2 ⊳ Administering Websense Databases

Overview of Websense databases

There are several databases used by Websense software.

Websense TRITON Reporting Database

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.

Database Description

Websense TRITON Reporting Database

Stores reporting and logging data for all TRITON modules. Also stores Data Security configuration data.

Websense TRITON Settings Database

Stores global TRITON configuration settings.

Websense Data Security Fingerprint Database

Stores Data Security fingerprints.

Websense Data Security Forensics Database

Stores details about each DLP incident, such as the email message or attachment that breached policy and the rules were breached.

Websense RTM Database Holds and organizes filtering data for display in Real-Time Monitor.

Websense Master Database Contains URL categories and protocol definitions, as well as supporting information (like risk class groupings).

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



� 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 machine’s 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, you’ll 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 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.

*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.

Windows

Server

2003 R2

32-bit*

Windows

Server

2008

32-bit

Windows

Server

2008 R2

64-bit

V-series

appliance

Data Security x x

Web Security x x x x

Email Security x

SQL

Server

2005*

SQL

Server

2008**

SQL

Server

2008 R2

Express

SQL

Server

2008

R2***

Data Security x x x

Web Security x x x x

Email Security x x x



***All editions except Web and Compact; all service packs, 32- and 64-bit, excluding

IA64.

System configuration recommendations

The performance of Websense’s 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 Microsoft’s 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.

Note

Clustering is supported for all supported versions of SQL

Server noted above.

http://msdn.microsoft.com/en-us/library/ms143506.aspx

http://technet.microsoft.com/en-us/library/ms143506%28SQL.100%29.aspx

http://www.microsoft.com/sqlserver/2005/en/us/system-requirements.aspx

http://msdn.microsoft.com/en-us/library/ms143506%28v=sql.90%29.aspx



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 Websense’s 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 modules—Web Security, Email Security, and Data Security—and 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

http://www.websense.com/support/article/t-kbarticle/VMware-support

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.

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.

Web Security

Use the following table to help estimate the size of your Websense Web Security Log

Database.

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.

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 system’s actual performance once it

has been in place for a few days or weeks and reassess

database sizing needs at that time.

If You Are Logging URL Host

Names (default)

If You Are Logging Full URLs

If Data Reduction is Enabled (default)

10 MB per user per month 13 MB per user per month

If Data Reduction is Disabled

25 MB per user per month 33 MB per user per month



33 MB * 7500 users * 4 months = 967 GB

In addition, you need to calculate space for the following:

� The database’s 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 database’s 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

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 database’s 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

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.



(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 database’s 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.

Note that Websense Email Security’s 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

Total

messages

per month

100

million

50

million

25

million

10

million

5

million

2

million

1

million

Inbound - without hybrid

304 GB 152 GB 76 GB 30 GB 15 GB 6 GB 3 GB

Inbound - with hybrid

260 GB 130 GB 65 GB 26 GB 13 GB 5 GB 3 GB

Outbound 290 GB 145 GB 73 GB 29 GB 15 GB 6 GB 3 GB

Internal 290 GB 145 GB 73 GB 29 GB 15 GB 6 GB 3 GB



Data Security Incident and Configuration Database, you need to estimate your usage

patterns of the following features:

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

Feature Impact on Database Size

Discovery incidents

(not standard with Websense TRITON Enterprise)

14 KB per incident

Typically, no more than 3.5 GB total

Network and endpoint incidents 10 KB per incident

Typically, 30 KB per user per month

User directory import data 8 KB per record

Typically, no more than 1 GB total

Configuration data 200 MB



that limit still meets your data retention requirements. If so, you can use SQL Server

2008 R2 Express.

* 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 second—as opposed to average number per

second—is 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

Note

Data Security alone can support up to 5000 users with

SQL Server 2008 R2 Express.

Users Web* Web and Data Email** and

Data

Web, Email and

Data

Over 2000 users

Not recommended Not recommended Not recommended Not recommended

2000 45 days 30 days Not recommended Not recommended



750 4 months 3 months Not recommended Not recommended

500 6 months 4 months 30 days Not recommended

250 1 year 8 months 60 days 30 days

100 More than 1 year 1 year 5 months 3 months



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 site—for 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 Security’s 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.

http://www.websense.com/content/support/library/web/v76/ls_cfg/first.aspx



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.

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 Discovery is not included in Websense TRITON

Enterprise. It is an add-on feature that requires a separate

subscription.

Note

Data Endpoint is not included in Websense TRITON

Enterprise. It is an add-on feature that requires a separate

subscription.

http://www.websense.com/content/support/library/data/v76/help/Inc Rep Disc.aspx

http://www.websense.com/content/support/library/data/v76/help/Inc Rep Disc.aspx



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).

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 directory—such as Active Directory or Domino—into 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 directory’s 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.


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.

Partition type Microsoft SQL Server

Standard or Enterprise

SQL Server Express

Active 1 partition (current quarter) 1 partition (current quarter)

Online up to 8 partitions (2 years) up to 4 partitions (1 year)

Restored up to 4 partitions (1 year) up to 4 partitions (1 year)

Archived up to 12 partitions (3 years) up to 12 partitions (3 years)

Total available managed partitions

25 21

http://www.websense.com/content/support/library/data/v76/help/archiving incidents.aspx

http://www.websense.com/content/support/library/data/v76/help/Archive Storage.aspx



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

http://www.websense.com/content/support/library/web/v76/triton_web_help/logging_options_explain.aspx

http://www.websense.com/content/support/library/web/v76/triton_web_help/logging_options_explain.aspx

http://www.websense.com/content/support/library/data/v76/help/Add new UD server.aspx



time window, invest in more hardware resources for your reporting system—more

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 system—more 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 Security’s reporting system calculates Internet browse time

each night at 2 a.m. for the previous day’s activity, though this is configurable. This is

a memory-, processor-, and disk I/O-intensive activity. If you don’t 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.

http://www.websense.com/content/support/library/web/v76/triton_web_help/log_db_ibt_config.aspx

http://www.websense.com/content/support/library/web/v76/triton_web_help/log_db_rollover_options.aspx



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

system—more 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.

http://www.websense.com/content/support/library/email/v76/esg_help/viewing_log_database_error_log_esg.aspx




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 you’re 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 you’re 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.



� 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 you’re interested in is in a

partition, you must bring the partition online, or you won’t 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.




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.


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 Real-

Time 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.

It’s 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.

http://www.websense.com/content/support/library/data/v76/help/edit FP repos.aspx



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.

http://www.websense.com/content/support/library/web/v76/triton_web_help/master_database.aspx

http://www.websense.com/content/support/library/web/v76/triton_web_help/master_database.aspx

Documents

Administering Websense Databases