Trustwave Dbprotect Installation Guide Version 6.4.9 Trustwave Dbprotect 6.4.9 Installation Guide - January 6, 2017

Trustwave DbProtect Installation Guide Version 6.4.9 Trustwave DbProtect 6.4.9 Installation Guide - January 6, 2017

Legal Notice

All rights reserved. This document is protected by copyright and any distribution, reproduction, copying, or decompilation is strictly prohibited without the prior written consent of Trustwave. No part of this document may be reproduced in any form or by any means without the prior written authorization of Trustwave. While every precaution has been taken in the preparation of this document, Trustwave assumes no responsibility for errors or omissions. This publication and features described herein are subject to change without notice.

While the authors have used their best efforts in preparing this document, they make no representation or warranties with respect to the accuracy or completeness of the contents of this document and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the author nor Trustwave shall be liable for any loss of profit or any commercial damages, including but not limited to direct, indirect, special, incidental, consequential, or other damages.

The most current version of this document may be obtained from:

www.trustwave.com/Company/Support/

Trademarks Trustwave and the Trustwave logo are trademarks of Trustwave. Such trademarks shall not be used, copied, or disseminated in any manner without the prior written permission of Trustwave.

Revision History

Version Date Changes

6.4.6 November 2015 Updated version of DbProtect Installation Guide

6.4.7 May 2016 Updated for DbProtect 6.4.7 (Scan Engine 3.0)

6.4.8 June 2016 Updated for DbProtect 6.4.8 (Maintenance Release)

6.4.9 January 2017 Updated for DbProtect 6.4.9 (Scan Engine 3.2)

Formatting Conventions

This manual uses the following formatting conventions to denote specific information.

Format and Meaning Symbols

Blue Underline A blue underline indicates a Web site or email address.

Bold Bold text denotes UI control and names such as commands, menu items, tab and field names, button and check box names, window and dialog box names, and areas of windows or dialog boxes.

Code Text in this format indicates computer code or information at a command line.

Italics Italics are used to denote the name of a published work, the current document, or another document; for text emphasis; or to introduce a new term. In code examples italics indicate a placeholder for values and expressions.

[Square brackets] In code examples, square brackets indicate optional sections or entries.

Note: This symbol indicates information that applies to the task at hand.

Tip: This symbol denotes a suggestion for a better or more productive way to use the product.

Caution: This symbol highlights a warning against using the product in an unintended manner.

Table of Contents

Legal Notice...... ii

Revision History...... iii

Formatting Conventions ...... iii

1 Introduction 7

1.1 Intended Audience ...... 7 1.2 DbProtect Components...... 7 1.3 Console...... 8 1.4 Scan Engines ...... 8 1.5 Sensors...... 8 1.6 Host-Based Sensors ...... 9

2 Planning Your DbProtect Installation 10

2.1 DbProtect Installation Checklist ...... 10 2.2 Networking, Port, and Firewall Considerations ...... 10 2.2.1 Networking Considerations ...... 10 2.2.2 Port Considerations...... 11 2.2.3 Firewall Considerations...... 11 2.3 Data Repository ...... 11 2.3.1 Data Repository Options...... 12 2.4 Scan Engine Compatibility ...... 12 2.5 Determining the Version of Components ...... 13

3 Minimum System Requirements 14

3.1 DbProtect Suite System Requirements...... 14 3.2 Scan Engine System Requirements ...... 16 3.3 Typical Deployment: Recommended System Requirements ...... 16 3.3.1 Typical System Specifications...... 17 3.3.2 Target Platforms ...... 17 3.3.3 Example Architecture 1...... 18 3.3.3.1Recommended Requirements for the Console Server ...... 18 3.3.4 Recommended Requirements for the MSSQL Server ...... 19 3.4 Example Architecture 2...... 19 3.4.1 Recommended Requirements for the Console Server ...... 19

4 Licensing 21

4.1 Licenses are now Centrally Stored ...... 21

4.2 Working Product after License Overage ...... 21 4.3 Recover Licenses when Asset is no Longer Needed ...... 21 4.4 Review License Usage ...... 22 4.5 Compliance Packs ...... 22

5 Installing the DbProtect Components 23

5.1 Installing DbProtect Suite ...... 24 5.2 Enterprise Services Host Setup ...... 25 5.3 Database Component Setup...... 26 5.4 Installing the SHATTER Knowledgebase ...... 29 5.5 Data Warehouse Setup...... 29 5.6 DbProtect Analytics Setup ...... 33 5.7 Installing Scan Engines...... 37 5.7.1 DbProtect Scan Engine Setup ...... 38 5.8 Installing Sensors ...... 40 5.9 Creating Your Own Microsoft SQL Server AppDetective Database ...... 41

6 Your Initial DbProtect Login 42

6.1 Prerequisite...... 42 6.2 Important Considerations for Using DbProtect With Google Desktop...... 42 6.2.1 Important Considerations for Using DbProtect With Internet Explorer ...... 42 6.2.2 Logging in to the Console ...... 42 6.3 Logging Into the DbProtect Console Using SSO ...... 44

7 Uninstalling the DbProtect Components 46

7.1 Before You Uninstall the DbProtect Suite Components ...... 46 7.2 Uninstalling the DbProtect Suite Components from the Start Menu ...... 46 7.3 Uninstalling and Unregistering a Sensor...... 46 7.3.1 Uninstalling a Sensor (on Windows) ...... 47 7.3.2 Uninstalling and Unregistering a Scan Engine ...... 47 7.3.2.1Unregistering a Scan Engine ...... 47 7.3.2.2Uninstalling a Scan Engine ...... 47

8 Installation Troubleshooting 48

8.1 How do I contact Customer Support? ...... 48 8.2 I uninstalled DbProtect without unregistering my Sensors. How can I re-register my Sensors without reinstalling them? ...... 48 8.3 Are there firewall issues I should consider? ...... 48 8.4 Do I require domain administrator rights after I install a Sensor on a cluster? ...... 48 8.5 The following message appears: “Error Occurred. The DbProtect database is not available at the moment. Please retry your request later.” What should I do?...... 48

8.6 Why am I displaying a blank page on the DbProtect Console UI? ...... 49 8.7 I am having trouble establishing a connection between the Console and my Sensor on Microsoft Windows 2008...... 49

Appendix A: Network Ports Used by DbProtect ...... 50

Appendix B: Modifying the LogOn As User for DbProtect Services ...... 51

B.1 What is the “Log On As” User?...... 51 B.2 Modifying the Windows Authentication LocalSystem Account ...... 51

Appendix C: DbProtect Log Files ...... 52

C.1 DbProtect Log Files ...... 52 C.1.1 DbProtect Installation and Upgrade Log Files ...... 52 C.2 Replay Log Files...... 52 C.2.1 Sensor Installation and Upgrade Log File ...... 53 C.3 Scan Engine Log Files ...... 53 C.3.1 Scan Engine Installation and Update Log Files ...... 53 C.3.2 Scan Engine Application Log Files...... 53

Appendix D: Required Client Drivers for Audits (Scan Engine Host Only) ...... 55

Appendix E: Required Audit Privileges...... 57

Appendix F: Auditing SQL Server (Using Windows Authentication) Against a Machine on a Different or Un- trusted Domain ...... 59

1 Introduction

DbProtect is a data security platform that uncovers database configuration mistakes, identification and access control issues, missing patches, or any toxic combination of settings that could lead to escalation of privileges attacks, data leakage, denial-of-service (DoS), or unauthorized modification of data held within data stores (relational databases and Big Data). Through its multi-user/role-based access, distributed architecture, and enterprise-level analytics, DbProtect enables organizations to secure all of their relational databases and Big Data stores throughout their environment, on premise or in the cloud.

1.1 Intended Audience This guide is intended for persons using DbProtect on a day-to-day basis. Typically, users responsible for installing DbProtect have the following (sometimes overlapping) job roles.

• System Administrators

• Network Administrators

• Database Administrators

1.2 DbProtect Components The following diagram illustrates how DbProtect components interact and shows which standard listening ports must be open for DbProtect to work.

1.3 Console The Console is the web browser-based, graphical component of DbProtect that allows you to navigate to the various features of DbProtect.

The DbProtect Suite installer consists of the following components.

• Dbprotect Setup: support files that enable DbProtect upgrades and removal.

• DbProtect Enterprise Services Host: an application server that manages remote connections to the system and various services that perform DbProtect functions.

• DbProtect Console Management Server: the browser-based graphical interface.

• DbProtect Enterprise Services: services that implement support for various features visible in the GUI.

• DbProtect Naming and Directory Service: a service locator directory.

• DbProtect Message Collector: a service that collects and stores alerts from sensors.

• DbProtect Analytics: a service that performs reporting functions.

• DbProtect Analytics Content: a collection of reports and dashboards.

• DbProtect VA Policy Editor: vulnerability assessment policy editing module.

• DbProtect Documentation and Content: includes this guide and other reference documentation.

• DbProtect Scan Engine Proxy: a load-balancing service for Scan Engines.

1.4 Scan Engines Scan Engines are network-based services that discover database applications within your infrastructure and assess their security strength by running penetration tests, audits and user rights reviews.

DbProtect Scan Engine consists of the following components.

• DbProtect Scan Engine Host: an application server that manages various services that connect to target databases.

• DbProtect Scan Engine: a service that performs database discovery and vulnerability assessment functions.

• DbPRotect Rights Management Service: a service that performs user rights reviews.

1.5 Sensors Sensors monitor your database for various events, such as intrusion attempts or auditing of normal usage. Sensors send alerts when they detect a violation of rules, and a monitored event occurs. Two types of Sensors are available: host-based Sensors and network-based Sensors.

1.6 Host-Based Sensors The table below lists all supported host-based database/OS combinations. The Sensor Readme file contains details on the supported versions of each of the below.

Table 1: Host Based Sensors

DB OS

Microsoft SQL Server Windows

IBM DB2 LUW (Linux, Unix, Linux Windows) Solaris AIX Windows

IBM DB2 z/OS Linux

Oracle Linux Solaris AIX HP-UX Windows

SAP (Sybase) ASE Solaris AIX

See the Sensor Readme file for information on network-based Sensors and supported database/OS combinations.

2 Planning Your DbProtect Installation

2.1 DbProtect Installation Checklist Below is a checklist for a typical DbProtect installation scenario:

Table 2: DbProtect Installation Checklist

Task

1. REVIEW THE MINIMUM SYSTEM REQUIREMENTS. Before you install DbProtect, read the minimum system requirements, prerequisites, and recommendations for: •Console • Scan Engines • Sensors (host-based or network-based) • For more information, see “Minimum System Requirements” on page 14.

2. OBTAIN THE LICENSE FILES. For more information, see “Licensing”.

3. INSTALL THE DBPROTECT COMPONENTS. Trustwave provides you with the installation files for: • the DbProtect management bundle, which includes the Console • Sensors (host-based or network-based) • Scan Engines (the Console and the Scan Engines run on Windows; the host- and network-based Sensors, however, can run on a variety of database/OS combinations) For more information, see “Installing the DbProtect Components” on page 23.

2.2 Networking, Port, and Firewall Considerations DbProtect requires various networking, port, and firewall conditions.

2.2.1 Networking Considerations Network connectivity is required for various services to communicate with each other. For example, the Console must be able to communicate with the Scan Engines and Sensors, and, optionally, with SNMP and Syslog systems. While the system has some fault tolerance built in, you should install it on servers that are continuously connected to the network.

In addition, the following networking requirements apply specifically to network-based Sensors:

• The network-based Sensor machine must be on the same Local Area Network (LAN) as the database machine(s) that it is monitoring, or otherwise have access to network traffic going to/coming from each database machine being monitored. You can accomplish this using a variety of methods, including a

Switched Port Analyzer (SPAN) port on a Cisco switch, a mirror port, Network Tap, a Data Aggregator device, or re-direction using VLANs.

• Two network interface cards (NICs) are recommended, i.e., one for communication from the network- based Sensor to the Console, and one to capture database traffic.

• The network environment must be standard Ethernet (10MB, 100MB, or 1GB -- whatever standard Ethernet card the machine supports). Unsupported environments include ATM, Token Ring and FDDI.

2.2.2 Port Considerations The system uses serval ports for external communication. Default values can be changed in some cases. You may need to work with your network administrators to open various ports depending on your deployment topology.

• By default, the Enterprise Services Host, and therefore the Console Management Server uses port 20080.

• Message Collector receives alerts from Sensors on port 20081.

• Scan Engines receive commands from the Console Management Server on port 20001.

• Sensors receive commands from the Console Management Server on port 20000. Other ports are used for internal communication and do not require any firewall or network changes. For a detailed list of all ports used refer to the table in “Network Ports Used by DbProtect”.

2.2.3 Firewall Considerations You must allow DbProtect traffic through firewalls.

The Console Management Server uses the HTTPS protocol on port 20080. This port must be opened to those users that are accessing the DbProtect system from their desktop machines.

While recommended, it is not required to restrict any traffic between Scan Engines and Sensors as DbProtect uses its own authentication mechanisms to restrict traffic within the system. For example, Trustwave recommends you disallow all traffic to the Message Collector port 20081 except from the Sensors.

Components of DbProtect communicate using Internet Protocol (IP) connections. For help configuring your firewall properly, see the table in “Network Ports Used by DbProtect” on page 50.

2.3 Data Repository DbProtect requires a Microsoft SQL Server 2008 or 2012 Data Repository to operate. This Data Repository stores all Alerts and audit data, as well as its system configuration information.

You can install your Microsoft SQL Server Data Repository locally or remotely (on a physical server separate from where the Console is installed).

DbProtect installs and upgrades the following databases.

• An operational database called AppDetective. This database is installed by the Database Component.

• The DbPAnalytics database. The Analytics setup creates a Microsoft SQL Server database to store the Analytics content (such as reports).

• A staging database called dbpstaging. This database is installed by the Data Warehouse component.

• A data warehouse called dbpdatawarehouse. This database is installed by the Data Warehouse component.

During setup, the installation wizards prompt you to specify the Microsoft SQL Server 2012 or Microsoft SQL Server 2014 instance where you want to install the Data Repository. You may install the operational database and the warehouse databases on separate servers.

2.3.1 Data Repository Options Acceptable data repositories for DbProtect include:

• Microsoft SQL Server 2008/2008 R2

• Microsoft SQL Server 2012, 2014 (backend repository)

You can install a new instance, or choose an existing instance, for your data repository during setup.

2.4 Scan Engine Compatibility The following table defines compatible versions of distributed DbProtect components.

The following table describes the compatibility of various Scan Engines with Supported DbProtect releases. Ensure that your Scan Engine is compatible with the version of DbProtect you are using.

• FC = Fully Compatible–can register and is supported after installation/upgrade

• PC = Partially Compatible–works after upgrade but not registered as new

• NS = Not Supported

Table 3: Version Compatibility

6.4.4/SE 6.4.5/SE 6.4.6/SE 6.4.6/SE 6.4.7SE 6.4.8/SE 6.4.9/SE Proxy 2.8 Proxy 2.9 Proxy 2.10 Proxy 2.12 Proxy 3.0 Proxy 3.0 Proxy 3.2

Scan Engine NS NS NS NS NS NS NS 2.1

Scan Engine NS NS NS NS NS NS NS 2.2

Scan Engine NS NS NS NS NS NS NS 2.4

Scan Engine NS NS NS NS NS NS NS 2.7

Scan Engine FC NS NS NS NS NS NS 2.8

Table 3: Version Compatibility

6.4.4/SE 6.4.5/SE 6.4.6/SE 6.4.6/SE 6.4.7SE 6.4.8/SE 6.4.9/SE Proxy 2.8 Proxy 2.9 Proxy 2.10 Proxy 2.12 Proxy 3.0 Proxy 3.0 Proxy 3.2

Scan Engine FC FC NS NS NS NS NS 2.9

Scan Engine NS FC FC NS NS NS NS 2.10

Scan Engine NS FC (if on FC NS NS NS NS 2.11 SHATTER KB 4.50 or higher)

Scan Engine NS NS NS FC NS NS NS 2.12

Scan Engine NS NS NS NS FC FC FC 3.0

Scan Engine NS NS NS NS FC FC FC 3.2

2.5 Determining the Version of Components To determine the current version of any installed DbProtect software components, log into DbProtect, choose the Administration tab, and click About DbProtect in the navigation menu.

3 Minimum System Requirements

3.1 DbProtect Suite System Requirements This section provides system requirements for the DbProtect Suite.

Table 4: Minimum System Requirements

Requirement Description

Hardware 2GHz processor required (see below) 2-8 cores recommended (DbProtect will take advantage of multiple cores)

Memory 12 GB (Pilot or trial installation) 12-24 GB (Starter program) 24-128 GB (Standard) 12 GB RAM minimum (16 GB+ recommended)

Processor x64 Processor 2.0 GHz+ 2-4 cores (pilot) 4-8 cores (Starter) 8+ cores (Standard)

Disk Space Pilot: 30 GB for application / 75 GB for temp/output Starter: 30 GB for application / 100-250 GB for temp/output Standard: 30 GB for application / 250+ GB for temp/output Note: Our benchmarking has shown that disks (whether physical or virtual) having sequential read and write speeds in excess of 100 MB/s yield acceptable performance. This is true for disks on the application server and for the SQL repository.

Operating Systems Windows Server 2008 Service Pack 2 Windows Server 2008 R2 Service Pack 1 or Windows Server 2012 or Windows Server 2012 R2 64-bit Standard Editions or higher. Note the service pack updates (required by .NET Framework 4.6)

Table 4: Minimum System Requirements

Requirement Description

SQL Server Repository SQL Server 2008 or Supported Versions SQL Server 2008 R2 or SQL Server 2012 or SQL Server 2014 64-bit Standard Editions or higher. Considerations: Pilot: The repository may be installed on the same host as the application server. Memory limits should be set to not exceed 30% of the host. Starter: The repository should be installed on a separate host from the application server, typically in a production SQL farm. Standard: The repository should be installed on a separate host from the application server, typically in a high-performance SQL farm, actively managed by DBA operations teams.

Browser Internet Explorer 9 or higher with JavaScript enabled. The minimum screen resolution is 1024x768.

Back-end Database DbProtect requires a back-end database, which you connect to using either Windows Authentication (using the Local System Windows Service account) or SQL Authentication. DbProtect requires Microsoft SQL Server 2008 or higher Note that Microsoft SQL Server Express editions are not supported.

Required .NET Framework 4.6 is required. Microsoft.NET Version

Scan Engines (for Pilot: One Scan engine, typically on the same host as the application server. Vulnerability Starter: 1-2 Scan engines, deployed on independent hosts. Management and/or Rights Review) Standard: 2+ Scan engines, deployed on independent hosts.

Sensors (for Activity Monitoring is facilitated using sensors that are available for a variety of platforms. Most Monitoring) frequently, these sensors are installed on the databases to be monitored. Occasionally, sensors may be placed on a network that can observe all traffic to/from a select set of databases. The management of all sensors is carried out securely from the DbProtect Management Console.

Account Rights and An Administrative account is required. Privileges

3.2 Scan Engine System Requirements This section provides system requirements for the DbProtect Scan Engine.

Table 5: Scan Engine System Requirements

Requirement Description

Hardware 2GHz processor required Two cores are recommended, as the DbProtect Scan Engine will take advantage of multiple cores

Memory 1GB RAM (4GB recommended)

Operating System Windows 2008 SP2 Windows 2008 R2 SP1 Windows 2012 Note the Service Pack requirements for .NET Framework 4.6

Disk Space The installer unpacks installer files to the default temporary folder location. This is usually on your system drive. Therefore, you must have a minimum of 2GB of disk space on your system drive for new installations and upgrades. DbProtect Scan Engine requires a minimum of 4GB disk space to operate.

Back-end Database DbProtect Scan Engine requires connectivity to the same back-end database as DbProtect Suite.

Required Microsoft.NET Version .NET Framework 4.6 is required. Be aware of the Operating System Service Pack requirements for this package.

Account Rights and Privileges An Administrative account is required for installation.

SAP (Sybase) ASE To run an audit or a rights review on a Sybase Adaptive Service Enterprise Requirements application, your workstation must have the appropriate client drivers installed. For more information, see the DbProtect User Guide. You must have Full Control on the registry key: HKEY_LOCAL_MACHINE\SYBASE\Setup. If you are using ODBC Drivers versions less than 3.7, you must also have read/ write permissions on the following local system files on the client machine: ${SYBASE_ROOT}\ini\sql.ini.

DB2 LUW Requirements To run an Audit on a DB2 LUW database, your server requires the appropriate client drivers installed. For more information, see Appendix Appendix D: on page 55.

3.3 Typical Deployment: Recommended System Requirements This section describes two typical DbProtect deployment scenarios and the system requirements for each scenario.

3.3.1 Typical System Specifications A typical DbProtect Application Server box has 12 GB of RAM. The programs folder on this same box needs 20 to 35 GB for disk space, with temporary file space of 150 to 250 GB. The database server should be managed by the DBA team, typically sized at 12 to 16 GB (or based on your enterprise’s standard production database server build).

It is also useful to have at least three drives on the database host, so that the SQL program files, data files, and log files can all be placed on separate drives. The data and log file system sizes depend on the data retention policies.

3.3.2 Target Platforms The following table lists the target platforms that DbProtect Vulnerability Management ScanEngines can be licensed and configured to scan (refer to the Sensor and Scanner Readme files for the most up to date information).

Table 6: Target Platforms

Vulnerability Management Target Platforms Supported Versions

Oracle Database Servers Oracle versions 12c, 11gR2, 11gR1, 10gR2, 10gR1, 9iR2

Microsoft SQL Server Microsoft SQL Server versions 2016, 2014, 2012, 2008R2, 2008, 2005, 2000

SAP (Sybase) ASE Database Sybase versions 16, 15.7, 15.5, 15, 12.5 Servers

IBM DB2 LUW IBM DB2 versions 10.5, 10.1, 9.7, 9.5, 9.1, 8.2, 8.1

IBM DB2 zSeries IBM DB2 versions 10 (z/OS), 9 (z/OS), 8 (z/OS)

MySQL Servers MySQL versions 5.6, 5.5, 5.1, 5

Teradata Databases Teradata versions 15.10, 15, 14.10, 14

MongoDB MongoDB Enterprise versions 3.0, 3.2, 3.4

Host-Based Sensors can monitor the following platforms:

• Microsoft SQL Server 2016 (x64 editions)

• Microsoft SQL Server 2014 (x64 editions)

• Microsoft SQL Server 2012 (x64 editions)

• Microsoft SQL Server 2008 (all x86 and x64 editions)

• Microsoft SQL Server 2005 (all x86 and x64 editions)

• Microsoft SQL Server 2000 (all x86 and x64 editions)

• Oracle 9iR2, 10gR1, 10gR2, 11gR1, 11gR2, 12cR1

• IBM DB2 LUW version 8.1, 8.2, 9.1, 9.5, 9.7

• SAP (Sybase) ASE 12.5, 15, 15.5, 15.7

Network-Based Sensors (not recommended) can monitor the following platforms:

• Oracle 10gR1, 10gR2, 11gR1, 11gR2, 12c,R1 (excluding “containers”)

• SAP (Sybase) ASE 12.5, 15, 15.5, 15.7

• IBM DB2 LUW version 8.1, 8.2, 9.1, 9.5, 9.7

These architecture recommendations are not exhaustive. Trustwave may recommend alternative specifications and architectures to meet the requirements of your enterprise.

3.3.3 Example Architecture 1 Two dedicated servers are typically required:

• one server for DbProtect Console Server and DbProtect Scan Engine

• one server for MSSQL data repository server

3.3.3.1 Recommended Requirements for the Console Server For the server supporting the DbProtect Console, the following system requirements are recommended.

Table 7: Recommended Requirements for Console Server

Virtual Environment Supported

RAM 12 GB minimum (16 GB recommended for improved performance)

Hard Drive Space 4 GB for program files including analytics module. A minimum of 1GB of temporary disk space on your C:\ drive is required during the installation.

Processor Dual 2GHz or faster processors

Operating Systems Windows Server 2008 SP2 or 2008 R2 SP1 (32-bit or 64-bit excluding Itanium) Microsoft .NET Framework 4.6 Note: DbProtect cannot be installed on a machine that is also a domain controller. Note: The Analytics module cannot be installed on a machine where Cognos BI is already installed.

Browser Internet Explorer 9 or higher recommended or Mozilla Firefox 3.0 and above. Java Runtime Environment (JRE) Version 6 update 11 or greater must be installed.

Rights To install the DbProtect Console, you must have administrative privileges on Windows and administrative (SA) privileges on the Microsoft SQL Server instance being used as the Data Repository. It is suggested to use Windows rights to access the database when installing. DbProtect installs itself as a service and the service account being used to run the service must have the “logon as a service” and “act as part of the operating system” privileges enabled. In addition, your DbProtect server and database server (if remote) must have a trusted relationship with one another or be in the same domain / workgroup.

Table 7: Recommended Requirements for Console Server

Virtual Environment Supported

Networking Network connectivity is required for the DbProtect Console to communicate with DbProtect Database Activity Monitoring Sensors. During installation you must enter a port where the DbProtect Console will “listen” for web browser requests. The default is 20080. The next consecutive port number (i.e., 20081 if you use the default), must be open in order for the DbProtect Console to receive Alerts. Note: If you maintain a firewall with hardened security, the traffic on both ports is SSL. You must allow communication between the DbProtect components.

3.3.4 Recommended Requirements for the MSSQL Server The MSSQL Server must meet the minimum or recommended requirements defined by Microsoft for the installation of their product. For the production DbProtect data repository, 500 GB of hard disk storage is recommended.

However, this requirement varies depending upon the alerts being captured and stored, as well as how long storage must persist for these events.

3.4 Example Architecture 2 One single server co-hosting the following components:

• DbProtect Console Server

• DbProtect Scan Engine

• MSSQL data repository server

3.4.1 Recommended Requirements for the Console Server For the server supporting the DbProtect Console, the following system requirements are recommended.

Table 8: Recommended Requirements for Console Server (Example 2)

Virtual Environment Supported

RAM 12 GB Minimum (16+ GB recommended for improved performance)

Hard Drive Space 4 GB for program files including analytics module. A minimum of 1GB of temporary disk space on your C:\ drive is required during the installation. The MSSQL Server must meet the minimum or recommended requirements defined by Microsoft for the installation of their product. For the production DbProtect data repository, 500 GB of hard disk storage is recommended. However this requirement will vary depending upon the alerts being captured and stored as well as how long storage must persist for these events.

Processor Dual 2 GHz or faster processors

Table 8: Recommended Requirements for Console Server (Example 2)

Virtual Environment Supported

Operating System • Windows Server 2008 SP2, 2008 R2 SP1, or 2012 (32-bit or 64-bit excluding Itanium) • Microsoft .NET Framework 4.6 Note: DbProtect cannot be installed on a machine that is also a domain controller. Note: The Analytics module cannot be installed on a machine where Cognos BI is already installed.

Browser Internet Explorer 9 or higher recommended. Java Runtime Environment (JRE) Version 6 update 11 or greater must be installed.

4 Licensing

License management has been simplified in DbProtect 6.4 and above. All your existing license files are still valid.

The key changes are:

• Licenses are now centrally stored

• Working product after license overage

• Recover licenses when an asset is no longer needed

• Review license usage

4.1 Licenses are now Centrally Stored License files are now centrally stored on the Console (the web application server). Licenses no longer need to be allocated or distributed on any Scan Engines for Vulnerability Management or Rights Management usage.

All licenses are to be stored in the following server directory on the Console server:

\Trustwave\DbProtect\Licenses

Existing license files from version 6.3.1 or above are still valid. You do not need to request any new license files; just place your existing license files into the license directory.

If you have a deployment where you have split your licensing into multiple files on multiple Scan Engine servers, move those license files to the license directory on the Console. If your license files are node locked to a specific server (Machine ID specific), you may contact your Account Representative or our Customer Support team for assistance with consolidating your licenses.

You can optionally install your license files directly from the web interface. To install license files, log in to DbProtect and navigate to: Set Up > System Settings > Licensing and then click on Add License and follow the on-screen instructions.

4.2 Working Product after License Overage DbProtect will continue to function and allow you to login even after you have exceeded your license usage. A license overage notification will be displayed after login if this situation occurs.

4.3 Recover Licenses when Asset is no Longer Needed Licensing for DbProtect is tied to the number of assets and for the usage of Vulnerability Management, Rights Management, and Activity Monitoring. When an Audit or a Pen Test is performed on an asset, a Vulnerability Management license is consumed for the asset that is tested. When a Rights Review is performed on an asset, a Rights Management license is consumed for the asset. When Activity Monitoring is registered and configured on a specific asset, an Activity Monitoring license is consumed for that asset. Once a license is associated, you can perform as many Vulnerability Management or Rights Management

scans or collects as much Activity Monitoring data for that asset; it will not consume another license. This is consistent with previous versions of DbProtect.

However, if the identity of an asset changes, you can edit the asset and change attributes such as the IP Address or the hostname, and the license association will not be disrupted. You can modify the identity of an asset by navigating to Manage > assets, then selecting the asset, and clicking Edit.

If you decommission an asset, you can also have it removed from DbProtect’s asset inventory, and you can recover the license that was consumed for that asset. To remove an asset from DbProtect:

1. Navigate to Manage > Assets.

2. Select the asset.

3. Click Manage Org Associations.

4. Clear the selection of every Organization the asset it is associated with. After user confirmation, the system will automatically determine that the asset is no longer needed, and it will remove it along with its security results data from the system.

4.4 Review License Usage You can review your license usage as follows:

1. Navigate to Set Up > System Settings > Licensing.

2. Click Get License Utilization Report.

4.5 Compliance Packs Note that if you are using Compliance Packs in DbProtect 6.3.1, they are not compatible for use in DbProtect 6.4 versions and above. In the DbProtect 6.4 version line, the main features of the Compliance Packs for DISA STIG and for CIS Security Benchmarks are available to all after upgrading to DbProtect 6.4.3 or higher.

5 Installing the DbProtect Components

Before installing DbProtect, review the “Minimum System Requirements” on page 14.

The DbProtect Suite is comprised of a management bundle, which consists of several third party prerequisites and the following components:

• Java Runtime Environment 1.7 Update

• Setup Support Files: a set of tools that manage the DbProtect Suite installation, including a Suite uninstaller.

• Scan Engine Proxy: a service responsible for load balancing requests between Scan Engine services.

• Enterprise Services Host: a service hosting various Enterprise Services, including the web server that presents the Console user interface.

• Naming & Directory Service: a service that provides location information to various components of the distributed DbProtect system.

• Database Schema: the database schema for the operational database.

• SHATTER Knowledgebase: a knowledge base of vulnerability assessment checks and activity monitoring rules.

• Data Warehouse: a database schema for the reporting database.

• Enterprise Services Host: a set of services that perform various back-end functions, such as asset search or scheduling.

• Management Console: the graphical user interface.

• Message Collector: a service that collects activity monitoring alerts from distributed sensors.

• Data Warehouse Data Service: a service that implements various data warehousing functions.

• IBM Cognos: a reporting server.

• Analytics & Reporting Service: a service that implements various analytics and reporting functions.

• Analytics & Reporting Content: a set of reports available within DbProtect Analytics.

• VA Policy Editor: an editor for vulnerability assessment policies.

• Documentation & Additional Content: this documentation and third party software copyright notices.

In addition, the DbProtect suite employs data collection agents: a Scan Engine (for Vulnerability Assessment and Rights Reviews), and Sensors (for Audit and Threat Management).

5.1 Installing DbProtect Suite The DbProtect Suite is available as a set of two installation bundles, which detect prerequisites and installs the necessary components. Data collection agents are deployed separately.

You must run Part 1 of the installation and ensure that all the included components have completed successfully before running part 2.

1. Locate the DbProtect setup packages on the media provided or download it from the Support portal website into a convenient location (e.g., c:\temp).

2. Launch the setup package Part 1 of 2. DbProtect Setup will detect any missing prerequisites or previously installed components. It will display and disable those components that are up-to-date and highlight those that must be installed or upgraded.

3. The DbProtect suite installer deploys all components into a common area: the Windows Program Files directory (usually C:\Program Files or C:\Program Files (x86)). You can choose this location the first time you install the DbProtect Suite.

4. You must read and accept the license agreement every time you install or upgrade the software.

5. Clicking Install will begin installation of all components in the order they are listed. The installer may require a system restart and will resume after the system has re-started.

6. When the Welcome to the DbProtect Enterprise Services Host Setup Wizard displays, click Next.

5.2 Enterprise Services Host Setup The Enterprise Services Host setup prompts for service Log On Credentials. This step allows you to specify the user DbProtect will use to run the DbProtect Enterprise Services Host service.

1. Choose Run service as LocalSystem or Run service as local or domain user.

2. If you select the latter, you must enter an account and password and click Test Credentials.

If you select the second option, ensure that the user already has the “Logon as a service” privilege. A user can be granted this privilege in the Windows Administrative Tools Local Security Settings application under Local Policies > User Rights Assignment.

The selected user must be allowed to connect to the Active Directory domain (for such operations as checking user credentials during logon to the DbProtect Console) and must have access to the DbProtect back-end databases when using Windows Integrated Authentication.

3. Click Next. When the Ready to install DbProtect Enterprise Services Host page displays, click Install.

4. Click Finish when this install is complete.

5.3 Database Component Setup After the previous install procedure is completed, the DbProtect Schema Component Setup wizard opens. The Schema Component setup creates a Microsoft SQL Server database for DbProtect’s operational data. The database is called AppDetective.

1. Click Next.

You can pre-create your own AppDetective database as long as it adheres to specific requirements. See “Creating Your Own Microsoft SQL Server AppDetective Database” on page 41.

2. The DbProtect Schema Component repository page displays. You are prompted to select a database server and/or instance. You may enter a server name (SERVERNAME, which assumes a default

instance); servername and instance (SERVERNAME\INSTANCE), or servername and port (SERVERNAME:PORT).

3. Click Next. The Database Creation Credentials page displays and prompts for database credentials.

4. Click Windows Authentication to use your current credentials during installation and credentials of the Enterprise Services Host service at runtime. Click SQL Authentication to specify a database login and password. If you are not sure which authentication type to select, see your database administrator.

5. Click Test Connection to enable the Next button.

6. If needed, you can click Modify Database Properties (after clicking Test Connection) to change the default paths.

7. After testing the connection and clicking Next, you see the Database Runtime Credentials page.

8. Click Windows Authentication to use your current credentials during installation and credentials of the Enterprise Services Host service at runtime. Click SQL Authentication to specify a database login and password. If you are not sure which authentication type to select, see your database administrator.

9. Click Test Connection to enable the Next button.

10. Click Next. The Ready to install DbProtect Schema Component page.

11. Click Install.

12. After the install of the Schema Component is complete, click Finish.

DbProtect does not store the credentials provided in this step unless you check the Remember the database credentials for upgrades check box. When specifying SQL Authentication, these credentials will be required during the installation of the SHATTER Knowledgebase and during the application upgrade.

5.4 Installing the SHATTER Knowledgebase After the installation of the Schema Component, you are prompted to install the SHATTER Knowledgebase.

1. Click Next to continue. The Ready to install Trustwave SHATTER Knowledgebase page displays.

2. Click Install.

3. Click Finish after the install is complete. You are then prompted to install the Data Warehouse.

5.5 Data Warehouse Setup The Data Warehouse setup creates two Microsoft SQL Server databases for DbProtect’s reporting data. The databases are called dbpdatawarehouse and dbpstaging.

After the SHATTER KB is installed, you are prompted to install the Data Warehouse.

The Data Warehouse Setup prompts for a database server and/or instance as well as database access credentials, similar to the Data Component Setup.

1. Click Next. The Data Warehouse Repository page displays. You are prompted to select a database server and/or instance. You may enter a server name (SERVERNAME, which assumes a default instance); servername and instance (SERVERNAME\INSTANCE), or servername and port (SERVERNAME:PORT)

2. Select the repository and click Next. The Database Creation Credentials page displays.

3. Click Windows Authentication to use your current credentials during installation and credentials of the Enterprise Services Host service at runtime. Click SQL Authentication to specify a database login and password. If you are not sure which authentication type to select, see your database administrator.

4. After selecting the credentials, click Test Connection and then click Next. The Database Run Time Credentials page displays.

5. Click Test Connection to enable the Next button.

6. Click Next.

7. Click Install when prompted to install the Data Warehouse.

8. Click Finish when prompted that the Data Warehouse Setup Wizard is complete. The DbProtect Message Collector Setup Wizard displays.

9. Click Next. The Service Logon Credentials page displays.

10. On the Service Log On Credentials page, select Run service as LocalSystem or Run service as local or domain user and click Next. If you select Run service as local or domain user, you must enter an account and a password, and then click Test Credentials.

11. Click Next.

12. Click Install to begin the installation of the DbProtect Message Collector.

13. Click Finish to exit the Message Collector Setup Wizard.

14. Additional components install automatically, and then you are notified that you have successfully installed DbProtect 6.4.9, part 1 of 2. Continue to part 2 of 2.

5.6 DbProtect Analytics Setup

1. Launch the setup package Part 2 of 2. Check to accept the license agreement, and then click Install. The IBM Cognos server installs automatically. This installation may take some time.

2. The DbProtect Analytics Setup Wizard displays.

The Analytics setup creates a Microsoft SQL Server database to store Analytics content, such as reports. The database is called dbpanalytics.

The Analytics Setup prompts for a database server and/or instance as well as database access credentials in a similar manner as the Data Component Setup. In addition, it lets you specify the credentials with which to run the IBM Cognos service that is responsible for the execution of the reports and SQL credentials to access the dbpanalytics database.

1. Click Next on the DbProtect Analytics Setup Wizard to display the DbProtect Analytics Content Store page. You are prompted to select a database server and/or instance. You may enter a server name (SERVERNAME, which assumes a default instance); servername and instance (SERVERNAME\INSTANCE), or servername and port (SERVERNAME:PORT)

2. Click Next to create a database to store the DbProtect Analytics content. The Database Creation User Credentials page displays.

4. After selecting the credentials, click Test Connection and then click Next. The Reporting Engine Service Logon Credentials page displays.

5. Select Run service as LocalSystem or Run service as local or domain user.

6. If you select Run service as local or domain user, you must enter an account and password and click Test Credentials.

7. Click Next. The Content Store Runtime User Credentials page displays.

9. If you select SQL Authentication, you must also test the connection.

10. Click Next.

11. The Reporting Engine Temporary Folder page displays.

Trustwave recommends allocating dedicated space in this folder for the Analytics content.

12. Click Browse if you want to choose a different location.

13. After a location is chosen, click Next. The Report Store Folder page displays.

14. Click Browse if you want to choose a different location.

15. After a location is chosen, click Next. The Ready to Install DbProtect Analytics page displays.

16. Click Install.

17. Click Finish when prompted that the DbProtect Analytics Setup Wizard is complete. The Welcome to the DbProtect Analytics Content Setup Wizard displays.

18. Click Next.

19. Click Finish when prompted that the DbProtect Analytics Content Setup Wizard is complete.

20. Click OK when prompted that you have successfully installed DbProtect Suite.

5.7 Installing Scan Engines The DbProtect Scan Engine is comprised of a management bundle, which consists of the following components:

• Scan Engine: a service responsible for Vulnerability Assessment functions.

• Scan Engine Host: a management service responsible for hosting applications, such as the Rights Management service.

• Rights Management Service: a service that performs Rights Management functions.

1. Locate the Scan Engine setup package on the media provided or download it from the Support portal to a convenient location (e.g., c:\temp).

2. Launch the setup package. Scan Engine Setup will detect any missing prerequisites or previously installed components. It will display and disable those components that are up-to-date and highlight those that must be installed or upgraded.

3. You must read and accept the license agreement every time you install or upgrade the software. Click Install to begin the installation of all components in the order they are listed. The installer may require a system restart and will resume after the system is re-started.

5.7.1 DbProtect Scan Engine Setup The Scan Engine setup installs a service that performs Vulnerability Assessment functions.

After clicking Install, the Welcome to Trustwave Scan Engine Host Setup wizard displays.

1. Click Next. The Destination Folder page displays.

2. The installer prompts you for a destination folder. By default, the folder location is C:\Program Files\Trustwave\DatabaseSecurityScanEngineHost.

3. Click Next. The Service Log On Credentials page displays.

4. Select Run service as LocalSystem and click Next. The Port Selection page displays.

5. Enter the port number and click Test Port. Then click Next. The Ready to install Trustwave Scan Engine Host page displays.

6. Click Install.

7. Click Finish when prompted. The installer also prompts you for the location of DbProtect Console, the service information and credentials to access the AppDetective database.

5.8 Installing Sensors Information on installing, starting, stopping, and reconfiguring Sensors is contained in the DbProtect Sensor Installation and Configuration Guide.

5.9 Creating Your Own Microsoft SQL Server AppDetective Database As explained in “Installing DbProtect Suite” on page 24, the DbProtect suite installer automatically installs an AppDetective Microsoft SQL Server database as part of the Database Component installation process.

However, you can create your own AppDetective Microsoft SQL Server database, as long as it adheres to the specific requirements outlined below.

If your AppDetective Microsoft SQL Server database does not adhere to these requirements, the Database Component installation will fail and your entire DbProtect suite installation will also fail.

To create your own AppDetective Microsoft SQL Server database:

1. Create the AppDetective Microsoft SQL Server database with COLLATE Latin1_General_CI_AI.

2. Set the following AppDetective Microsoft SQL Server database options: 'autoclose'='false'

'bulkcopy'='false'

'trunc. log'='false'

'torn page detection'='true'

'read only'='false'

'dbo use'='false'

'single'='false'

'autoshrink'='false'

'ANSI null default'='false'

'recursive triggers'='false'

'ANSI nulls'='false'

'concat null yields null'='false'

'cursor close on commit'='false'

'default to local cursor'='false'

'quoted identifier'='false'

'ANSI warnings'='false'

'auto create statistics'='true'

'auto update statistics'='true'

6 Your Initial DbProtect Login

6.1 Prerequisite You must have the Java Runtime Environment (JRE) SE 6 Update 11 installed to connect to the DbProtect Console using a Web browser.

6.2 Important Considerations for Using DbProtect With Google Desktop Some older versions of Google Desktop (5.1 and earlier) may cause problems when loading the DbProtect Console applet in Internet Explorer. You should turn off Google Desktop, or re-install a newer (5.2 or greater) version.

6.2.1 Important Considerations for Using DbProtect With Internet Explorer Internet Explorer has an advanced “Do not save encrypted pages to disk” option (In Windows 2008 r2, this setting is enabled by default). In Internet Explorer 9, resources received from HTTPS URLs are not placed in the Temporary Internet Files Cache, and temporary files are not created for these resources. This stops any DbProtect files (except web pages) from being downloaded.

You must also disable the XSS filter to ensure that reporting works correctly. In Windows Server 2012 R2STD the “Do not save encrypted pages to disk” setting is disabled by default. Check to ensure it has not been enabled due to a Group Policy.

To disable this option by configuring Internet Explorer:

1. In the Internet Explorer menu bar, go to Tools > Internet Options >Advanced tab.

2. On the Advanced tab, in the Security section, clear the option Do not save encrypted pages to disk.

3. Restart the browser.

6.2.2 Logging in to the Console To log in to the DbProtect Console:

1. From the Start menu, select All Programs > Trustwave > DbProtect > Launch DbProtect.

If you see the “problem with this website’s security certificate” page, click the Continue to this website link.

2. After navigating the certificate messages, the Log In page is displayed.

3. From the Log In drop down list, select Use Windows Authentication or Manually.

4. If you select Use Windows Authentication, DbProtect uses your Windows login credentials to log on to DbProtect.

5. If you select Manually, you are prompted to enter your login credentials: • In the User Name field, enter your DbProtect user name. Use any of the following formats:

• username: local user

• \username

• username@ • In the Password field, enter your DbProtect password.

•Use the Domain drop-down to select your domain, or manually enter a domain in the Domain field.

DbProtect is designed to use only Secure Sockets Layer (SSL) communication, which encrypts your user name and credentials prior to transmission to DbProtect. DbProtect then uses the Windows Authentication subsystem to verify the credentials.

You can check the Remember my settings check box to store your Username, Password and Domain login values. Click Reset to reset the entered Username, Password and Domain login values.

6. Click Log In to display the DbProtect Console. For more information on navigating the DbProtect Console, see Global Navigation in DbProtect in the DbProtect User Guide.

Every DbProtect Console page includes global navigation elements. For more information on navigating the console, see the DbProtect User Guide.

6.3 Logging Into the DbProtect Console Using SSO DbProtect allows you to use Windows authentication to log into the DbProtect Console using a login mechanism known as single sign-on (SSO).

SSO capability only works on Microsoft Windows systems.

If Windows authentication is properly configured, you can log into the DbProtect Console using Internet Explorer 9 or greater without having to enter a username and password. For security purposes, SSO is ideally combined with strong authentication methods like smart cards or one-time password tokens.

There are numerous benefits to implementing SSO. For example, SSO reduces the proliferation of user accounts and passwords and enables a more secure environment. SSO also eliminates the need for DbProtect users to remember an additional password. Other benefits include:

• reducing time spent re-entering passwords for the same identity

• reducing IT costs due to lower number of IT help desk calls about passwords

• security on all levels of entry/exit/access to systems without the inconvenience of re-prompting users

• centralized reporting for compliance adherence.

In order to implement SSO, you (or your administrator) must modify several configuration files. For more information, see the DbProtect Administrator’s Guide.

To log into the DbProtect Console using SSO:

1. Do the following: • Open Internet Explorer 9 or greater with JavaScript enabled, and the screen resolution set to a minimum of 1024x768.

• Enter https://YourMachineName: InstallPort in the Address line, where:

• YourMachineName is the computer name of your DbProtect Console machine • InstallPort is the port number entered during installation. A Security Alert pop-up appears, prompting you to accept a security certificate from Trustwave DbPro- tect uses this certificate to communicate with users over a secure channel.

If an “access denied” pop-up appears, prompting you to enter your credentials, this means you do not have access to the DbProtect system, even though you are a valid Windows user. If this happens, contact your DbProtect administrator to obtain access to the DbProtect system.

2. The DbProtect Console appears. For more information on navigating the console, see the DbProtect User Guide.

7 Uninstalling the DbProtect Components

This section provides uninstallation steps for the DbProtect suite components.

You should uninstall the DbProtect suite components from the Start Menu or from the Control Panel.

7.1 Before You Uninstall the DbProtect Suite Components Before you uninstall the DbProtect Console, do the following:

1. Unregister all sensors from within DbProtect before uninstalling the DbProtect suite components. Unregistering a sensor brings the sensor back to its original install state, allowing you to register the sensor again with the DbProtect Console. For more information, see “Uninstalling and Unregistering a Sensor”.

2. If you are uninstalling the DbProtect Console with the intention of re-installing it later on a different server, you should back-up your SQL Server back-end database before you begin un-installing the DbProtect suite components. Then you can restore the SQL Server back-end database to whichever instance you select after you re-install the DbProtect suite components elsewhere. For more information on backing up your back-end database, see the DbProtect Administrator’s Guide.

7.2 Uninstalling the DbProtect Suite Components from the Start Menu To uninstall the DbProtect suite components from the Start Menu:

1. Choose Start > Trustwave > DbProtect > Uninstall DbProtect to display the uninstallation wizard.

2. Follow the prompts. The order of the uninstallation process is the exact opposite of the DbProtect suite component installation process (for more information, see “Installing the DbProtect Components” on page 23).

The DbProtect Suite component uninstallation process does not delete your back-end database.

3. A message informs you when the uninstallation is complete. Click Finish.

7.3 Uninstalling and Unregistering a Sensor DbProtect Audit and Threat Management allows you to uninstall and/or unregister your sensors. The key differences between uninstallation and unregistration follow:

• Unregistration removes the sensor from the Console, but does not remove the sensor from the host where it is installed.

• Uninstallation removes the sensor from the server where is installed, but does not remove the sensor from the Console where it may have been registered (assuming the sensor was not unregistered before it was uninstalled).

7.3.1 Uninstalling a Sensor (on Windows) Unregister all sensors from within DbProtect before uninstalling the Console or sensors. Unregistering a sensor brings the sensor back to its original install state, allowing you to register the sensor again with DbProtect. For more information, see Uninstalling and Unregistering Sensors in the DbProtect Sensor Installation and Configuration Guide.

7.3.2 Uninstalling and Unregistering a Scan Engine

7.3.2.1 Unregistering a Scan Engine When you unregister a Scan Engine, you return the Scan Engine to its original, unconfigured installation state -- but it is not removed.

Unregister your Scan Engine before you uninstall it.

To unregister a Scan Engine:

1. Log into DbProtect and select Vulnerability Management.

2. Click Scan Engines on the toolbar.

3. Do one of the following to unregister a Scan Engine: • Choose Scan Engines > Unregister from the menu.

• Right-click a Scan Engine in the Scan Engines portion of the Scan Engines page, and choose Unregister.

4. A confirmation message prompts you to confirm the unregistration. Click Yes.

7.3.2.2 Uninstalling a Scan Engine You must be logged in to the Scan Engine host to uninstall a Scan Engine.

You should unregister an Scan Engine before you uninstall it. For more information, see “Uninstalling a Scan Engine” on page 47.

To uninstall a Scan Engine, click Start > All Programs > Trustwave > Trustwave Scan Engine > uninstall and follow the prompts.

8 Installation Troubleshooting

8.1 How do I contact Customer Support? Navigate to https://www.trustwave.com/Company/Support/.

8.2 I uninstalled DbProtect without unregistering my Sensors. How can I re- register my Sensors without reinstalling them? Trustwave provides a sensor reset batch file (force_unregister.bat on Microsoft Windows and force_unregister on Unix) with each sensor installation. The file is located in the util folder of the sensor installation directory (e.g. for Windows c:\\util\force_unregister.bat). When you execute the batch file, it resets the sensor to its original settings. You can then register the sensor again.

8.3 Are there firewall issues I should consider? The DbProtect Console is accessible using HTTPS on port 20080. You can allow all machines, certain machines, or no machines to have access from outside your firewall. In the latter case, only machines inside the firewall can access the DbProtect Console. This is completely at your discretion, but for convenience Trustwave recommends you at least allow users to connect from their desktop machines. DbProtect has its own method of authentication and using a firewall is not required to restrict access.

The Message Collector component of DbProtect “listens” for HTTPS traffic on port 20081, which the sensor uses to send Alerts. Trustwave recommends you disallow all traffic to that port except from the sensors.

Sensors listen on port 20000 for HTTPS traffic from DbProtect (unless you configure them differently during installation), or you can reconfigure sensor to change the port number; for more information, see “Installing Sensors”.

No other machines should be permitted to connect to the sensors.

8.4 Do I require domain administrator rights after I install a Sensor on a cluster? No. For more information on installing sensors on a SQL Server Cluster, see the DbProtect Sensor Installation and Configuration Guide.

8.5 The following message appears: “Error Occurred. The DbProtect database is not available at the moment. Please retry your request later.” What

should I do? Make sure the database instance that DbProtect uses (i.e., MSSQL) is running, and make sure the database credentials you specified during installation are correct. For more information on starting and stopping DbProtect services, see the DbProtect Administrator’s Guide. For more information on DbProtect component installation, see “Installing the DbProtect Components” on page 23.

Email [email protected].

8.6 Why am I displaying a blank page on the DbProtect Console UI? You must enable Javascript on your web browser.

8.7 I am having trouble establishing a connection between the Console and my Sensor on Microsoft Windows 2008. If you are having trouble establishing a connection between the Console and a sensor installed on Microsoft Windows 2008 (i.e., a host-based sensor for Oracle on Windows, a host-based sensor for DB2 on Windows, a host-based sensor for Microsoft SQL Server on Windows, or any network-based sensor), make sure IPV6 support is not enabled on the network adapter, and that your Microsoft Windows Firewall is disabled.

Appendix A: Network Ports Used by DbProtect

Components of DbProtect communicate using Internet Protocol (IP) connections. To help you configure your firewalls properly, the following table lists each component and describes how they each use the network.

Table 9: Network Ports

Application Application Type Port Encrypted Direction Protocol

Sensors

All Sensors SOAP TCP 20000 Over SSL

Host-Based Internal UDP 7777 No Database to Sensor, Oracle with DDL local only Triggers Installed

Scan Engines

All Scan Engines SOAP TCP 20001 Over SSL Console to Scan Engine

SQL 1433 No Scan Engine to Database

Enterprise Services Host

DbProtect Suite HTTP TCP 20080 User to Web Server

SQL 1433 Console to Database

LDAP 20389 All Services to Naming and Directory Service (local only)

Message Collector

All Message HTTP TCP 20081 Over SSL Sensor to Message Collectors Collector

Scan Engine Host and Proxy

Scan Engine SOAP TCP 6125 Yes Proxy to Scan Engine Host Host

Scan Engine SOAP TCP 6123 No Services to Scan Proxy, Proxy local only

Appendix B: Modifying the LogOn As User for DbProtect Ser- vices

B.1 What is the “Log On As” User? When you install DbProtect (see “Installing the DbProtect Components” on page 23), the Database Runtime Configuration page allows you to configure your DbProtect runtime user account. This is the “log on as” user, i.e., the user whose privileges are used to log into and use DbProtect.

You can connect to your custom SQL Server instance using SQL Authentication or Windows Authentication. The latter uses the LocalSystem account as the run-as user for the services installed (i.e., DbProtect and DbProtect Message Collector).

This chapter explains how to modify the Windows Authentication LocalSystem account.

B.2 Modifying the Windows Authentication LocalSystem Account To modify the Windows Authentication LocalSystem account:

1. Choose Start > Control Panel to display the Control Panel.

2. Double-click the Administrative Tools icon.

3. Double-click the Services icon to display the Services dialog box.

4. Highlight a service (e.g., DbProtect Message Collector) to display the DbProtect Message Collector Properties pop-up.

5. Click the Log On tab to display the Log on as: portion of the DbProtect Message Collector Properties pop-up appears.

6. Select This account: and enter the: • new “log on as” user’s domain name\user name (or click Browse to display the Select User pop- up and locate a valid user) \

• password for the specified user.

7. Click Apply.

8. A message informs you the revised “log on as” account change will not take effect until you reboot your computer. Click OK.

Appendix C: DbProtect Log Files

During normal installation of DbProtect suite components, log files are generated and placed in a directory, typically C:\Program Files\Trustwave\DbProtect\Logs. Trustwave Customer Support will ask you to send these files if you contact them for assistance.

Credential information may sometimes be recorded in this manually generated log file. Review the contents of this log to remove any sensitive credential information before sending the log to any Trustwave Customer Support professionals.

C.1 DbProtect Log Files DbProtect log files come in two categories:

• “DbProtect Installation and Upgrade Log Files”

C.1.1 DbProtect Installation and Upgrade Log Files The following DbProtect log files are related to installation and upgrade. Once installation has completed successfully, you can ignore these files (or you can safely remove them).

• Bootstrapper_3.11.1.log

• BackendInstaller_install_silent.log

• DBC_install.log

• LegacyUninstaller_install.log

• LegacyUninstaller_uninstall.log

• DbProtect_install.log

• MessageCollector_install.log

• DBC-uninstall-1.0.log

• DBC-uninstall-1.1.log

• DBC-uninstall-fix-1.1.log

• DBC-uninstall-fix-1.2.log

C.2 Replay Log Files Sensor log files are related to “store-&-forward”, i.e., Trustwave’s method of storing Alerts temporarily in case DbProtect becomes unavailable. These are more commonly known as the replay log files. They come in two forms:

• *.replay.log, which contains Alerts to be forwarded to DbProtect when it becomes available

• *.replay.log.bookmark, which is a bookmark pointing to the replay log indicating where forwarding left off the last time it ran.

If DbProtect becomes unavailable, these files ensure your Alerts will continue to be logged. They store Alerts in binary form which are “replayed” to DbProtect when it is back online.

The growth rate of the Alert log files depends on Alert rate and size. An average replay log grows at rate of approximately 2k/second -- but only when the Sensor cannot communicate with DbProtect.

The number of and size of Alert log files depends on how many Alerts per second are being fired and how long the Message Collector component of DbProtect has been down. Once it is back online, the replay logs will not shrink in size, but rather they will disappear one file at a time.

Replay logs “roll over” at 500MB and continue to do so every 500MB until DbProtect becomes available.

C.2.1 Sensor Installation and Upgrade Log File The Sensor configuration.log file is related to installation and upgrade. Once installation is completed, you can ignore these files (or you can remove them safely).

C.3 Scan Engine Log Files Scan Engine log files are classified in two categories:

• “Scan Engine Installation and Update Log Files”

• “Scan Engine Application Log Files”

C.3.1 Scan Engine Installation and Update Log Files The Scan Engine installation and update log files -- for versions 5.5 and above only -- are located in the <%Temp%> directory, e.g., C:\Documents and Settings\\Local Settings\Temp

You can run the command echo %TEMP% to determine the name and location of your Temp directory.

The names of the installation and update log files are:

• ScanEngineInstall.log

• ScanEngine_{GUID}.log (e.g., ScanEngine_{D164A132-DE80-4EE7-8EB1- BAF1DC605B6A}.log).

C.3.2 Scan Engine Application Log Files Scan Engines of all supported versions include application log files. The locations of the application log files differ, depending on your Scan Engine version.

For more information on supported Scan Engine versions, see “Scan Engine Compatibility” on page 12.

The Scan Engine application log files are in located in the following supported version-specific locations:

• For Scan Engine version 5.5 and above, the Scan Engine application log files are located in the following folder: <%UserProfile%>\<%Local Application Data%>\Trustwave\AppDetective\logs\ You can run the command echo %USERPROFILE% to determine the name and location of your USERPROFILE directory. The <%Local Application Data%> varies on different Windows versions. For example, on Windows 2000/2003: C:\Documents and Settings\\Local Settings\Application Data\Trustwave\AppDetective\logs\. On Windows 2008: C:\Users\\AppData\Local\Trustwave\AppDetective\logs\

If the Scan Engine runs as a LocalSystem account, is Default User on Windows 2003 and Default on Windows 2008. For supported Scan Engines before version 5.5, the Scan Engine application log files are located in one of the following locations (depending on your Scan Engine version): C:\Program Files\Trustwave\ScanEngine\logs or C:\Program Files\Trustwave\adse\logs

The name of the Scan Engine application log file is: adscanengine.exe..log (e.g., adscanengine.exe.1508.log).

Appendix D: Required Client Drivers for Audits (Scan Engine Host Only)

Additional client driver installations must be performed to run Audit policy scans and Rights Review scans. The following table includes details.

Even if you have installed DbProtect on a 64-bit OS, you must install the 32-bit client drivers. If client drivers are installed after the installation of DbProtect, you must restart the Trustwave Scan Engine Service. If this is not done, then testing credentials or running scans will not work.

Table 10: Client Drivers

Platform Client Drivers Required

SAP (Sybase) ASE (Data Server) Versions supported: 16, 15.7, 15.0, 12.5 (32-bit only) You must install the appropriate client drivers (both ODBC and ADO.NET) on your host for Audit and User Rights Review scans to function. You must use the 16.0 client if the target database to be scanned is version 16.0. You should use the latest version and patch (ESD) of the 15.7 client driver or the 12.5 client driver. To obtain access to downloads from SAP/Sybase proceed to the following link (Requires valid support agreement with SAP): http://service.sap.com/support/ Note: Work with your DBA group to obtain the drivers needed.

IBM DB2 LUW (Database) Versions supported: 10.5, 10.1, 9.7, 9.5, 9.1 (32-bit only) You must install the appropriate runtime client drivers on your host for Audit and User Rights Review scans to function. Trustwave recommends that you use that latest version and Fix Pack of the client driver. Latest client drivers may not work with the older versions 8.2 and 8.1. To obtain access to downloads from IBM proceed to the following link (access may require free registration): http://www-01.ibm.com/support/docview.wss?uid=swg27007053 Note: Work with your DBA group to obtain the drivers needed.

Table 10: Client Drivers

Platform Client Drivers Required

IBM DB2 z/OS (Subsystem) Versions supported: 10.5, 9.5, 9.1, 8.2 – DB2 Connect (32-bit only) You must install the appropriate client/connect drivers on your host for Audit scans to function. It is suggested to use the latest version and Fix Pack of the client driver. Latest client drivers may not work with older versions of 8.1 and 7.1 The DB2 Connect driver does require a license provided by IBM. To obtain access to download from IBM proceed to the following link (access may require free registration): http://www-01.ibm.com/support/docview.wss?uid=swg27007053 Note: Work with your DBA group to obtain the drivers needed.

MySQL (Server) Versions supported: 5.2.4, 5.2.5, 5.2.6, 5.2.7 (ODBC) and 6.2.5, 6.5.7 (.NET) (32-bit only) You must install the appropriate client drivers (both ODBC and .NET) on your host for Audit scans to function. To obtain access to downloads from MySQL proceed to the following link (access may require free registration): Follow this link for the ODBC http://dev.mysql.com/downloads/connector/odbc/ 5.2.html Follow this link for the .NET http://dev.mysql.com/downloads/connector/net/ 6.5.html Note: Work with your DBA group to obtain the drivers needed.

Teradata Database Versions supported: 15.10.x (ODBC) (32-bit only), 15.11.x (.NET) (32-bit only) You must install the appropriate runtime client drivers on your host for Audit and User Rights Review scans to function. To obtain access to downloads from Teradata proceed to the following links (access may require free registration): http://downloads.teradata.com/download/connectivity/odbc-driver/windows http://downloads.teradata.com/download/connectivity/net-data-provider-for- teradata Note: Work with your DBA group to obtain the drivers needed.

MongoDB Versions supported: MongoDB Enterprise 3.0, 3.2, 3.4 MongoDB drivers are included with Scan Engine 3.2, which is required for MongoDB support.

Appendix E: Required Audit Privileges

Audit policy scans and User Rights Review scans require read-only access to the asset. While you can use an Administrator account to run the scans, it is not required. To setup the appropriate databases access on the assets, User Creation Scripts are provided within the product, specifically from the SHATTER Knowledgebase component.

To access these files, proceed to the following directory:

C:\Program Files\Trustwave\DbProtect\Resources\ ShatterKnowledgebase\UserCreationScripts

In these directories, you see a readme file that provides more information about each script. The basic guidance for each script follows [where = asset type and version (where needed)]:

• CreateUser.sql: creates a user called ‘aduser’ and will grant read-only permissions needed to run Audit policy scans.

• CreateUserURR.sql: creates a user called ‘aduserURR’ and will grant read-only permissions needed to run Audit policy and User Rights Review scans.

• CreatePowerUser.sql: creates a user called ‘aduser_admin’ and will grant elevated privileges (i.e. SYSDBA for Oracle).

• CreateUserSA.sql: specific for Microsoft SQL Server and creates a user called ‘aduser’ and will grant sysadmin rights.

• UserPermissionsDB2Mainframe.sql: creates a user called ‘aduser’ and will grant read-only permissions needed to run Audit policy scans against IBM DB2 z/OS.

To understand if you should use the PowerUser or SA script, read the CheckPermissions.txt file located in the following directory as there are some checks that do require elevated privileges:

C:\Program Files\Trustwave\DbProtect\Resources\ShatterKnowledgebase

In addition to setting up database access on the asset, OS access maybe also needed if you are running OS integrity checks or checks that do require OS access (i.e. Oracle Critical Patch Update checks). Beyond the information in the readme file (see the readme file for complete instructions on setting up WMI and DCOM permissions), here is more guidance on OS access.

Table 11: Permissions for OS Access

Check Windows Permission Needed

Not Using NTFS Partition Permission to read the installation disk type

Registry Permissions Remote registry access

Services Run as Local System Permission to list the system services

Permissions on Files Permission to read files in the installation directory of the database

Table 12: Permissions for Unix Access

Check Unix Permissions Needed

Permissions on Files Permission to list files in the installation directories of the database

Setgid Bit Enabled See above

Setuid Bit Enabled See above

Certain target databases need to have system variables to specify the location of the database instances.

Table 13: Target Database Permissions for Unix

Target Database Unix Permissions Needed

Oracle Make sure the $ORACLE_HOME variable is correct. Note: The OS account needs to have the same privileges as the Oracle Software Owner.

SAP (Sybase) ASE Make sure the $SYBASE variable is correct.

MySQL Define a datadir or basedir variable to point to the database root.

For Microsoft SQL Server, you can also choose to use Windows Authentication for database credentials. You must enter the domain or hostname, username, and password (for example, if your Windows login is domain/aduser, you enter ‘domain’ in the Domain or IP/Hostname field, and ‘aduser’ in the User Name field).

If any fields are encrypted, the account used for the Audit policy scan does not have access to those fields, some checks may not work properly. Depositor access that only has access to read public documents provides sufficient privileges to run an Audit policy, with the exception of the names.nsf database, which requires Reader access.

Appendix F: Auditing SQL Server (Using Windows Authentica- tion) Against a Machine on a Different or Untrusted Domain

If you attempt to Audit a SQL Server database (using Windows Authentication) against a machine on a different or untrusted domain, the following error message may appear:

SQLSTATE: 28000, Native error: 18452, Message: [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user ''. The user is not associated with a trusted SQL Server connection.

To Audit a SQL Server database (using Windows Authentication) against a machine on a different or untrusted domain:

1. Establish a connection to the target server.

2. Enter the appropriate Net Use syntax. For a remote host that is a: • member of domain, enter: net use \\ip /user:domain\username

• workgroup member (standalone computer), enter: net use \\ip /user:username or net use \\ip /user:computername\username

3. Use named pipes to connect to an untrusted domain.

4. Select the Properties branch option Connect to Microsoft SQL Servers using Named Pipes. You must check this option when Auditing a SQL Server database in an untrusted domain..

You must enable the named pipes protocol on both the Scan Engine host and the SQL Server target server when using this option

5. Confirm the following: • That the Server and Remote Registry services on your remote host are running.

• That the Net Use set of credentials file being used is a member of either the domain hosting the target server, or a domain that is trusted by that domain.

• That login provides remote registry access and read-only file access to the remote machine. To check this:

• enter: net use \\server with your credentials, and expand HKEY_LOCAL_MACHINE on the target server • enter: net use \\server\c$ to verify you can access files on the target server. • That access to the remote host can be restricted by firewall, which is common on Windows 2003. You can verify this on the remote host by looking into the firewall settings/logs for rejects packets. This means there should be connectivity on port 445 or 139 on the target host.

6. Do the following to create and test a DSN connection to the target host:

a. Choose Control Panel > Administrative Tools > Data Sources (ODBC).

b. Open the System DSN tab and click Add.

Auditing SQL Server (Using Windows Authentication) Against a Machine on a Different or Untrusted Domain Copyright © 2017 Trustwave Holdings, Inc. All rights reserved. 59 Trustwave DbProtect 6.4.9 Installation Guide - January 6, 2017

c. Choose Microsoft SQL Server from the list.

d. Click Finish.

e. Enter a Name and Description for this data source entry.

f. In the Server field, enter the IP address and listening port of the target server, e.g., 172.27.190.58,1756.

g. Click Next.

h. Select SQL Server Authentication and enter your database credentials in the Login ID and Password fields.

i. Click Next.

j. Follow the steps in the wizard.

7. You should now be able to test the connection to the data source. If this test is successful, you should also be able to perform the Audit with the Scan Engine. If you are unable to connect, try using the other IP address, or use Windows Authentication rather than the SQL credentials (after connecting with Net Use).

Auditing SQL Server (Using Windows Authentication) Against a Machine on a Different or Untrusted Domain Copyright © 2017 Trustwave Holdings, Inc. All rights reserved. 60 About Trustwave® Trustwave helps businesses fight cybercrime, protect data and reduce security risk. With cloud and managed security services, integrated technologies and a team of security experts, ethical hackers and researchers, Trustwave enables businesses to transform the way they manage their information security and compliance programs. More than three million businesses are enrolled in the Trustwave TrustKeeper® cloud platform, through which Trustwave delivers automated, efficient and cost-effective threat, vulnerability and compliance management. Trustwave is headquartered in Chicago, with customers in 96 countries. For more information about Trustwave, visit https://www.trustwave.com.