DB2_Windows-DbProtect_Installation_Guide by yvtong

VIEWS: 73 PAGES: 377

									DbProtect 6.2
Installation Guide
Last Modified December 5, 2010




Application Security, Inc.
www.AppSecInc.com
info@appsecinc.com
1-866-9APPSEC
                                                                           DbProtect Installation Guide



         Contents
         Introduction 4
         About DbProtect: The Enterprise Solution for Database Security 4
         Intended Audience 5
         DbProtect Components 6
         Networking, Port, and Firewall Considerations 9
         Data Repository 11
         Customer Support 12

         Planning Your DbProtect Installation 13
         DbProtect Installation Checklist 13
         DbProtect Version Compatibility Matrix 14

         Minimum System Requirements 17
         DbProtect Suite System Requirements 17
         Scan Engine System Requirements 18
         Sensor System Requirements 20
         Typical Deploymnet: Recommended System Requirements 70

         Licensing 76

         Installing the DbProtect Components 79
         Installing the DbProtect Suite Components 79
         Installing Scan Engines 87
         Installing, Starting/Stopping, and Reconfiguring the Sensors 89

         Your Initial DbProtect Login 152
         Logging In to the Console 152
         DbProtect Console Login Troubleshooting 156




Application Security, Inc.                                                                           2
                                                                     DbProtect Installation Guide


         Uninstalling the DbProtect Components 161
         Uninstalling the DbProtect Suite Components 161
         Uninstalling and Unregistering a Sensor 162
         Uninstalling and Unregistering a Scan Engine 165

         Installation Troubleshooting 167

         Appendices 176
         Appendix A: Installing/Uninstalling Sensors in a SQL Server Cluster 176
         Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle
         Databases on an Oracle RAC 187
         Appendix C: Modifying the Sensor Listener Port Number 189
         Appendix D: Network Ports Used by DbProtect 190
         Appendix E: Working with Oracle DDL Triggers (for Host-Based Sensors for Oracle In-
         stalled on *nix Platforms Only) 191
         Appendix F: Modifying the "Log On As" User for the DbProtect Sensor and DbProtect
         Message Collector Services 195
         Appendix G: DB2 Administrative Client Driver Installation 196
         Appendix H: DbProtect Log Files 197
         Appendix I: Using App DSN, the Repair ODBC Utility 205
         Appendix J: Configuring Your Oracle Audit Trail in Order to Monitor Logins 207
         Appendix K: Required Client Drivers for Audits 208
         Appendix L: Required Audit Privileges 219
         Appendix M: Auditing SQL Server (Using Windows Authentication) Against a Machine on
         a Different or Untrusted Domain 280
         Appendix N: Troubleshooting the Java Run Time Environment (JRE) Security Settings on
         Internet Explorer 6 and 7 282
         Appendix P: Monitoring Multiple Instances on a DB2 Server 286
         Appendix Q: Monitoring Oracle Databases in an Oracle Fail Safe Environment: Sensor and
         Cluster Configuration Steps 287
         Appendix R: Configuring Your Host-Based Sensor (Installed on a *nix Platform) to Start
         Automatically Upon System Reboot 291
         Appendix S: DbProtect Requirements for Sybase ASE 293




Application Security, Inc.                                                                     3
Chapter 1             Introduction

About DbProtect: The Enterprise Solution for
Database Security
DbProtect is a database security, risk and compliance application designed to meet 
the needs of companies with large heterogeneous database environments. DbPro‐
tects’s IT risk management framework, security controls, continuous controls moni‐
toring, and governance for databases make it the leading solution on the market 
today.

DbProtect is a centrally‐managed enterprise solution that uses a proven methodology 
for information assurance.  It is built on the industry’s leading and most comprehen‐
sive database security knowledgebase—called SHATTER—which accurately identi‐
fies vulnerabilities, risks, and actual threats.

DbProtect accomplishes the following to secure enterprise data:

                                   DISCOVERY – Identifies and locatates all data‐
                                   bases on a given system

                                   CLASSIFICATION – Identifies risks to business 
                                   and development policies

                                   ASSESSMENT – Analyzes database structures 
                                   for security risks, and determines what privi‐
                                   leges have been assigned to users

                                   PRIORITIZATION – Creates a plan to mitigate 
                                   risks

                                   FIX – Executes the plan and fixes the violations
    MONITORING – Applies compensating controls where a fix cannot be applied

    The DbProtect platform protects enterprise organizations around the world from 
    internal and external threats, while also ensuring that those organizations meet or 
    exceed regulatory compliance requirements. At its core, DbProtect is built on 
    tools devleoped from the SHATTER Knowledgebase, including: Asset Manage‐
    ment; Policy Management; Vulnerability Management; Rights Management; Con‐
    figuration & Patch Management; Audit & Threat Management; and Analytics & 
    Reporting.

    Intended Audience
    This guide is intended for persons responsible for day‐to‐day usage of DbProtect. 
    Typically, those responsible for installing DbProtect maintain one of (or a combi‐
    nation of) the following roles:
    System Administrators
    System Administrators maintain and operate a computer system and/or network. 
    Their duties vary from one organization to another. System administrators are 
    usually charged with installing, supporting, and maintaining servers or other 
    computer systems, and planning for and responding to service outages and other 
    problems. Other duties may include scripting or light programming, project man‐
    agement for systems‐related projects, supervising or training computer operators, 
    and handling computer problems beyond the knowledge of technical support 
    staff.
    Network Administrators
    Network Administrators are responsible for the maintenance of the computer 
    hardware and software that comprises a network. This normally includes the 
    deployment, configuration, maintenance and monitoring of active network 
    equipment. Network administration commonly includes activities and tasks such 
    as network address assignment, assignment of routing protocols and routing 
    table configuration, as well as configuration of authentication and authorization‐
    directory services. A network administrator’s duties often also include mainte‐
    nance of network facilities in individual machines, such as drivers and settings of 


5                      Application Security, Inc.
                     Intended Audience




personal computers, as well as printers and so on. Network administrators are also 
responsible for the security of the network and for assigning IP addresses to the 
devices connected to the networks. 
Database Administrators
Database Administrators (DBAs) are responsible for the environmental aspects of a 
database. In general, these include:
   • Recoverability ‐ creating and testing backups
   • Integrity ‐ verifying or helping to verify data integrity
   • Security ‐ defining and/or implementing access controls to the data
   • Availability ‐ ensuring maximum uptime
   • Performance ‐ ensuring maximum performance
   • Development and testing support ‐ helping programmers and engineers to 
   efficiently utilize the database

The role of a DBA has changed according to the technology of database management 
systems (DBMSs), as well as the needs of the database owners.




                     Application Security, Inc.                                       6
    DbProtect Components
    The following diagram illustrates how DbProtect components interact and shows 
    which standard listening ports must be open in order for DbProtect to work.




    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 Console consists of the following components.
       •   Dbprotect Setup: support files that enable DbProtect upgrades and removal.


7                       Application Security, Inc.
                      DbProtect Components




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


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. 

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, 




                      Application Security, Inc.                                        8
    and a monitored event occurs. Two types of Sensors are available: Networking, 
    Port, and Firewall Considerations and Network‐Based Sensors.

    Host-Based Sensors

    The table below lists all supported host‐based database/OS combinations. 

                               DB                        OS

                     SQL SERVER                WINDOWS
                     DB2                       LINUX
                                               SOLARIS
                                               AIX
                                               WINDOWS
                     ORACLE                    LINUX
                                               SOLARIS
                                               AIX
                                               HP‐UX
                                               WINDOWS
                     SYBASE                    SOLARIS
                                               AIX




9                     Application Security, Inc.
                      Networking, Port, and Firewall Considerations




Network-Based Sensors

Network‐based Sensors allow you to monitor Windows‐based Sybase, Oracle, and 
DB2 on the network. The table below lists supported database/OS combinations, and 
links you to the installation steps. 

                               DB                               OS

                   DB2                             WINDOWS
                   SYBASE
                   ORACLE


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

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 connected to the net‐
work continuously.

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.



                      Application Security, Inc.                                    10
        • 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.

     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 don’t require any firewall or 
     network changes. For a detailed list of all ports used refer to the table in Appendix 
     D: Network Ports Used by DbProtect.
     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’s 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, Application Security, Inc. 
        recommends you disallow all traffic to the Message Collector port 20081 
        except from the Sensors.



11                      Application Security, Inc.
                      Data Repository




   • Components of DbProtect communicate using Internet Protocol (IP) 
   connections. To help you configure your firewall properly, the table in Appendix 
   D: Network Ports Used by DbProtect lists each component and describes how 
   they each use the network.

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

DbProtect installs and upgrades the following databases.
   • An operational database called AppDetective. This database is installed by the 
   Database Component.
   • 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 2000, Microsoft SQL Server 2005, or Microsoft SQL Server 2008 instance where 
you want to install the Data Repository. You may install the operational database and 
the warehouse databases on separate servers.




                      Application Security, Inc.                                   12
     Acceptable Data Repository Software

     Acceptable data repositories for DbProtect include:
        •   Microsoft SQL Server 2000 instance (SP4 or higher)
        •   Microsoft SQL Server 2005
        •   Microsoft SQL Server 2008.

     You can install a new instance, or choose an existing instance, for your data repos‐
     itory during setup.
     Local Vs. Remote Installation Considerations

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

     Customer Support
     Customer Support is available from 9 A.M. to 9 P.M. (GMT ‐5) Monday through

     Friday, except for company holidays. You may contact technical support for the 
     list of company holidays.

     Extended support of 24x7 is available as an added cost. You may contact 
     sales@appsecinc.com if you require this service.

     Telephone (in the U.S.): 1‐866‐927‐7732

     Telephone (outside the U.S.): 1‐212‐912‐4100

     Email: support@appsecinc.com




13                       Application Security, Inc.
Chapter 2                Planning Your DbProtect Installation

This chapter explains how to plan your DbProtect installation.

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

                                                      Action

                 1. REVIEW THE MINIMUM SYSTEM 
                  REQUIREMENTS.
                  Before you install any software, carefully read the 
                  minimum system requirements, prerequisites, and 
                  recommendations for:
                  •   Console
                  •   Scan Engines
                  •   Sensors (host-based or network-based).

                  For more information, see DbProtect Suite System 
                  Requirements.
                 2. OBTAIN THE LICENSE FILES.
                  For more information, see DbProtect Licensing 
                  Overview.
                                                        Action

                   3. INSTALL THE DBPROTECT COMPONENTS.
                    Application Security, Inc. provides you with the 
                    installation files for:
                    •   DbProtect management bundle, which includes the Console
                    •   Sensors (host-based or network-based)
                    •   Scan Engines.
                    Note: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 Suite 
                    Components.


     DbProtect Version Compatibility Matrix
     This section includes a DbProtect version compatibility matrix, and instructions 
     which explain how to determine the current version of any installed DbProtect 
     application.

     DbProtect version compatibility matrix

     DbProtect is a distributed system that connects to multiple Scan Engines and Sen‐
     sors. The service version compatibility matrix is below:

                                                          Supported Versions of:
                    Suite Version
                                                  Scan Engine                     Sensor


                         6.2               6.4, 6.5, 6.6, 6.7           3.10, 3.11, 3.12, 
                                                                        3.13
                         6.1               6.2, 6.3, 6.4, 6.5,          3.9, 3.10, 3.11, 3.12
                                           6.6, 6.7
                         6.0               6.0, 6.1, 6.2, 6.3           3.8, 3.9, 3.10, 3.11



14                      Application Security, Inc.
                     DbProtect Version Compatibility Matrix




Determining the current version of any installed DbProtect
software component

To determine the current version of any installed DbProtect software components 
log‐in to DbProtect and choose About DbProtect in the Administration tab. 

You may also find DbProtect components in the system’s Control Panel.
1. Choose Start > Control Panel to display the Control Panel dialog box.
2. Double click the Add or Remove Programs icon to display the Add or Remove 
   Programs dialog box.




                     Application Security, Inc.                                    15
     3. Click any of the following DbProtect applications (assuming they are currently 
        installed on your computer):
         • DbProtect Console Management Server
         • DbProtect Scan Engine
         • DbProtect Sensor




     4. Click the Click here for support information link to display the Support Info 
        pop‐up, which lists the exact version number of the installed DbProtect appli‐
        cation.




16                     Application Security, Inc.
Chapter 3              Minimum System Requirements

This chapter provides minimum system requirements for all DbProtect components.

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

Hardware

2GHz processor required; four to eight cores recommended, as DbProtect will take 
advantage of multiple cores.

Memory

8GB RAM required, 16GB recommended.

Operating System

Windows 2003 or Windows 2008 Server required.

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 insatllations and upgrades.

DbProtect Suite requires a minimum of 20 GB disk space to operate.

DbProtect Analytics requires a significant amount of temporary disk space in order 
to create reports. The amount of disk space required depends on the size of the 
     reports, which, in turn, depends on the estimates amount of data in a report. In 
     general, 100 GB of temporary storage is recommended, but actual size will vary.

     Browser

     Internet Explorer 6 or greater with JavaScript enabled. The minimum screen reso‐
     lution is 1024x768.

     Back-End Database

     DbProtect requires a back‐end database, which you connect to using either Win‐
     dows Authentication (using the Local System Windows Service account) or SQL 
     Authentication.

     Supported back‐end database types include the following:
        •   Microsoft SQL Server 2000 SP4
        •   Microsoft SQL Server 2005
        •   Microsoft SQL Server 2008.

     Microsoft SQL Server Express editions are not supported. 

     Account Rights and Privileges

     An Administrative account is required.

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

     Hardware

     2GHz processor required; two cores recommended, as DbProtect Scan Engine will 
     take advantage of multiple cores.



18                      Application Security, Inc.
                       Scan Engine System Requirements




Memory

1GB RAM required, 4GB recommended.

Operating System

Windows 2003 or Windows 2008 Server required.

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

Account Rights and Privileges

An Administrative account is required for installation.

Lotus/Domino requirements

To run Lotus Domino Audits, you must have the Lotus Notes Client installed on your 
ScanEngine server. DbProtect requires a valid .id file and password to function 
properly. For more information, see Lotus Notes client driver installation.




                       Application Security, Inc.                                     19
     Sybase Requirements

     To run an audit or a rights review on a Sybase SQL Server/Adaptive Server Enter‐
     prise application, your workstation must have the appropriate client drivers 
     installed. For more information, see Sybase Client/Client Driver/.NET Driver 
     Installation.

     You must have Full Control on the registry key: HKEY_LOCAL_MACHINE\SYB-
     ASE\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 requirements

     To run an Audit on a DB2 database, your server requires the appropriate client 
     drivers installed. For more information, see Appendix G: DB2 Administrative Cli‐
     ent Driver Installation.

     Sensor System Requirements
     This section provides system requirements for host‐based and network‐based 
     sensors. 

     Host-Based Sensors - Supported Database Platforms

     Host‐based Sensors allow you to monitor the following databases on a host 
     server:
        • Microsoft SQL Server on Windows
        • Oracle on Solaris, AIX, HP‐UX, Red Hat Enterprise Linux, and Microsoft 
        Windows
        • DB2 on Red Hat Enterprise Linux, Solaris, AIX, and Microsoft Windows
        • Sybase on Solaris, AIX, HP‐UX, and Red Hat Enterprise Linux.




20                     Application Security, Inc.
                         Sensor System Requirements




A host‐based Sensor must reside on the same machine as the Microsoft SQL Server 
instance(s), Oracle SID(s), or DB2 UDB instance it is monitoring.

Although it is theoretically possible to install a host‐based Sensor and the Console on 
the same host, Application Security, Inc. recommends that for host‐based Sensors on 
production databases you install the Console and Data Repository on different hosts. 
For more information, see DbProtect Suite System Requirements.

The supported database platforms list for host‐based Sensors is below. 

                                                                           For more information,
       Supported databases                            Supported OS’
                                                                                   see:

MICROSOFT SQL SERVER                 WINDOWS                               Host‐Based 
Microsoft SQL Server 2000 (all       Windows 2000 Server (including        Sensor for SQL 
x86 and x64 editions)                Advanced Server), 32‐bit and 64‐      Server (on 
Microsoft SQL Server 2005 (all       bit (excluding Itanium); Windows      Windows) ‐ 
x86 and x64 editions)                Server 2003 (including Enterprise     Minimum 
Microsoft SQL Server 2008 (all       Edition), 32‐bit and 64‐bit           System 
x86 and x64 editions)                (excluding Itanium); Windows          Requirements
                                     2008, 32‐bit and 64‐bit (excluding 
                                     Itanium).




                         Application Security, Inc.                                         21
                                                                          For more information,
       Supported databases                      Supported OS’
                                                                                  see:

DB2                                RED HAT ENTERPRISE LINUX               Host‐Based 
DB2 versions 8, 9, and 9.5.        Red Hat Enterprise Linux 3, 4, or 5    Sensor for DB2 
                                   (32‐bit x86 and 64‐bit x64).           (on Red Hat 
                                                                          Enterprise 
                                   The host‐based Sensor installer        Linux) ‐ 
                                   may display a warning message if 
                                                                          Minimum 
                                   you run it on Red Hat Enterprise       System 
                                   Linux 3 to inform you DB2 is not 
                                                                          Requirements
                                   supported on version 3. You may 
                                   safely ignore this warning.
                                   SOLARIS                                Host‐Based 
                                   Solaris 8, 9, and 10 (32‐bit and 64‐   Sensor for DB2 
                                   bit SPARC).                            (on Solaris) ‐ 
                                                                          Minimum 
                                                                          System 
                                                                          Requirements
                                   AIX                                    Host‐Based 
                                   AIX 5.2 Technology Level 5 and         Sensor for DB2 
                                   greater (32‐bit and 64‐bit).           (on AIX) ‐ 
                                                                          Minimum 
                                                                          System 
                                                                          Requirements
                                   WINDOWS                                Host‐Based 
                                   Windows 2000 Server (including         Sensor for DB2 
                                   Advanced Server), 32‐bit and 64‐       (on Windows) ‐ 
                                   bit (excluding Itanium); Windows       Minimum 
                                   Server 2003 (including Enterprise      System 
                                   Edition), 32‐bit and 64‐bit            Requirements
                                   (excluding Itanium); Windows 
                                   2008, 32‐bit and 64‐bit (excluding 
                                   Itanium).


22                     Application Security, Inc.
                         Sensor System Requirements




                                                                            For more information,
       Supported databases                            Supported OS’
                                                                                    see:

SYBASE                               SOLARIS                                Host‐Based 
Sybase 12.5‐15.                      Solaris 8, 9, and 10 (32‐bit and 64‐   Sensor for 
                                     bit SPARC).                            Sybase (on 
                                                                            Solaris) ‐ 
                                                                            Minimum 
                                                                            System 
                                                                            Requirements
                                     AIX                                    Host‐Based 
                                     AIX 5.2 Technology Level 5 and         Sensor for 
                                     greater (32‐bit and 64‐bit).           Sybase (on AIX) 
                                                                            ‐ Minimum 
                                                                            System 
                                                                            Requirements




                         Application Security, Inc.                                          23
                                                                          For more information,
       Supported databases                    Supported OS’
                                                                                  see:

ORACLE                            SOLARIS                                 Host‐Based 
Oracle 9iR2, 10g, 10gR2, and      Solaris 8, 9, and 10 (32‐ and 64‐bit    Sensor for 
11gR1.                            SPARC).                                 Oracle (on 
                                                                          Solaris) ‐ 
                                                                          Minimum 
                                                                          System 
                                                                          Requirements
                                  AIX                                     Host‐Based 
                                  AIX 5.2 Technology Level 5 and          Sensor for 
                                  greater.                                Oracle (on AIX) ‐ 
                                                                          Minimum 
                                                                          System 
                                                                          Requirements
                                  HP‐UX                                   Host‐Based 
                                  HP‐UX 11i v1 or later on the PA‐        Sensor for 
                                  RISC processor and HP‐UX 11i v2         Oracle (on HP‐
                                  or later on the Itanium (IA64)          UX) ‐ Minimum 
                                  processor.                              System 
                                                                          Requirements
                                  RED HAT ENTERPRISE LINUX                Host‐Based 
                                  Red Hat Enterprise Linux 3, 4,          Sensor for 
                                  and 5 (32‐bit x86 and 64‐bit x64).      Oracle (on Red 
                                                                          Hat Enterprise 
                                                                          Linux) ‐ 
                                                                          Minimum 
                                                                          System 
                                                                          Requirements
                                   WINDOWS                                Host‐Based 
                                   Windows 2000 Server (including         Sensor for 
                                   Advanced Server), 32‐bit and 64‐       Oracle (on 
                                   bit (excluding Itanium); Windows       Windows) ‐ 
                                   Server 2003 (including Enterprise      Minimum 
                                   Edition), 32‐bit and 64‐bit            System 
24                     Application Security, Inc.
                                   (excluding Itanium); Windows           Requirements
                                   2008, 32‐bit and 64‐bit (excluding 
                           Sensor System Requirements




Network-Based Sensors - Supported Database Platforms

Network‐based Sensors allow you to monitor Sybase, Oracle, and DB2 on the net‐
work. If you want to install a network‐based Sensor, the table below lists supported 
database/OS combinations, and links you to the minimum system requirements. Net‐
work‐based Sensors only run on the Windows OS, but the databases they monitor do 
not need to be running on Windows.

The supported database platforms list for network‐based sensors is below. 

     Supported databases                   Supported OS’            For more information, see:

SYBASE                            WINDOWS                        Network‐Based Sensor for 
Sybase 11.x‐15.                   Windows 2000 Server            Sybase ‐ Minimum System 
                                  (including Advanced            Requirements
ORACLE                            Server), 32‐bit and 64‐bit     Network‐Based Sensor for 
                                  (excluding Itanium);           Oracle ‐ Minimum System 
Oracle 8, 8i, 9iR1, 9iR2, 
                                  Windows Server 2003            Requirements
10gR2, and 11gR1.
                                  (including Enterprise 
DB2                               Edition), 32‐bit and 64‐bit    Network‐Based Sensor for 
                                  (excluding Itanium);           DB2 ‐ Minimum System 
DB2 UDB versions 8, 9, 
and 9.5; DB2 for zSeries          Windows 2008, 32‐bit and       Requirements
                                  64‐bit (excluding 
v8, v7 (DRDA) (TCP/IP).
                                  Itanium).
                                  Network‐based Sensors 
                                  only run on the Windows 
                                  OS, but the databases they 
                                  monitor do not need to be 
                                  running on Windows.




                           Application Security, Inc.                                            25
     Host-Based Sensor for SQL Server (on Windows) - Minimum
     System Requirements

     This section provides detailed minimum system requirements for the host‐based 
     Sensor for SQL Server (on Windows).
     Supported SQL Server Versions
        •   Microsoft SQL Server 2000 (all x86 and x64 editions)
        •   Microsoft SQL Server 2005 (all x86 and x64 editions)
        •   Microsoft SQL Server 2008 (all x86 and x64 editions).
     Supported Windows Versions
     Windows 2000 Server (including Advanced Server), 32‐bit and 64‐bit (excluding 
     Itanium); Windows Server 2003 (including Enterprise Edition), 32‐bit and 64‐bit 
     (excluding Itanium); Windows 2008, 32‐bit and 64‐bit (excluding Itanium).
     Rights and Privileges
     You need the following rights and privileges to install a host‐based Sensor for 
     Microsoft SQL Server (on Windows):
        • To install a host‐based sensor for Microsoft SQL Server, you must be a 
        Windows user with administrative rights on both the host server and 
        Microsoft SQL Server. You must also have domain administrator rights to 
        install a host‐based sensor for SQL Server in a cluster. To run the host‐based 
        sensor for Microsoft SQL Server, you must have ʺLog on as a serviceʺ rights on 
        Windows, and administrative rights on Microsoft SQL Server at runtime.
        • To run the host‐based sensor for Microsoft SQL Server, you must have ʺrun 
        as a serviceʺ rights on Windows, and administrative rights on Microsoft SQL 
        Server at runtime.
     Microsoft SQL Server 2005/2008 Windows User Requirement
     Microsoft SQL Server 2005/2008 does not create a login for the Windows user 
     “Local System” by default. You must run the host‐based sensor for SQL Server 
     (on Windows) as a Windows user that exists in your SQL Server instance.




26                       Application Security, Inc.
                       Sensor System Requirements




Service Account Requirements
In addition, the service account (i.e., the user running the DbProtect Sensor service) 
requires, at a minimum:
   •   to be in the sysadmin role (Microsoft SQL Server 2000 only)
   •   to have ALTER TRACE permission (Microsoft SQL Server 2005/2008 only)
   •   to have permission to execute the following stored procedures:
        -sp_trace_create
        -sp_trace_setevent
        -sp_trace_setfilter
        -sp_trace_getdata
        -sp_trace_setstatus

You must also have read/write or full permission on the Sensor installation directory 
(which is, by default, <installation folder>:/AppSecInc/Sensor).

You must also have read rights on the following register entries (if they exist):
   • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instance
   Names\SQL
   • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
   Server\SQL_COG_NY_D\Cluster
   • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
   Server\SQL_COG_NY_D\MSSQLServer\CurrentVersion.

To use the Audit Filter Wizard (for more information, see the DbProtect User Guide), 
the service account must also be able to query the sysobjects table within all data‐
bases.
Adding the EXECUTE Privilege for Runtime Users
In addition to db_datareader and db_datawriter role, the Dbprotect runtime user 
must also have EXECUTE permission to all stored procedures in the AppDetective 
database. In SQL Server 2005 and 2008, use following script to add windows user 
ʹjwdbp‐se\dbp_userʹ to ʹdb_execprocʹ role which is granted the EXECUTE privilege 
to all objects:




                       Application Security, Inc.                                    27
     USE AppDetective
     GO
     CREATE ROLE db_execproc
     GO
     GRANT EXECUTE TO db_execproc
     GO
     EXEC sp_addrolemember 'db_execproc', 'jwdbp-se\dbp_user'
     GO


     For SQL Server 2000, use following script to achieve the same
     goal:


     USE AppDetective
     GO


     DECLARE @pname nvarchar(128)
     DECLARE procCursor CURSOR FOR SELECT Name FROM sysobjects
     WHERE OBJECTPROPERTY(id, N'IsProcedure') = 1


     OPEN procCursor
     FETCH NEXT FROM procCursor INTO @pname


     WHILE   @@FETCH_STATUS = 0
     BEGIN
         EXEC ('grant execute on [dbo].[' + @pname + ']   to
     [jwdbp-se\dbp_user]')




28             Application Security, Inc.
                       Sensor System Requirements




       FETCH NEXT FROM procCursor INTO @pname
       END


       CLOSE procCursor
       DEALLOCATE procCursor
       GO
Hardware
   • RAM. 2GB, or at least 512 MB in addition to operating system and database 
   memory requirements. Application Security, Inc. recommends adding more 
   memory if your data volume is high.
   • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is 
   required if you configure the Sensor to log to a local file.
Networking, Port, and Firewall Considerations
Please see Networking, Port, and Firewall Considerations for important information 
on network connectivity, port availability, and firewalls.
Important Server and Instance Information
   • Each machine should have only one Sensor.
   • Every Sensor requires its own dedicated port for communication.
   • One host‐based sensor for Microsoft SQL Server (on Windows) can monitor 
   multiple instances on a single machine.
   • You can monitor as many Microsoft SQL Server instances as your license allows; 
   for more information, see Licensing.
SQL Server Cluster Support
If you want to install a host‐based sensor on a single instance, or multiple instances, 
of a Microsoft SQL Server Cluster, then you must read Appendix A: Installing/Unin‐
stalling Sensors in a SQL Server Cluster. 




                       Application Security, Inc.                                     29
     Host-Based Sensor for DB2 (on Red Hat Enterprise Linux) -
     Minimum System Requirements

     This topic provides detailed minimum system requirements for the host‐based 
     sensor for DB2 (on Red Hat Enterprise Linux).
     Supported DB2 Versions
     DB2 versions 8, 9, and 9.5.
     Supported Red Hat Enterprise Linux Versions
     Red Hat Enterprise Linux 3, 4, or 5 (32‐bit x86 and 64‐bit x64).
     Caution! The host-based sensor installer may display a warning message if you run it on Red
              Hat Enterprise Linux 3 to inform you DB2 is not supported on version 3. You may
              safely ignore this warning.

     Rights and Privileges
     The DB2 administrator must grant the following privileges to the appradar user 
     for every DB2 database in the instance the user wants to monitor. These privileges 
     are:
        • SYSADM if the user wants to monitor failed logins
        • DBADM if the user does not want to monitor failed logins.
     Required Red Hat Enterprise Linux 32- and 64-Bit Minimum Kernel
     Release
     Host‐based sensors for DB2 on Red Hat Enterprise Linux 32‐ and 64‐bit require a 
     minimum Red Hat Enterprise Linux kernel release of version 2.6. Otherwise, 
     install a kernel patch that supports asynchronous I/O.
     MON_HEAP_SZ Database Configuration Parameter
     The host‐based sensor for DB2 (on Red Hat Enterprise Linux) uses DB2 internal 
     feature monitoring. The MON_HEAP_SZ database configuration parameter specifies 
     the number of 4KB blocks of memory available to the monitoring facility. If this 
     parameter is set too low, monitoring won’t turn on and, consequently, the host‐
     based sensor for DB2 won’t be able to monitor your DB2 database.




30                        Application Security, Inc.
                      Sensor System Requirements




Application Security, Inc. recommends a value of 1024 for the MON_HEAP_SZ configura‐
tion parameter, but you should use the formula provided by IBM to determine your 
exact monitoring memory requirements. For more information, see http://pub-
lib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/admin/
c0005995.htm

Hardware
   • RAM. 2GB, or at least 512 MB in addition to operating system and database 
   memory requirements. Application Security, Inc. recommends adding more 
   memory if your data volume is high.
   • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is 
   required if you configure the Sensor to log to a local file.
Networking, Port, and Firewall Considerations
Please see Networking, Port, and Firewall Considerations for important information 
on network connectivity, port availability, and firewalls.
Important Server and Instance Information
   • Each machine should have only one Sensor.
   • Every Sensor requires its own dedicated port for communication.
   • You can monitor as many DB2 instances as your license allows; for more 
   information, see Licensing.
Single Instance Monitoring Limitation
A host‐based sensor for DB2 (installed on a *nix platform) can only monitor one DB2 
instance. The host‐based sensor for DB2 uses an IBM‐provided API that caches the 
value of the DB2INSTANCE environment variable. Consequently, even if the environ‐
ment variable’s value changes, the API will not switch to the other instance. This pre‐
vents the host‐based sensor for DB2 process from monitoring more than one instance 
at a time, and it prevents it from switching from one instance to another (unless you 
re‐start the Sensor).

There is a workaround, however, that allows you to monitor multiple instances on an 
DB2 server. For more information, see Appendix P: Monitoring Multiple Instances on 
a DB2 Server.
User Group Requirement



                      Application Security, Inc.                                    31
     The account running the DB2 instance must be a member of the AppRadar group, 
     and the account running the Sensor must be a member of the DB2 group.
     DB2 Auditing Usage for Failed Logins
     ʺFailed loginʺ support utilizes DB2ʹs ʺauditingʺ feature. This is unique to host‐
     based sensors for DB2, since all other types of host‐based sensor utilize ʺevent 
     monitoring.ʺ

     The host‐based sensors for DB2 automatically turns on DB2 auditing. If you 
     enable any Rule related to failed logins (specifically, ʺFailed Loginʺ, ʺPassword 
     Guessingʺ, or ʺScripted Password Attackʺ). The host‐based sensors for DB2 moni‐
     tor all other types of events using the DB2 ʺevent monitoringʺ facility.

     To enable the host‐based sensor for DB2 to activate native auditing (in order to 
     monitor failed login events) set the following parameters during Sensor installa‐
     tion:
        • Set the environment variable DB2INSTANCE to the name of the DB2 instance 
        that you want the host‐based sensor for DB2 to monitor (e.g., 
        DB2INSTANCE=db2inst1)
        • Add the path to the script db2audit.exe (in the DB2 instance installation 
        directory) to the PATH environment variable (e.g., PATH=$PATH:/home/
        db2inst1/sqllib/adm).

     For more information on how the host‐based sensors for DB2 uses auditing to 
     monitor failed logins and how to manually manage the resulting audit files, see 
     the DbProtect Administrator’s Guide.
     Caution! Host-based sensors for DB2 fully control DB2 "auditing" if user authentication (failed
               login) events are enabled in a Policy (specifically, "Failed Login", "Password
               Guessing", or "Scripted Password Attack"). In other words, the host-based sensor for
               DB2 turns "auditing" on, sets it, and turns it off. If you are using DB2 "auditing" on
               other applications, the host-based sensors for DB2 can potentially override (and
               effectively disable) DB2 "auditing" on these other applications. The host-based
               sensors for DB2 monitor all other types of events using the DB2 "event monitoring"
               facility.




32                        Application Security, Inc.
                        Sensor System Requirements




Host-Based Sensor for DB2 (on Solaris) - Minimum System
Requirements

This topic provides detailed minimum system requirements for the host‐based sen‐
sor for DB2 (on Solaris).
Supported DB2 Versions

DB2 versions 8 and 9.
Supported Solaris Versions

Solaris 8, 9, and 10 (32‐ bit and 64‐bit SPARC).
Rights and Privileges

The DB2 administrator must grant the following privileges to the appradar user for 
every DB2 database in the instance the user wants to monitor. These privileges are:
   • SYSADM if the user wants to monitor failed logins
   • DBADM if the user does not want to monitor failed logins.




                        Application Security, Inc.                               33
     Required Solaris patches

     The following table lists OS patches required for Solaris versions 8 and 9. 

              Solaris version                      Required patch

              Solaris 8         Patch Id: 108434-22
                                Summary: SunOS 5.8: 32‐bit shared library patch 
                                for C++
                                108435‐22 is the corresponding 64‐bit patch.
                                Date: Aug/01/2006
                                Patch Id: 111721-04
                                Summary: SunOS 5.8: Math Library (libm) patch
                                Date: May/08/2003
                                Patch Id: 117350-39
                                Summary: SunOS 5.8: kernel patch
                                Date: Jul/20/2006
              Solaris 9         Patch Id: 111711-15 / 111712-16
                                Summary: SunOS 5.9: 32‐bit shared library patch 
                                for C++
                                11712‐16 is the corresponding 64‐bit patch
                                Date: Aug/07/2006
                                Patch Id: 111722-04
                                Summary: SunOS 5.9: Math Library (libm) patch
                                Date: May/08/2003
                                Patch Id: 118558-25 (or better)
                                Summary: SunOS 5.9: Kernel Patch
                                Date: Apr/25/2006



34                        Application Security, Inc.
                      Sensor System Requirements




Hardware
   • RAM. 2GB, or at least 512 MB in addition to operating system and database 
   memory requirements. Application Security, Inc. recommends adding more 
   memory if your data volume is high.
   • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is 
   required if you configure the Sensor to log to a local file.
Networking, Port, and Firewall Considerations

Please see Networking, Port, and Firewall Considerations for important information 
on network connectivity, port availability, and firewalls.
Important Server and Instance Information
   • Each machine should have only one Sensor.
   • Every Sensor requires its own dedicated port for communication.
   • You can monitor as many DB2 instances as your license allows; for more 
   information, see Licensing.
Single instance monitoring limitation

A host‐based sensor for DB2 (installed on a *nix platform) can only monitor one DB2 
instance. The host‐based sensor for DB2 uses an IBM‐provided API that caches the 
value of the DB2INSTANCE environment variable. Consequently, even if the environ‐
ment variable’s value changes, the API will not switch to the other instance. This pre‐
vents the host‐based sensor for DB2 process from monitoring more than one instance 
at a time, and it prevents it from switching from one instance to another (unless you 
re‐start the Sensor).

There is a workaround, however, that allows you to monitor multiple instances on an 
DB2 server. For more information, see Appendix P: Monitoring Multiple Instances on 
a DB2 Server.
User Group Requirement

The account running the DB2 instance must be a member of the AppRadar group, 
and the account running the Sensor must be a member of the DB2 group.


                      Application Security, Inc.                                    35
     DB2 Auditing Usage for Failed Logins

     ʺFailed loginʺ support utilizes DB2ʹs ʺauditingʺ feature. This is unique to host‐
     based sensors for DB2, since all other types of host‐based sensor utilize ʺevent 
     monitoring.ʺ

     The host‐based sensors for DB2 automatically turns on DB2 auditing. If you 
     enable any Rule related to failed logins (specifically, ʺFailed Loginʺ, ʺPassword 
     Guessingʺ, or ʺScripted Password Attackʺ). The host‐based sensors for DB2 moni‐
     tor all other types of events using the DB2 ʺevent monitoringʺ facility.

     To enable the host‐based sensor for DB2 to activate native auditing (in order to 
     monitor failed login events) set the following parameters during Sensor installa‐
     tion:
        • Set the environment variable DB2INSTANCE to the name of the DB2 instance 
        that you want the host‐based sensor for DB2 to monitor (e.g., 
        DB2INSTANCE=db2inst1)
        • Add the path to the script db2audit.exe (in the DB2 instance installation 
        directory) to the PATH environment variable (e.g., PATH=$PATH:/home/
        db2inst1/sqllib/adm).

     For more information on how the host‐based sensors for DB2 uses auditing to 
     monitor failed logins and how to manually manage the resulting audit files, see 
     the DbProtect Administrator’s Guide.
     Caution! Host-based sensors for DB2 fully control DB2 "auditing" if user authentication (failed
               login) events are enabled in a Policy (specifically, "Failed Login", "Password
               Guessing", or "Scripted Password Attack"). In other words, the host-based sensor for
               DB2 turns "auditing" on, sets it, and turns it off. If you are using DB2 "auditing" on
               other applications, the host-based sensors for DB2 can potentially override (and
               effectively disable) DB2 "auditing" on these other applications. The host-based
               sensors for DB2 monitor all other types of events using the DB2 "event monitoring"
               facility.




36                        Application Security, Inc.
                      Sensor System Requirements




Host-Based Sensor for DB2 (on AIX) - Minimum System
Requirements

This topic provides detailed minimum system requirements for the host‐based sen‐
sor for DB2 (on AIX).
Supported DB2 Versions

DB2 versions 8, 9, and 9.5.
Supported AIX Versions

AIX 5.2 Technology Level 5 and greater (32‐bit and 64‐bit).
Rights and Privileges

The DB2 administrator must grant the following privileges to the appradar user for 
every DB2 database in the instance the user wants to monitor. These privileges are:
   • SYSADM if the user wants to monitor failed logins
   • DBADM if the user does not want to monitor failed logins.

Hardware
   • RAM. 2GB, or at least 512 MB in addition to operating system and database 
   memory requirements. Application Security, Inc. recommends adding more 
   memory if your data volume is high.
   • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is 
   required if you configure the Sensor to log to a local file.
Networking, Port, and Firewall Considerations

Please see Networking, Port, and Firewall Considerations for important information 
on network connectivity, port availability, and firewalls.




                      Application Security, Inc.                                 37
     Important Server and Instance Information
        • Each machine should have only one Sensor.
        • Every Sensor requires its own dedicated port for communication.
        • You can monitor as many DB2 instances as your license allows; for more 
        information, see Licensing.
     Single Instance Monitoring Limitation

     A host‐based sensor for DB2 (installed on a *nix platform) can only monitor one 
     DB2 instance. The host‐based sensor for DB2 uses an IBM‐provided API that 
     caches the value of the DB2INSTANCE environment variable. Consequently, even if 
     the environment variable’s value changes, the API will not switch to the other 
     instance. This prevents the host‐based sensor for DB2 process from monitoring 
     more than one instance at a time, and it prevents it from switching from one 
     instance to another (unless you re‐start the Sensor).

     There is a workaround, however, that allows you to monitor multiple instances on 
     an DB2 server. For more information, see Appendix P: Monitoring Multiple 
     Instances on a DB2 Server.
     User Group Requirement

     The account running the DB2 instance must be a member of the AppRadar group, 
     and the account running the Sensor must be a member of the DB2 group.
     DB2 Auditing Usage for Failed Logins

     ʺFailed loginʺ support utilizes DB2ʹs ʺauditingʺ feature. This is unique to host‐
     based sensors for DB2, since all other types of host‐based sensor utilize ʺevent 
     monitoring.ʺ

     The host‐based sensors for DB2 automatically turns on DB2 auditing. If you 
     enable any Rule related to failed logins (specifically, ʺFailed Loginʺ, ʺPassword 
     Guessingʺ, or ʺScripted Password Attackʺ). The host‐based sensors for DB2 moni‐
     tor all other types of events using the DB2 ʺevent monitoringʺ facility.




38                      Application Security, Inc.
                          Sensor System Requirements




To enable the host‐based sensor for DB2 to activate native auditing (in order to moni‐
tor failed login events) set the following parameters during Sensor installation:
   • Set the environment variable DB2INSTANCE to the name of the DB2 instance that 
   you want the host‐based sensor for DB2 to monitor (e.g., DB2INSTANCE=db2inst1)
   • Add the path to the script db2audit (in the DB2 instance installation directory) 
   to the PATH environment variable (e.g., PATH=$PATH:/home/db2inst1/sqllib/adm).

For more information on how the host‐based sensors for DB2 uses auditing to moni‐
tor failed logins and how to manually manage the resulting audit files, see the DbPro‐
tect Administrator’s Guide.
Caution! Host-based sensors for DB2 fully control DB2 "auditing" if user authentication (failed
          login) events are enabled in a Policy (specifically, "Failed Login", "Password Guessing", or
          "Scripted Password Attack"). In other words, the host-based sensor for DB2 turns
          "auditing" on, sets it, and turns it off. If you are using DB2 "auditing" on other
          applications, the host-based sensors for DB2 can potentially override (and effectively
          disable) DB2 "auditing" on these other applications. The host-based sensors for DB2
          monitor all other types of events using the DB2 "event monitoring" facility.


Host-Based Sensor for DB2 (on Windows) - Minimum System
Requirements

This topic provides detailed minimum system requirements for the host‐based sen‐
sor for DB2 (on Red Hat Enterprise Linux).
Supported DB2 Versions

DB2 versions 8, 9, and 9.5.
Supported Windows Versions

Windows 2000 Server (including Advanced Server), 32‐bit and 64‐bit (excluding Ita‐
nium); Windows Server 2003 (including Enterprise Edition), 32‐bit and 64‐bit 
(excluding Itanium); Windows 2008, 32‐bit and 64‐bit (excluding Itanium).




                          Application Security, Inc.                                               39
     Rights and Privileges

     The DB2 administrator must grant the following privileges to the appradar user 
     for every DB2 database in the instance the user wants to monitor. These privileges 
     are:
        • SYSADM if the user wants to monitor failed logins
        • DBADM if the user does not want to monitor failed logins.

     To install a host‐based sensor for DB2, you must be a Windows user with admin‐
     istrative rights on the host server.
     Hardware
        • RAM. 2GB, or at least 512 MB in addition to operating system and database 
        memory requirements. Application Security, Inc. recommends adding more 
        memory if your data volume is high.
        • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space 
        is required if you configure the Sensor to log to a local file.
     Networking, Port, and Firewall Considerations

     Please see Networking, Port, and Firewall Considerations for important informa‐
     tion on network connectivity, port availability, and firewalls.
     Important Server and Instance Information
        • Each machine should have only one Sensor.
        • Every Sensor requires its own dedicated port for communication.
        • One host‐based sensor for DB2 (on Windows) can monitor multiple 
        instances on a single machine.
        • You can monitor as many DB2 instances as your license allows; for more 
        information, see Licensing.
     Network Connectivity

     Network connectivity is required for communication with the Console and, 
     optionally, with SNMP and Syslog systems.



40                      Application Security, Inc.
                             Sensor System Requirements




User Group Requirement

The account running the DB2 instance must be a member of the AppRadar group, 
and the account running the Sensor must be a member of the DB2 group.

Host-Based Sensor for Sybase (on Solaris) - Minimum System
Requirements

This topic provides detailed minimum system requirements for the host‐based sen‐
sor for Sybase (on Solaris).
Supported Sybase Versions

Sybase 12.5‐15.5.
Supported Solaris Versions

Solaris 8, 9, and 10 (32‐ and 64‐bit SPARC).
Rights and Privileges

To run the host‐based sensor for Sybase v.12.5.4 and above, you must be assigned, at 
a minimum, the sso_ role. You must also be the owner of the sybsecurity database.

To run the host‐based sensor for Sybase v.12.5.2, you must also have “select” permis‐
sion on the syssrvroles table in the “master” database. A command to grant that 
permission is: grant select on syssrvroles to sso_role.
Required Solaris Patches

The following table lists OS patches required for Solaris versions 8 and 9. 

           Solaris version                            Required patch




                             Application Security, Inc.                           41
     Solaris 8       Patch Id: 108434-22
                     Summary: SunOS 5.8: 32‐bit shared library patch 
                     for C++
                     108435‐22 is the corresponding 64‐bit patch.
                     Date: Aug/01/2006
                     Patch Id: 111721-04
                     Summary: SunOS 5.8: Math Library (libm) patch
                     Date: May/08/2003
                     Patch Id: 117350-39
                     Summary: SunOS 5.8: kernel patch
                     Date: Jul/20/2006
     Solaris 9       Patch Id: 111711-15 / 111712-16
                     Summary: SunOS 5.9: 32‐bit shared library patch 
                     for C++
                     11712‐16 is the corresponding 64‐bit patch
                     Date: Aug/07/2006
                     Patch Id: 111722-04
                     Summary: SunOS 5.9: Math Library (libm) patch
                     Date: May/08/2003
                     Patch Id: 118558-25 (or better)
                     Summary: SunOS 5.9: Kernel Patch
                     Date: Apr/25/2006




42               Application Security, Inc.
                       Sensor System Requirements




To determine your Solaris patch level: 
Any user can execute the following command.
1. Execute the following command:
uname -a; showrev -p | egrep -e '^Patch: 117350|^Patch: 111721|^Patch:
108434' | cut -d" " -f1,2

The output displays your OS and patches; for example:
SunOS sunny14 5.8 Generic_117350-38 sun4u sparc SUNW,Ultra-80
Patch: 117350-38
Patch: 111721-04
Patch: 108434-21

Interfaces File Requirement

The interfaces file provides *nix clients and servers with connectivity information 
about a Sybase server. Among other things, this file contains a list of all installed Syb‐
ase servers. By default the interfaces file is located in the directory addressed by the 
SYBASE environment variable. The SYBASE environment variable should point at an 
interfaces file which lists all the Sybase servers you may want to monitor.

Sybsecurity Prerequisite

Sybase monitoring requires the presence of the Sybase Security System (sybsecurity) 
device. The sybsecurity device stores the sybsecurity database. The sybsecurity 
database is created as part of the auditing configuration process. It contains all the 
system tables in the model database as well as a system table for keeping track of 
server‐wide auditing options and system tables for the audit trail. sybsecurity is not 
installed by default when you install Sybase. Instead, you must install sybsecurity 
separately from the main Sybase installation. If sybsecurity is not installed, Applica‐
tion Security, Inc. provides a script called sybsecurity_installer.sh (stored in the 
util directory of your host‐based Sybase installer) which you can run to automati‐
cally install sybsecurity on your Sybase host.




                       Application Security, Inc.                                      43
     Hardware
        • RAM. 2GB, or at least 512 MB in addition to operating system and database 
        memory requirements. Application Security, Inc. recommends adding more 
        memory if your data volume is high.
        • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space 
        is required if you configure the Sensor to log to a local file.
     Networking, Port, and Firewall Considerations

     Please see Networking, Port, and Firewall Considerations for important informa‐
     tion on network connectivity, port availability, and firewalls.
     Important Server and Instance Information
        • Each machine should have only one Sensor.
        • Every Sensor requires its own dedicated port for communication.
        • One host‐based sensor for Sybase (on Solaris) can monitor multiple Sybase 
        databases on a single machine.
        • You can monitor as many Sybase databases as your license allows; for more 
        information, see Licensing.

     Host-Based Sensor for Sybase (on AIX) - Minimum System
     Requirements

     This topic provides detailed minimum system requirements for the host‐based 
     sensor for Sybase (on AIX).
     Supported Sybase Versions

     Sybase 12.5‐15.5.
     Supported AIX Versions

     AIX 5.2 Technology Level 5 and greater.




44                       Application Security, Inc.
                       Sensor System Requirements




Rights and Privileges

To run the host‐based sensor for Sybase v.12.5.4 and above, you must be assigned, at 
a minimum, the sso_ role. You must also be the owner of the sybsecurity database.

To run the host‐based sensor for Sybase v.12.5.2, you must also have “select” permis‐
sion on the syssrvroles table in the “master” database. A command to grant that 
permission is: grant select on syssrvroles to sso_role.
Interfaces File Requirement

The interfaces file provides *nix clients and servers with connectivity information 
about a Sybase server. Among other things, this file contains a list of all installed Syb‐
ase servers. By default the interfaces file is located in the directory addressed by the 
SYBASE environment variable. The SYBASE environment variable should point at an 
interfaces file which lists all the Sybase servers you may want to monitor.

Sybsecurity Prerequisite

Sybase monitoring requires the presence of the Sybase Security System (sybsecurity) 
device. The sybsecurity device stores the sybsecurity database. The sybsecurity 
database is created as part of the auditing configuration process. It contains all the 
system tables in the model database as well as a system table for keeping track of 
server‐wide auditing options and system tables for the audit trail. sybsecurity is not 
installed by default when you install Sybase. Instead, you must install sybsecurity 
separately from the main Sybase installation. If sybsecurity is not installed, Applica‐
tion Security, Inc. provides a script called sybsecurity_installer.sh (stored in the 
util directory of your host‐based Sybase installer) which you can run to automati‐
cally install sybsecurity on your Sybase host.
Hardware
   • RAM. 2GB, or at least 512 MB in addition to operating system and database 
   memory requirements. Application Security, Inc. recommends adding more 
   memory if your data volume is high.
   • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is 
   required if you configure the Sensor to log to a local file.



                       Application Security, Inc.                                      45
     Networking, Port, and Firewall Considerations

     Please see Networking, Port, and Firewall Considerations for important informa‐
     tion on network connectivity, port availability, and firewalls.
     Important Server and Instance Information
        • Each machine should have only one Sensor.
        • Every Sensor requires its own dedicated port for communication.
        • One host‐based Sensor for Sybase (on AIX) can monitor multiple Sybase 
        databases on a single machine.
        • You can monitor as many Sybase databases as your license allows; for more 
        information, see Licensing.

     Host-Based Sensor for Sybase (on HP-UX) - Minimum System
     Requirements

     This topic provides detailed minimum system requirements for the host‐based 
     Sensor for Sybase (on HP‐UX).
     Supported Sybase Versions

     Sybase 12.5‐15.5.
     Supported HP-UX Versions

     HP‐UX 11i v1 or later on the PA‐RISC processor and HP‐UX 11i v2 or later on the 
     Itanium (IA64) processor.
     Rights and Privileges

     To run the host‐based sensor for Sybase v.12.5.4 and above, you must be assigned, 
     at a minimum, the sso_ role. You must also be the owner of the sybsecurity data‐
     base.

     To run the host‐based Sensor for Sybase v.12.5.2, you must also have “select” per‐
     mission on the syssrvroles table in the “master” database. A command to grant 
     that permission is: grant select on syssrvroles to sso_role.


46                       Application Security, Inc.
                       Sensor System Requirements




Interfaces File Requirement

The interfaces file provides *nix clients and servers with connectivity information 
about a Sybase server. Among other things, this file contains a list of all installed Syb‐
ase servers. By default the interfaces file is located in the directory addressed by the 
SYBASE environment variable. The SYBASE environment variable should point at an 
interfaces file which lists all the Sybase servers you may want to monitor.

Sybsecurity Prerequisite

Sybase monitoring requires the presence of the Sybase Security System (sybsecurity) 
device. The sybsecurity device stores the sybsecurity database. The sybsecurity 
database is created as part of the auditing configuration process. It contains all the 
system tables in the model database as well as a system table for keeping track of 
server‐wide auditing options and system tables for the audit trail. sybsecurity is not 
installed by default when you install Sybase. Instead, you must install sybsecurity 
separately from the main Sybase installation. If sybsecurity is not installed, Applica‐
tion Security, Inc. provides a script called sybsecurity_installer.sh (stored in the 
util directory of your host‐based Sybase installer) which you can run to automati‐
cally install sybsecurity on your Sybase host.
Hardware
   • RAM. 2GB, or at least 512 MB in addition to operating system and database 
   memory requirements. Application Security, Inc. recommends adding more 
   memory if your data volume is high.
   • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is 
   required if you configure the Sensor to log to a local file.
Networking, Port, and Firewall Considerations

Please see Networking, Port, and Firewall Considerations for important information 
on network connectivity, port availability, and firewalls.
Important Server and Instance Information
   •   Each machine should have only one sensor.
   •   Every sensor requires its own dedicated port for communication.


                       Application Security, Inc.                                      47
        • One host‐based sensor for Sybase (on HP‐UX) can monitor multiple Sybase 
        databases on a single machine.
        • You can monitor as many Sybase databases as your license allows; for more 
        information, see Licensing.

     Host-Based Sensor for Sybase (on Red Hat Enterprise Linux) -
     Minimum System Requirements

     This topic provides detailed minimum system requirements for the host‐based 
     Sensor for Sybase (on Red Hat Enterprise Linux).
     Supported Sybase Versions

     Sybase 12.5‐15.5.
     Supported Red Hat Enterprise Linux Versions

     Red Hat Enterprise Linux 3,4, and 5 (32‐bit x86 and 64 bit x64).
     Rights and Privileges

     To run the host‐based Sensor for Sybase v.12.5.4 and above, you must be 
     assigned, at a minimum, the sso_ role. You must also be the owner of the sybse-
     curity database.

     To run the host‐based Sensor for Sybase v.12.5.2, you must also have “select” per‐
     mission on the syssrvroles table in the “master” database. A command to grant 
     that permission is: grant select on syssrvroles to sso_role.
     Interfaces File Requirement

     The interfaces file provides *nix clients and servers with connectivity informa‐
     tion about a Sybase server. Among other things, this file contains a list of all 
     installed Sybase servers. By default the interfaces file is located in the directory 
     addressed by the SYBASE environment variable. The SYBASE environment variable 
     should point at an interfaces file which lists all the Sybase servers you may want 
     to monitor.



48                       Application Security, Inc.
                      Sensor System Requirements




Sybsecurity Prerequisite

Sybase monitoring requires the presence of the Sybase Security System (sybsecurity) 
device. The sybsecurity device stores the sybsecurity database. The sybsecurity 
database is created as part of the auditing configuration process. It contains all the 
system tables in the model database as well as a system table for keeping track of 
server‐wide auditing options and system tables for the audit trail. sybsecurity is not 
installed by default when you install Sybase. Instead, you must install sybsecurity 
separately from the main Sybase installation. If sybsecurity is not installed, Applica‐
tion Security, Inc. provides a script called sybsecurity_installer.sh (stored in the 
util directory of your host‐based Sybase installer) which you can run to automati‐
cally install sybsecurity on your Sybase host.
Hardware
   • RAM. 2GB, or at least 512 MB in addition to operating system and database 
   memory requirements. Application Security, Inc. recommends adding more 
   memory if your data volume is high.
   • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is 
   required if you configure the Sensor to log to a local file.
Networking, Port, and Firewall Considerations

Please see Networking, Port, and Firewall Considerations for important information 
on network connectivity, port availability, and firewalls.
Important Server and Instance Information
   • Each machine should have only one Sensor.
   • Every Sensor requires its own dedicated port for communication.
   • One host‐based Sensor for Sybase (on Red Hat Linux) can monitor multiple 
   Sybase databases on a single machine.
   • You can monitor as many Sybase databases as your license allows; for more 
   information, see Licensing.




                      Application Security, Inc.                                    49
     Host-Based Sensor for Oracle (on Solaris) - Minimum System
     Requirements

     This topic provides detailed minimum system requirements for the host‐based 
     Sensor for Oracle (on Solaris).
     Supported Oracle Versions

     Oracle 9iR2, 10gR1, 10gR2, and 11gR1.
     Supported Solaris Versions

     Solaris 8, 9, and 10 (32‐ and 64‐bit SPARC).
     Rights and Privileges

     Host‐based Sensor for Oracle installations on all UNIX platforms (Solaris, AIX, 
     HP‐UX, and Red Hat Enterprise Linux) require the following rights and privi‐
     leges:
        • To install the host‐based Sensor for Oracle package, you must have 
        administrative (root) privileges on the host. If this is not possible, a tar 
        distribution of the host‐based Sensor for Oracle is also available.
        • To run the host‐based Sensor for Oracle, you must use a user that is a 
        member of the same “dba” group as oracle on the host.

     The appradar account must belong to the Oracle DBA group or to the database, 
     and it must allow for login by a system account.




50                      Application Security, Inc.
                             Sensor System Requirements




Required Solaris patches

The following table lists OS patches required for Solaris versions 8 and 9. 

           Solaris version                            Required patch

           Solaris 8           Patch Id: 108434-22
                               Summary: SunOS 5.8: 32‐bit shared library patch 
                               for C++
                               108435‐22 is the corresponding 64‐bit patch.
                               Date: Aug/01/2006
                               Patch Id: 111721-04
                               Summary: SunOS 5.8: Math Library (libm) patch
                               Date: May/08/2003
                               Patch Id: 117350-39
                               Summary: SunOS 5.8: kernel patch
                               Date: Jul/20/2006
           Solaris 9           Patch Id: 111711-15 / 111712-16
                               Summary: SunOS 5.9: 32‐bit shared library patch 
                               for C++
                               11712‐16 is the corresponding 64‐bit patch
                               Date: Aug/07/2006
                               Patch Id: 111722-04
                               Summary: SunOS 5.9: Math Library (libm) patch
                               Date: May/08/2003
                               Patch Id: 118558-25 (or better)
                               Summary: SunOS 5.9: Kernel Patch
                               Date: Apr/25/2006



                             Application Security, Inc.                           51
     To determine your Solaris patch level: 
     Any user can execute the following command.
     1. Execute the following command:
     uname -a; showrev -p | egrep -e '^Patch: 117350|^Patch: 111721|^Patch:
     108434' | cut -d" " -f1,2

     The output displays your OS and patches; for example:
     SunOS sunny14 5.8 Generic_117350-38 sun4u sparc SUNW,Ultra-80
     Patch: 117350-38
     Patch: 111721-04
     Patch: 108434-21

     Hardware
        • RAM. 2GB, or at least 512 MB in addition to operating system and database 
        memory requirements. Application Security, Inc. recommends adding more 
        memory if your data volume is high.
        • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space 
        is required if you configure the Sensor to log to a local file.
     Networking, Port, and Firewall Considerations

     See Networking, Port, and Firewall Considerations for important information on 
     network connectivity, port availability, and firewalls.
     Important Server and Instance Information
        • Each machine should have only one Sensor.
        • Every Sensor requires its own dedicated port for communication.
        • One host‐based Sensor for Oracle (on Solaris) can monitor multiple Oracle 
        SIDs on a single machine.
        • You can monitor as many Oracle SIDs as your license allows.

     Oracle Word Size Prerequisite

     You must install a host‐based Sensor for Oracle corresponding to the word‐size 
     Oracle uses, not the operating system. For example, if Oracle is 32‐bit but the 



52                     Application Security, Inc.
                       Sensor System Requirements




operating system is 64‐bit, your host‐based Sensor for Oracle must be 32‐bit. This is 
only true for host‐based Sensor for Oracle installations, and it’s true for all Unix oper‐
ating systems on which it runs (i.e., AIX, HP‐UX, Red Hat Enterprise Linux, and 
Solaris).
Creating the Appradar Runtime User Account and Working With
Oracle (on Solaris) SGA Shared Memory Permissions

Creating the appradar Runtime User Account:

Application Security, Inc. strongly recommends you create a unique DbProtect user 
called appradar, and use this account for host‐based Sensor for Oracle installation. 
While creating this user is not mandatory, it will ensure that other database adminis‐
trators can’t turn off your host‐based Oracle Sensors.

The appradar user must belong to the primary group of the Oracle user. In many 
cases oracle is the default Oracle user name, while the default group name is typi‐
cally either oracle or dba. The user (i.e., appradar) must be a member of the same dba 
group as oracle on the host.

To determine your Oracle group name, enter the following command: id oracle. 
Your Oracle user name (uid) and group name (gid) should display, e.g., 
uid=1001(oracle) gid=503(dba).

To ensure proper permissioning, verify group ownership of the Oracle process 
memory segments by executing ipcs -m. This command displays current user and 
group memberships of the Oracle segment. Confirm the appradar user has the same 
primary group as the group ownership of the shared memory, and that this user is 
also in the dba group.

To create the runtime user account: 
1. Use an administrative account to create a runtme user account called appradar 
   (suggested name).
2. Set the proper Oracle permissions for this user; see above.

Working with Oracle SGA Shared Memory Permissions:


                       Application Security, Inc.                                      53
     The Oracle System Global Area (SGA) is a group of shared memory areas that 
     are dedicated to an Oracle instance. Oracle processes use SGA to store and com‐
     municate information. Among other things, SGA allows processes (such as the 
     host‐based Sensor for Oracle on any *nix platform) to attach, read, and/or write ‐‐ 
     but not execute. SGA properties are similar to those of a file, i.e., owner, group, 
     and mode. The permission to attach, read, and/or write depends on the SGA 
     mode. The mode for shared memory and a file both depend on the umask setting 
     of the OS session that creates the shared memory or file.

     When you start an Oracle instance, Oracle creates SGA. The SGA mode depends 
     on the umask setting of the OS session which starts the Oracle instance. If the umask 
     setting of the OS session masks the bit ʺread for groupʺ, the SGAʹs modes will not 
     have permission for the group to read. Consequently, your host‐based Sensor for 
     Oracle on any *nix platform ‐‐ which is in the same group as Oracle OS user ‐‐ can 
     not read information from the SGA. As a result, your host‐based Sensor for Oracle 
     on a *nix platform will not fire Alerts.

     Solution: Use the umask command to change the user mask of the session to make 
     sure the group read bit is not masked off. (An example of a correct setting is: 
     umask 026.) You should place this command in the appropriate shell startup file 
     for the Oracle database user ID. After you change the umask value, restart Oracle. 
     After Oracle starts up, use ipcs –m to check the SGA to make sure the modes for 
     the Oracle segments include group read, which grants other users in this group 
     permission to read the segment. This allows the appradar runtime user (who is 
     part of the same group) to read the SGA and monitor activity.
     Sensor re-start requirement (for DDL trigger removals/re-adds)
     - on Solaris

     If you remove and re‐add a DDL trigger for any reason, you must re‐start the Sen‐
     sor afterwards. Most DDL rules will not fire until this is done.




54                      Application Security, Inc.
                      Sensor System Requirements




Configuring a host-based Sensor for Oracle (on Solaris) to monitor
Oracle databases on an Oracle RAC

Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle 
relational database management system (RDBMS) software simultaneously while 
accessing a single database, thus providing a clustered database. For more informa‐
tion on configuring a host‐based Sensor (regardless of the host operating system) to 
monitor databases on an Oracle RAC, see Appendix B: Installing and Configuring a 
Host‐Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC.

Host-Based Sensor for Oracle (on AIX) - Minimum System
Requirements

This topic provides detailed minimum system requirements for the host‐based Sen‐
sor for Oracle (on AIX).
Supported Oracle Versions

Oracle 9iR2, 10gR1, 10gR2, and 11gR1.
Supported AIX Versions

AIX 5.2 Technology Level 5 and greater.




                      Application Security, Inc.                                   55
     Rights and Privileges

     Host‐based Sensor for Oracle installations on all UNIX platforms (Solaris, AIX, 
     HP‐UX, and Red Hat Enterprise Linux) require the following rights and privi‐
     leges:
        • To install the host‐based Sensor for Oracle package, you must have 
        administrative (root) privileges on the host. If this is not possible, a tar 
        distribution of the host‐based Sensor for Oracle is also available.
        • To run the host‐based Sensor for Oracle, you must use a user that is a 
        member of the same “dba” group as oracle on the host.
     Hardware
        • RAM. 2GB, or at least 512 MB in addition to operating system and database 
        memory requirements. Application Security, Inc. recommends adding more 
        memory if your data volume is high.
        • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space 
        is required if you configure the Sensor to log to a local file.
     Networking, Port, and Firewall Considerations

     Please see Networking, Port, and Firewall Considerations for important informa‐
     tion on network connectivity, port availability, and firewalls.
     Important Server and Instance Information
        • Each machine should have only one Sensor.
        • Every Sensor requires its own dedicated port for communication.
        • One host‐based Sensor for Oracle (on AIX) can monitor multiple instances 
        on a single machine.
        • You can monitor as many Oracle SIDs as your license allows; for more 
        information, see Licensing.
     Oracle Word size prerequisite

     You must install a host‐based Sensor for Oracle corresponding to the word‐size 
     Oracle uses, not the operating system. For example, if Oracle is 32‐bit but the 



56                      Application Security, Inc.
                       Sensor System Requirements




operating system is 64‐bit, your host‐based Sensor for Oracle must be 32‐bit. This is 
only true for host‐based Sensor for Oracle installations, and it’s true for all Unix oper‐
ating systems on which it runs (i.e., AIX, HP‐UX, Red Hat Enterprise Linux, and 
Solaris).




                       Application Security, Inc.                                      57
     Creating the appradar Runtime User Account and working with
     Oracle (on AIX) SGA shared memory permissions

     Creating the appradar Runtime User Account:

     Application Security, Inc. strongly recommends you create a unique DbProtect 
     user called appradar, and use this account for host‐based Sensor for Oracle instal‐
     lation. While creating this user is not mandatory, it will ensure that other database 
     administrators can’t turn off your host‐based Oracle Sensors.

     The appradar user must belong to the primary group of the Oracle user. In many 
     cases oracle is the default Oracle user name, while the default group name is typ‐
     ically either oracle or dba. The user (i.e., appradar) must be a member of the same 
     dba group as oracle on the host.

     To determine your Oracle group name, enter the following command: id oracle. 
     Your Oracle user name (uid) and group name (gid) should display, e.g., 
     uid=1001(oracle) gid=503(dba)

     To ensure proper permissioning, verify group ownership of the Oracle process 
     memory segments by executing ipcs -m. This command displays current user and 
     group memberships of the Oracle segment. Confirm the appradar user has the 
     same primary group as the group ownership of the shared memory, and that this 
     user is also in the dba group.

     To create the runtime user account: 
     1. Use an administrative account to create a runtime user account called appradar 
        (suggested name).
     2. Set the proper Oracle permissions for this user; see above.

     Working with Oracle SGA Shared Memory Permissions:

     The Oracle System Global Area (SGA) is a group of shared memory areas that 
     are dedicated to an Oracle instance. Oracle processes use SGA to store and com‐
     municate information. Among other things, SGA allows processes (such as the 
     host‐based Sensor for Oracle on any *nix platform) to attach, read, and/or write ‐‐ 


58                      Application Security, Inc.
                       Sensor System Requirements




but not execute. SGA properties are similar to those of a file, i.e., owner, group, and 
mode. The permission to attach, read, and/or write depends on the SGA mode. The 
mode for shared memory and a file both depend on the umask setting of the OS ses‐
sion that creates the shared memory or file.

When you start an Oracle instance, Oracle creates SGA. The SGA mode depends on 
the umask setting of the OS session which starts the Oracle instance. If the umask set‐
ting of the OS session masks the bit ʺread for groupʺ, the SGAʹs modes will not have 
permission for the group to read. Consequently, your host‐based Sensor for Oracle on 
any *nix platform ‐‐ which is in the same group as Oracle OS user ‐‐ can not read 
information from the SGA. As a result, your host‐based Sensor for Oracle on a *nix 
platform will not fire Alerts.

Solution: Use the umask command to change the user mask of the session to make 
sure the group read bit is not masked off. (An example of a correct setting is: umask
026.) You should place this command in the appropriate shell startup file for the Ora‐
cle database user ID. After you change the umask value, restart Oracle. After Oracle 
starts up, use ipcs –m to check the SGA to make sure the modes for the Oracle seg‐
ments include group read, which grants other users in this group permission to read 
the segment. This allows the appradar runtime user (who is part of the same group) 
to read the SGA and monitor activity.
Sensor re-start requirement (for DDL trigger removals/re-adds) -
on AIX

If you remove and re‐add a DDL trigger for any reason, you must re‐start the Sensor 
afterwards. Most DDL rules will not fire until this is done.
Configuring a host-based Sensor for Oracle (on AIX) to monitor
Oracle databases on an Oracle RAC

Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle 
relational database management system (RDBMS) software simultaneously while 
accessing a single database, thus providing a clustered database. For more informa‐
tion on configuring a host‐based Sensor (regardless of the host operating system) to 




                       Application Security, Inc.                                     59
     monitor databases on an Oracle RAC, see Appendix B: Installing and Configuring 
     a Host‐Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC.

     Host-Based Sensor for Oracle (on HP-UX) - Minimum System
     Requirements

     This topic provides detailed minimum system requirements for the host‐based 
     Sensor for Oracle (on HP‐UX).
     Supported Oracle Versions

     Oracle 9iR2, 10gR1, 10gR2, and 11gR1.
     Supported HP-UX Versions

     HP‐UX 11i v1 or later on the PA‐RISC processor and HP‐UX 11i v2 or later on the 
     Itanium (IA64) processor.
     Rights and Privileges

     Host‐based Sensor for Oracle installations on all UNIX platforms (Solaris, AIX, 
     HP‐UX, and Red Hat Enterprise Linux) require the following rights and privi‐
     leges:
        • To install the host‐based Sensor for Oracle package, you must have 
        administrative (root) privileges on the host. If this is not possible, a tar 
        distribution of the host‐based Sensor for Oracle is also available.
        • To run the host‐based Sensor for Oracle, you must use a user that is a 
        member of the same “dba” group as oracle on the host.
     Hardware
        • RAM. 2GB, or at least 512 MB in addition to operating system and database 
        memory requirements. Application Security, Inc. recommends adding more 
        memory if your data volume is high.
        • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space 
        is required if you configure the Sensor to log to a local file.




60                      Application Security, Inc.
                       Sensor System Requirements




Networking, Port, and Firewall Considerations

Please see Networking, Port, and Firewall Considerations for important information 
on network connectivity, port availability, and firewalls.
Important Server and Instance Information
   • Each machine should have only one Sensor.
   • Every Sensor requires its own dedicated port for communication.
   • One host‐based Sensor for Oracle (on HP‐UX) can monitor multiple instances 
   on a single machine.
   • You can monitor as many Oracle SIDs as your license allows; for more 
   information, see Licensing.
Oracle Word size prerequisite

You must install a host‐based Sensor for Oracle corresponding to the word‐size Ora‐
cle uses, not the operating system. For example, if Oracle is 32‐bit but the operating 
system is 64‐bit, your host‐based Sensor for Oracle must be 32‐bit. This is only true 
for host‐based Sensor for Oracle installations, and it’s true for all Unix operating sys‐
tems on which it runs (i.e., AIX, HP‐UX, Red Hat Enterprise Linux, and Solaris).
Creating the appradar Runtime User Account and working with
Oracle (on HP-UX) SGA shared memory permissions

Creating the appradar Runtime User Account:

Application Security, Inc. strongly recommends you create a unique DbProtect user 
called appradar, and use this account for host‐based Sensor for Oracle installation. 
While creating this user is not mandatory, it will ensure that other database adminis‐
trators can’t turn off your host‐based Oracle Sensors.

The appradar user must belong to the primary group of the Oracle user. In many 
cases oracle is the default Oracle user name, while the default group name is typi‐
cally either oracle or dba. The user (i.e., appradar) must be a member of the same dba 
group as oracle on the host.




                       Application Security, Inc.                                     61
     To determine your Oracle group name, enter the following command: id oracle. 
     Your Oracle user name (uid) and group name (gid) should display, e.g., 
     uid=1001(oracle) gid=503(dba)

     To ensure proper permissioning, verify group ownership of the Oracle process 
     memory segments by executing ipcs -m. This command displays current user and 
     group memberships of the Oracle segment. Confirm the appradar user has the 
     same primary group as the group ownership of the shared memory, and that this 
     user is also in the dba group.

     To create the runtime user account: 
     1. Use an administrative account to create a runtime user account called appradar 
        (suggested name).
     2. Set the proper Oracle permissions for this user; see above.

     Working with Oracle SGA Shared Memory Permissions:

     The Oracle System Global Area (SGA) is a group of shared memory areas that 
     are dedicated to an Oracle instance. Oracle processes use SGA to store and com‐
     municate information. Among other things, SGA allows processes (such as the 
     host‐based Sensor for Oracle on any *nix platform) to attach, read, and/or write ‐‐ 
     but not execute. SGA properties are similar to those of a file, i.e., owner, group, 
     and mode. The permission to attach, read, and/or write depends on the SGA 
     mode. The mode for shared memory and a file both depend on the umask setting 
     of the OS session that creates the shared memory or file.

     When you start an Oracle instance, Oracle creates SGA. The SGA mode depends 
     on the umask setting of the OS session which starts the Oracle instance. If the umask 
     setting of the OS session masks the bit ʺread for groupʺ, the SGAʹs modes will not 
     have permission for the group to read. Consequently, your host‐based Sensor for 
     Oracle on any *nix platform ‐‐ which is in the same group as Oracle OS user ‐‐ can 
     not read information from the SGA. As a result, your host‐based Sensor for Oracle 
     on a *nix platform will not fire Alerts.




62                      Application Security, Inc.
                      Sensor System Requirements




Solution: Use the umask command to change the user mask of the session to make 
sure the group read bit is not masked off. (An example of a correct setting is: umask
026.) You should place this command in the appropriate shell startup file for the Ora‐
cle database user ID. After you change the umask value, restart Oracle. After Oracle 
starts up, use ipcs –m to check the SGA to make sure the modes for the Oracle seg‐
ments include group read, which grants other users in this group permission to read 
the segment. This allows the appradar runtime user (who is part of the same group) 
to read the SGA and monitor activity.
Sensor re-start requirement (for DDL trigger removals/re-adds) -
on HP-UX

If you remove and re‐add a DDL trigger for any reason, you must re‐start the Sensor 
afterwards. Most DDL rules will not fire until this is done.
Configuring a host-based Sensor for Oracle (on HP-UX) to monitor
Oracle databases on an Oracle RAC

Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle 
relational database management system (RDBMS) software simultaneously while 
accessing a single database, thus providing a clustered database. For more informa‐
tion on configuring a host‐based Sensor (regardless of the host operating system) to 
monitor databases on an Oracle RAC, see Appendix B: Installing and Configuring a 
Host‐Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC.

Host-Based Sensor for Oracle (on Red Hat Enterprise Linux) -
Minimum System Requirements

This topic provides detailed minimum system requirements for the host‐based Sen‐
sor for Oracle (on Red Hat Enterprise Linux).
Supported Oracle Versions

Oracle 9iR2, 10gR1, 10gR2, and 11gR1.




                      Application Security, Inc.                                   63
     Supported Red Hat Enterprise Linux Versions

     Red Hat Enterprise Linux 3, 4, and 5 (32‐bit x86 and 64‐bit x64).
     Rights and Privileges

     Host‐based Sensor for Oracle installations on all UNIX platforms (Solaris, AIX, 
     HP‐UX, and Red Hat Enterprise Linux) require the following rights and privi‐
     leges:
        • To install the host‐based Sensor for Oracle package, you must have 
        administrative (root) privileges on the host. If this is not possible, a tar 
        distribution of the host‐based Sensor for Oracle is also available.
        • To run the host‐based Sensor for Oracle, you must use a user that is a 
        member of the same “dba” group as oracle on the host.
     Hardware
        • RAM. 2GB, or at least 512 MB in addition to operating system and database 
        memory requirements. Application Security, Inc. recommends adding more 
        memory if your data volume is high.
        • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space 
        is required if you configure the Sensor to log to a local file.
     Networking, Port, and Firewall Considerations

     Please see Networking, Port, and Firewall Considerations for important informa‐
     tion on network connectivity, port availability, and firewalls.
     Important Server and Instance Information
        • Each machine should have only one Sensor.
        • Every Sensor requires its own dedicated port for communication.
        • One host‐based Sensor can monitor multiple instances on a single machine.
        • You can monitor as many Oracle SIDs as your license allows; for more 
        information, see Licensing.




64                      Application Security, Inc.
                       Sensor System Requirements




Oracle Word size prerequisite

You must install a host‐based Sensor for Oracle corresponding to the word‐size Ora‐
cle uses, not the operating system. For example, if Oracle is 32‐bit but the operating 
system is 64‐bit, your host‐based Sensor for Oracle must be 32‐bit. This is only true 
for host‐based Sensor for Oracle installations, and it’s true for all Unix operating sys‐
tems on which it runs (i.e., AIX, HP‐UX, Red Hat Enterprise Linux, and Solaris).
Creating the appradar Runtime User Account and working with
Oracle (on Red Hat Enterprise Linux) SGA shared memory
permissions

Creating the appradar Runtime User Account:

Application Security, Inc. strongly recommends you create a unique DbProtect user 
called appradar, and use this account for host‐based Sensor for Oracle installation. 
While creating this user is not mandatory, it will ensure that other database adminis‐
trators can’t turn off your host‐based Oracle Sensors.

The appradar user must belong to the primary group of the Oracle user. In many 
cases oracle is the default Oracle user name, while the default group name is typi‐
cally either oracle or dba. The user (i.e., appradar) must be a member of the same dba 
group as oracle on the host.

To determine your Oracle group name, enter the following command: id oracle. 
Your Oracle user name (uid) and group name (gid) should display, e.g., 
uid=1001(oracle) gid=503(dba)

To ensure proper permissioning, verify group ownership of the Oracle process 
memory segments by executing ipcs -m. This command displays current user and 
group memberships of the Oracle segment. Confirm the appradar user has the same 
primary group as the group ownership of the shared memory, and that this user is 
also in the dba group.

To create the runtime user account: 




                       Application Security, Inc.                                     65
     1. Use an administrative account to create a runtime user account called appradar 
        (suggested name).
     2. Set the proper Oracle permissions for this user; see above.

     Working with Oracle SGA Shared Memory Permissions:

     The Oracle System Global Area (SGA) is a group of shared memory areas that 
     are dedicated to an Oracle instance. Oracle processes use SGA to store and com‐
     municate information. Among other things, SGA allows processes (such as the 
     host‐based Sensor for Oracle on any *nix platform) to attach, read, and/or write ‐‐ 
     but not execute. SGA properties are similar to those of a file, i.e., owner, group, 
     and mode. The permission to attach, read, and/or write depends on the SGA 
     mode. The mode for shared memory and a file both depend on the umask setting 
     of the OS session that creates the shared memory or file.

     When you start an Oracle instance, Oracle creates SGA. The SGA mode depends 
     on the umask setting of the OS session which starts the Oracle instance. If the umask 
     setting of the OS session masks the bit ʺread for groupʺ, the SGAʹs modes will not 
     have permission for the group to read. Consequently, your host‐based Sensor for 
     Oracle on any *nix platform ‐‐ which is in the same group as Oracle OS user ‐‐ can 
     not read information from the SGA. As a result, your host‐based Sensor for Oracle 
     on a *nix platform will not fire Alerts.

     Solution: Use the umask command to change the user mask of the session to make 
     sure the group read bit is not masked off. (An example of a correct setting is: 
     umask 026.) You should place this command in the appropriate shell startup file 
     for the Oracle database user ID. After you change the umask value, restart Oracle. 
     After Oracle starts up, use ipcs –m to check the SGA to make sure the modes for 
     the Oracle segments include group read, which grants other users in this group 
     permission to read the segment. This allows the appradar runtime user (who is 
     part of the same group) to read the SGA and monitor activity.




66                      Application Security, Inc.
                      Sensor System Requirements




Sensor re-start requirement (for DDL trigger removals/re-adds) -
on Red Hat Enterprise Linux

If you remove and re‐add a DDL trigger for any reason, you must re‐start the Sensor 
afterwards. Most DDL rules will not fire until this is done.
Configuring a host-based Sensor for Oracle (on Red Hat Enterprise
Linux) to monitor Oracle databases on an Oracle RAC

Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle 
relational database management system (RDBMS) software simultaneously while 
accessing a single database, thus providing a clustered database. For more informa‐
tion on configuring a host‐based Sensor (regardless of the host operating system) to 
monitor databases on an Oracle RAC, see Appendix B: Installing and Configuring a 
Host‐Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC.

Host-Based Sensor for Oracle (on Windows) - Minimum System
Requirements

This topic provides detailed minimum system requirements for the host‐based Sen‐
sor for Oracle (on Windows).
Supported Oracle Versions

Oracle 9iR2, 10gR1, 10gR2, and 11gR1.
Supported Windows Versions

Windows 2000 Server (including Advanced Server), 32‐bit and 64‐bit (excluding Ita‐
nium); Windows Server 2003 (including Enterprise Edition), 32‐bit and 64‐bit 
(excluding Itanium); Windows 2008, 32‐bit and 64‐bit (excluding Itanium).




                      Application Security, Inc.                                   67
     Rights and Privileges

     To install a host‐based Sensor for Oracle, you must be a Windows user with 
     administrative rights on the host server.

 Note:      The host‐based Sensor for Oracle may be run as either a LocalSystem or a 
            Domain Account.  However, if you are running it as a Domain Account, the 
            user must belong in the ora_dba group.

     Hardware
        • RAM. 2GB, or at least 512 MB in addition to operating system and database 
        memory requirements. Application Security, Inc. recommends adding more 
        memory if your data volume is high.
        • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space 
        is required if you configure the Sensor to log to a local file.
     Networking, Port, and Firewall Considerations

     Please see Networking, Port, and Firewall Considerations for important informa‐
     tion on network connectivity, port availability, and firewalls.
     Important Server and Instance Information
        • Each machine should have only one Sensor.
        • Every Sensor requires its own dedicated port for communication.
        • One host‐based Sensor for Oracle (on Windows) can monitor multiple 
        instances on a single machine.
        • You can monitor as many Oracle SIDs as your license allows; for more 
        information, see Licensing.
     Oracle-Reserved Character Installation Restriction

     Make sure you install your host‐based Sensor for Oracle (on Windows) in a path 
     that does not include Oracle‐reserved characters such as parentheses. This is an 
     Oracle restriction. For example: C:\Program Files (x86). In a case such as this, 




68                     Application Security, Inc.
                     Sensor System Requirements




you must install the host‐based Sensor for Oracle (on Windows) in another location.




                     Application Security, Inc.                                  69
     Configuring a Host-Based Sensor for Oracle (on Windows) to
     Monitor Oracle Databases on an Oracle RAC

     Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle 
     relational database management system (RDBMS) software simultaneously while 
     accessing a single database, thus providing a clustered database. For more infor‐
     mation on configuring a host‐based Sensor (regardless of the host operating sys‐
     tem) to monitor databases on an Oracle RAC, see Appendix B: Installing and 
     Configuring a Host‐Based Sensor for Oracle to Monitor Oracle Databases on an 
     Oracle RAC.
     Configuring a Host-Based Sensor for Oracle (on Windows) to
     Monitor Oracle Databases in an Oracle Fail-Safe Environment

     Windows‐only Oracle Fail Safe is another type of Oracle cluster. It is a core feature 
     included with every Oracle 11gR1, Oracle 10g and Oracle9i license for Microsoft 
     Windows 2000 and Microsoft Windows 2003. Oracle Fail Safe is integrated with 
     Microsoft Cluster Server to allow you to configure and verify Microsoft Windows 
     clusters and to automatically fail over Oracle databases and applications. For 
     more information on configuring a host‐based Sensor for Oracle on Windows to 
     monitor Oracle databases in an Oracle Fail Safe environment, see Appendix Q: 
     Monitoring Oracle Databases in an Oracle Fail Safe Environment: Sensor and 
     Cluster Configuration Steps.

     Network-Based Sensor for Sybase - Minimum System
     Requirements

     This topic provides detailed minimum system requirements for the network‐
     based Sensor for Sybase.
     Supported Sybase Versions

     Sybase 11.x‐15.5.




70                       Application Security, Inc.
                      Sensor System Requirements




Supported Windows Versions

Windows 2000 Server (including Advanced Server), 32‐bit and 64‐bit (excluding Ita‐
nium); Windows Server 2003 (including Enterprise Edition), 32‐bit and 64‐bit 
(excluding Itanium); Windows 2008, 32‐bit and 64‐bit (excluding Itanium).
Network‐based Sensors only run on the Windows OS, but the databases they monitor 
do not need to be running on Windows.
Rights and Privileges
   • To install the network‐based Sensor, you must have administrative privileges 
   on Windows.
   • To run the network‐based Sensor, you must have administrative and “run as a 
   serviceʺ privileges on Windows.
   • To create a custom Filter for Sybase, you require read access to the following 
   tables: master..sysdatabases and the sysobjects, sysusers, and syscolumns 
   tables in the target databases being audited.
   For more information on Filters, see the DbProtect Administrator’s Guide and the 
   DbProtect User Guide.
Hardware
   • Dedicated hardware recommendation. Application Security, Inc. recommends 
   you install the network‐based Sensor on dedicated hardware, because it improves 
   performance and it’s easier to support. However, you can install the network‐
   based Sensor and the Console on the same machine.
Generally, to facilitate the networking requirements listed below, your network 
administrator will install the network‐based Sensor on a machine in the same data 
center as the database(s) it will be monitoring.
   • RAM. At least 512 MB. Application Security, Inc. recommends adding more 
   memory if your data volume is high.
   • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is 
   required if you configure the to log to a local file.




                      Application Security, Inc.                                   71
     Networking, Port, and Firewall Considerations

     Please see Networking, Port, and Firewall Considerations for important informa‐
     tion on network connectivity, port availability, and firewalls. The following con‐
     sideration 

     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 required, 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). Older drivers may 
         not work. Other environments currently not supported: ATM, Token Ring, 
         FDDI.
     Application Security, Inc. recommends you use two network interface cards: one 
     for “listening” to database traffic, and one to communicate with the Console, if 
     data volume is high.

     Network-Based Sensor for Oracle - Minimum System
     Requirements

     This topic provides detailed minimum system requirements for the network‐
     based Sensor for Oracle.
     Supported Oracle Versions

     Oracle 8, 8i, 9iR2, 10gR1, 10gR2, and 11gR1.




72                     Application Security, Inc.
                      Sensor System Requirements




Supported Windows Versions

Windows 2000 Server (including Advanced Server), 32‐bit and 64‐bit (excluding Ita‐
nium); Windows Server 2003 (including Enterprise Edition), 32‐bit and 64‐bit 
(excluding Itanium); Windows 2008, 32‐bit and 64‐bit (excluding Itanium).
Network‐based Sensors only run on the Windows OS, but the databases they monitor 
do not need to be running on Windows.
Rights and Privileges
   • To install the network‐based Sensor, you must have administrative privileges 
   on Windows.
   • To run the network‐based Sensor, you must have administrative and “run as a 
   serviceʺ privileges on Windows.
   • To create a custom Filter for Oracle, you must have the following privileges: 
   all_users, all_tables, all_tab_columns, and all_objects.

   For more information on Filters, see the DbProtect Administrator’s Guide and the 
   DbProtect User Guide.
Hardware
   • RAM. 2GB, or at least 512 MB in addition to operating system and database 
   memory requirements. Application Security, Inc. recommends adding more 
   memory if your data volume is high.
   • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is 
   required if you configure the Sensor to log to a local file.
   • Dedicated hardware recommendation. Application Security, Inc. recommends 
   you install the network‐based Sensor on dedicated hardware, because it improves 
   performance and it’s easier to support. However, you can install the network‐
   based Sensor and the Console on the same machine.
Generally, to facilitate the networking requirements listed below, your network 
administrator will install the network‐based Sensor on a machine in the same data 
center as the database(s) it will be monitoring.




                      Application Security, Inc.                                   73
     Networking, Port, and Firewall Considerations

     Please see Networking, Port, and Firewall Considerations for important informa‐
     tion on network connectivity, port availability, and firewalls. The following con‐
     sideration 

     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 required, 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). Older drivers may 
         not work. Other environments currently not supported: ATM, Token Ring, 
         FDDI.
     Application Security, Inc. recommends you use two network interface cards: one 
     for “listening” to database traffic, and one to communicate with the Console, if 
     data volume is high.

     Network-Based Sensor for DB2 - Minimum System
     Requirements

     This topic provides detailed minimum system requirements for the network‐
     based Sensor for DB2.
     Supported DB2 Versions

     DB2 UDB versions 8, 9, and 9.5; DB2 for zSeries v8, v7 (DRDA) (TCP/IP).




74                     Application Security, Inc.
                      Sensor System Requirements




Supported Windows Versions

Windows 2000 Server (including Advanced Server), 32‐bit and 64‐bit (excluding Ita‐
nium); Windows Server 2003 (including Enterprise Edition), 32‐bit and 64‐bit 
(excluding Itanium); Windows 2008, 32‐bit and 64‐bit (excluding Itanium).
Network‐based Sensors only run on the Windows OS, but the databases they monitor 
do not need to be running on Windows.
Rights and Privileges
   • To install the network‐based Sensor, you must have administrative privileges 
   on Windows.
   • To run the network‐based Sensor, you must have administrative and “run as a 
   serviceʺ privileges on Windows.
   • To create a custom Filter for DB2, you must install the appropriate DB2 
   administrative client drivers (for more information, see Appendix G: DB2 
   Administrative Client Driver Installation), and configure it to recognize the 
   monitored database (either through Discovery or reference). Creating a custom 
   Filter for DB2 also requires access to read the following tables:
      -sysibm.systables
      -ysibm.syscolumns
      -sysibm.sysroutines

   For more information on Filters, see the DbProtect Administrator’s Guide and the 
   DbProtect User Guide.
Hardware
   • RAM. 2GB, or at least 512 MB in addition to operating system and database 
   memory requirements. Application Security, Inc. recommends adding more 
   memory if your data volume is high.
   • Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is 
   required if you configure the Sensor to log to a local file.




                      Application Security, Inc.                                   75
        • Dedicated hardware recommendation. Application Security, Inc. 
        recommends you install the network‐based Sensor on dedicated hardware, 
        because it improves performance and it’s easier to support. However, you can 
        install the network‐based Sensor and the Console on the same machine.

 Note:      Generally, to facilitate the networking requirements listed below, your 
            network administrator will install the network‐based Sensor on a machine 
            in the same data center as the database(s) it will be monitoring.

     Networking, Port, and Firewall Considerations

     Please see Networking, Port, and Firewall Considerations for important informa‐
     tion on network connectivity, port availability, and firewalls. The following con‐
     sideration 

     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 required, 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). Older drivers may 
        not work. Other environments currently not supported: ATM, Token Ring, 
        FDDI.

 Note:      Application Security, Inc. recommends you use two network interface cards: 
            one for “listening” to database traffic, and one to communicate with the 
            Console, if data volume is high.



76                     Application Security, Inc.
                       Typical Deploymnet: Recommended System Requirements




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

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 pro‐
gram 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. 

Target Platforms

The following table lists the target platforms that DbProtect Vulnerability Manage‐
ment ScanEngines can be licensed and configured to scan.

    Vulnerability Management                    Target Platforms Supported Versions
Oracle Database Servers                    Oracle 11g, 10gR2, 10g, 9i, 9iR2, 8i
Microsoft SQL Server                       Microsoft SQL Server Versions 2008, 2005, 
                                           2000, MSDE
Lotus Notes/Domino                         Lotus Notes/Domino v7.0, 6.5, 6.0
Sybase Database Servers                    Sybase 15, 12.5, 12.0, 11.9.2
IBM DB2 UDB (LUW)                          IBM DB2 Version 9.5, 9.1, 8.2, 8.1




                       Application Security, Inc.                                       77
 IBM DB2 zSeries                              IBM DB2 Version 9 (z/OS), 8 (z/OS), 7 (OS/390)
 MySQL Servers                                MySQL 5.1, 5.0, 4.1, 4.0

     Host‐Based Database Activity Monitoring Sensors can monitor the following 
     platforms:
        •   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, 10g, 10gR2, 11gR1
        •   IBM DB2 UDB version 8.1, 8.2, 9.1, 9.5
        •   Sybase ASE 11.9.2, 12, 12.5, 15

     Network‐Based Database Activity Monitoring Sensors (not recommended) can 
     monitor the following platforms:
        •   Oracle 8i, 9i, 9iR2, 10g, 10gR2, 11gR1
        •   Sybase ASE 11.9.2, 12, 12.5, 15
        •   IBM DB2 UDB version 8.1, 8.2, 9.1
        •   IBM DB2 OS/390 7 (DRDA) (TCP/IP)
        •   IBM DB2 z/OS 8, 9 (DRDA) (TCP/IP)

 Caution!       These architecture recommendations are not exhaustive. Application 
                Security Inc. may recommend alternative specifications and architectures 
                to meet the requirements of your enterprise.




78                        Application Security, Inc.
                       Typical Deploymnet: Recommended System Requirements




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
Recommended Requirements for the Console Server
For the server supporting the DbProtect Console, the following system requirements 
are recommended.

Virtual Environment      Supported
RAM                      8 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 2 GHz or faster processors
Operating System         •  Windows Server 2008 or 2003 (32‐bit or 64‐bit excluding 
                         Itanium)
                         • Microsoft .NET Framework 2.0 SP1 (x86)

                         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 7.0 or higher recommended or Mozilla 
                         Firefox 3.0 and above. Java Runtime Environment (JRE) 
                         Version 6 update 11 or greater must be installed.




                       Application Security, Inc.                                   79
 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.
 Networking                 Network connectivity is required for the DbProtect Console 
                            to communicate with DbProtect Database Activity Monitor‐
                            ing 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 allowcommunication 
                            between the DbProtect components.

     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.




80                      Application Security, Inc.
                      Typical Deploymnet: Recommended System Requirements




Example Architecture 2

One single server co‐hosting the following components:
   •   DbProtect Console Server
   •   DbProtect Scan Engine
   •   MSSQL data repository server
Recommended Requirements for the Console Server
For the server supporting the DbProtect Console, the following system requirements 
are recommended.

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.




                      Application Security, Inc.                                  81
 Operating System       •  Windows Server 2008 or 2003 (32‐bit or 64‐bit excluding 
                        Itanium)
                        • Microsoft .NET Framework 2.0 SP1 (x86)

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




82                  Application Security, Inc.
             Typical Deploymnet: Recommended System Requirements




Networking     Network connectivity is required for the DbProtect Console 
               to communicate with DbProtect Database Activity Monitor‐
               ing 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 allowcommunication 
               between the DbProtect components.




             Application Security, Inc.                                   83
84   Application Security, Inc.
Chapter 4             Licensing

This chapter explains DbProtect licensing.

DbProtect Licensing Overview

DbProtect licensing is enforced and controlled by information obtained from an 
Application Security, Inc.‐provided set of license files.

A license is required for users to log into DbProtect Console. If you have subscribed 
to software updates, the license file also determines when the DbProtect maintenance 
subscription is scheduled to expire.

DbProtect license files are “node locked”. In order to receive a license for your prod‐
uct implementation, you will need to provide some specific details about your 
server(s) to Application Security, Inc.

How are licenses consumed?

Each database/application on your network requires a license to perform Penetration 
Tests, Audits or Rights Reviews (by a Scan Engine) or to be monitored (by a Sensor). 
Discovery results are not metered.
   • Vulnerabilty Assessment and Rights Review license consumption. When you 
   run a test against a database/application for the first time, one license of the 
   appropriate type (i.e., Penetration Test or Audit) is consumed from the available 
   set of licenses for that particular database/application type. The consumed license 
   is then “node locked” to the IP address of the Penetration Tested or Audited 
   database/application. You can re‐test these applications any time without 
   consuming another license. For more information on viewing your number of 
   available licenses, see Viewing your “node locked” Scan Engine licensing 
   information.
     • Audit and Threat Management license consumption. When you enumerate 
     a database asset to monitor with the appropriate type of Sensor, the Sensor 
     registration process is what consumes a Sensor license. The license remains 
     “node locked” for a given database as long as it is registered using the Sensor 
     Manager in DbProtect Audit and Threat Management (for more information, 
     see Registering a Sensor in the DbProtect User Guide).




77                  Application Security, Inc.
The Mechanics of DbProtect Licensing

To use DbProtect, you must install at least two license files, i.e., one for the DbProtect 
Console, and one for each Scan Engine.

Contact Application Security, Inc. Customer Support (support@appsecinc.com) and 
provide the following information:
   •For each host where a DbPRotect Console and a Scan Engine are installed, 
   obtain the VolumeID of your server by running 
   %ProgramFiles%\AppSecInc\EnterpriseServicesHost\util\asiidentify.exe
   and provide it to Application Security, Inc. Customer Support along with the 
   number of Penetration Test, Audit and Rights Review licenses you require for 
   each database type.
   • Application Security, Inc. Customer Support or your sales representative will 
   email your license files and installation instructions.
Licensing Artifacts

Application Security, Inc. Customer Support will email you a set of license files 
(ADnnnnnnnnn.lic and ARnnnnnnnnn.lic).

Install all .lic files into %ProgramFiles%\AppSecInc\Licenses.

You must deploy the:
   • ADnnnnnnnnn.lic and ARnnnnnnnnn.lic licenses files on your DbProtect Console 
   host.
   • ADnnnnnnnnn.lic license files on each DbProtect ScanEngine host.


Viewing your “node locked” Scan Engine licensing information

On any Scan Engine host, you can open the License Viewer. It shows where your 
Scan Engine license file is located, how many licenses you have, how many Penetra‐
tion Test and Audit licenses you’ve used (and on which platforms), etc.

To view your Scan Engine licensing info: 


                       Application Security, Inc.                                       78
     1.   Choose Start > Programs > AppSecInc > ScanEngine > License Viewer to dis‐
          play the License Viewer.

     The License Viewer provides:
          •   the license file location in the License File: field
          •   your basic license file information, including:

         ‐ Customer Name
         ‐ License Type
         ‐ Product Version
         ‐ Expiration Date
         ‐ ASAP Expiration
         ‐ Machine ID#
     2. The AppDetective ‐ Licensing Info dialog box allows you to:
         • view how many licenses you purchased (see the Licenses Purchased: field, 
         which is below the Penetration Tests and Security Audits tabs)
         • click the Penetration Tests and Security Audits tabs, respectively, to see how 
         many Penetration Test and Audit licenses you’ve used to‐date
         • use the Application Type: drop‐down to filter your used license data by 
         platform (e.g., Oracle, My SQL, Sybase, Web Applications, etc.).
     3. You can also click the:
         • Get Machine ID # button to display the AppDetective ‐ Machine ID 
         Number pop‐up, which displays your machine ID
         • Select License File button to display an Open dialog box, which allows you 
         to open your .lic file.
 Hint:         Click the Copy to clipboard button to copy your machine ID to your com‐
               puter’s clipboard, whereupon you can paste the number into a field, docu‐
               ment, etc.




79                          Application Security, Inc.
Chapter 5                Installing the DbProtect Components

This chapter explains how to install the following DbProtect components:
   •   DbProtect Suite
   •   Scan Engines
   •   Sensors

Before installing DbProtect, please review the minimum system requirements for the 
DbProtect components. For more information, see Minimum System Requirements.

Installing the DbProtect Suite Components
DbProtect Suite Components

The DbProtect Suite is comprised of a management bundle, which consists of several 
thirdparty pre‐requisites and the following components: 
   • 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 and 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 knowledgebase of vulnerability assessment 
   checks and activity monitoring rules 
   • Data Warehouse: a database schema for the reporting database
   • Enterprise Services: 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 3rd 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).




80                      Application Security, Inc.
                      Installing the DbProtect Suite Components




Installing DbProtect Suite

The DbProtect Suite is available as one bundle, which detects prerequisites and 
installs the necessary components. Data collection agents are deployed separately.
1. Locate the DbProtect setup package on the media provided or download it from 
   the Application Security customer portal website into a convenient location (e.g., 
   c:\temp). 
2. Launch the setup package. 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.




                      Application Security, Inc.                                     81
     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 loca‐
          tion the first time you install theDbProtect Suite.
     4. You must read and accept the license agreement every time you install or 
        upgrade the software.
     5. Clicking the Install button will begin installation of all components in the order 
        they are listed. The installer may require a system reboot and will resume after 
        the system is back up.




82                            Application Security, Inc.
                      Installing the DbProtect Suite Components




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.




Choose Run service as LocalSystem or browse for a specific user.
If you choose a specific user, ensure that he 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 toconnect 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 Inte‐
grated Authentication.




                      Application Security, Inc.                                     83
     Database Component Setup

     The Database Component setup creates a Microsoft SQL Server database for 
     DbProtect’s operational data. The database is called AppDetective.
     You can pre‐create your own AppDetective database as long as it adheres to 
     specific requirements outlined in Appendix S: DbProtect Requirements for Sybase 
     ASE.
     The Database Component installer prompts for a database server and/or instance. You may enter a server
     name, a server\instance or server:port.




     The Database Component installer prompts for database credentials. Choose Win-
     dows Authentication    to use your current credentials during installation and cre‐
     dentials of the Enterprise Services Host service at runtime. Choose SQL
     Authentication to specify a database login and password.




84                           Application Security, Inc.
                      Installing the DbProtect Suite Components




If youʹre not sure which authentication type to select, see your database administra‐
tor.




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

Creating Your Own Microsoft SQL Server AppDetective Database

As explained in Installing the DbProtect Suite Components, 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 specific 
requirements outlined in this appendix. If your AppDetective Microsoft SQL Server 
database does not adhere to these requirements, the Database Component installa‐
tion will fail (meaning, your entire DbProtect suite installation will also fail).

To create your own AppDetective Microsoft SQL Server database:


                      Application Security, Inc.                                   85
     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'




86                        Application Security, Inc.
                      Installing Scan Engines




Data Warehouse Setup

The Data Warehouse setup creates two Microsoft SQL Server databases for DbPro‐
tect’s reporting data. The databases arecalled dbpdatawarehouse and dbpstaging.
The Data Warehouse Setup prompts for a database server and/or instance as well as 
database access credentials in a similar manner as the Data Component Setup.

DbProtect Analytics Setup

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

The Analytics Setup prompts for a database server and/or instance as well as data‐
base access credentials in a similar manner as the Data Component Setup. In addi‐
tion, 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 dbpa-
nalytics database.


Installing Scan Engines
DbProtect Scan Engine Components

The DbProtect Scan Engine is comprised of a management bundle, which consists of 
the following components: 
   • Scan Engine: a service responsible for Vulnerability Assessemnt 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.

Installing Scan Engine




                      Application Security, Inc.                                     87
     1. Locate the ScanEngine setup package on the media provided or download it 
        from the Application Security customer portal website into a convenient loca‐
        tion (e.g., c:\temp). 
     2. Launch the setup package. ScanEngine Setup will detect any missing prerequi‐
        sites or previously installed components. It will display and disable those com‐
        ponents 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.

     Clicking the Install button will begin installation of all components in the order they are listed. 
     The installer may require a system reboot and will resume after the system is back up.




88                          Application Security, Inc.
                      Installing, Starting/Stopping, and Reconfiguring the Sensors




DbProtect SCAN ENGINE Setup

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

The installer prompts you for a destination folder. By default, the installer deploys 
Scan Engine in under %ProgramFiles%\AppSecInc\Scan Engine. 




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

Installing, Starting/Stopping, and Reconfiguring
the Sensors
This section provides detailed installation steps for the Sensor components of DbPro‐
tect. There are two types of Sensors available: host‐based and network‐based. This 
section also explains how to start and stop the Sensors (on a Windows or *nix plat‐
form), and how to reconfigure your Sensors (on a Windows or *nix platform).


                      Application Security, Inc.                                     89
     First make sure you have carefully read the minimum system requirements for 
     the Sensors. For more information, see Sensor System Requirements.




90                    Application Security, Inc.
                      Installing, Starting/Stopping, and Reconfiguring the Sensors




Host-based Sensors (supported databases and platforms)

Host‐based Sensors allow you to monitor the following databases on a host server:
   •   Microsoft SQL Server on Windows
   •   DB2 on Solaris, AIX, Red Hat Enterprise Linux, and Windows
   •   Oracle on Solaris, AIX, HP‐UX, Red Hat Enterprise Linux, and Windows
   •   Sybase on Solaris and AIX.

If you want to install a host‐based Sensor, the table below lists supported database/
OS combinations, and links you to the installation steps. 

               DB           OS                                 Go to:

            MICROS     WINDO            Host‐based Sensor for SQL Server (on 
            OFT        WS               Windows) ‐ installation steps
            SQL 
            SERVER
            DB2        RED HAT  Host‐based Sensor for DB2 (on Red 
                       ENTERP   Hat Enterprise Linux) ‐ installation 
                       RISE     steps
                       LINUX
                       SOLARIS          Host‐based Sensor for DB2 (on 
                                        Solaris) ‐ installation steps
                       AIX              Host‐based Sensor for DB2 (on AIX) ‐ 
                                        installation steps
                       WINDO            Host‐based Sensor for DB2 (on 
                       WS               Windows) ‐ installation steps
            SYBASE     SOLARIS          Host‐based Sensor for Sybase (on 
                                        Solaris) ‐ installation steps
                       AIX              Host‐based Sensor for Sybase (on 
                                        AIX) ‐ installation steps



                      Application Security, Inc.                                     91
       DB           OS                       Go to:

     ORACL     SOLARIS       Host‐based Sensor for Oracle (on 
     E                       Solaris) ‐ installation steps
               AIX           Host‐based Sensor for Oracle (on AIX) 
                             ‐ installation steps
               HP‐UX         Host‐based Sensor for Oracle (on HP‐
                             UX) ‐ installation steps
               RED HAT  Host‐based Sensor for Oracle (on Red 
               ENTERP   Hat Enterprise Linux) ‐ installation 
               RISE     steps
               LINUX
               WINDO         Host‐based Sensor for Oracle (on 
               WS            Windows) ‐ installation steps




92           Application Security, Inc.
                              Installing, Starting/Stopping, and Reconfiguring the Sensors




Network-based Sensors (supported databases and platforms)

Network‐based Sensors allow you to monitor Sybase, Oracle, and DB2 on the net‐
work. If you want to install a network‐based Sensor, the table below lists supported 
database/OS combinations, and links you to the installation steps.
Network‐based Sensors only run on the Windows OS, but the databases they monitor 
do not need to be running on Windows.  

                  DB            OS                                   Go to:

               DB2          WINDO          Network‐based Sensor for Sybase, Oracle, and DB2 ‐ 
                                           installation steps
                            WS
               SYBAS
               E
               ORAC
               LE

Host-based Sensor for SQL Server (on Windows) - installation
steps
Important: To install a host-based Sensor for Microsoft SQL Server, you must be a Windows user with
           administrative rights on both the host server and Microsoft SQL Server. You must also have domain
           administrator rights to install a host-based Sensor for SQL Server in a cluster. To run the host-based
           Sensor for Microsoft SQL Server, you must have “run as a service" rights on Windows, and
           administrative rights on Microsoft SQL Server at runtime.

To install the host‐based Sensor for Microsoft SQL Server on Windows:
1. Locate the setup file on the Application Security, Inc.‐provided CD, or download it 
   from the Application Security, Inc. FTP site or website.
2. Save the file to a convenient location (e.g., c:\temp).




                              Application Security, Inc.                                                        93
     3. Double click the executable file to display the installation wizard (Welcome 
        page) and begin the Sensor installation.

     The installer indicates which version of the Sensor it will install.




     Click the Install button to display the License Agreement page.
     4. The License Agreement page is shown below.




94                      Application Security, Inc.
                      Installing, Starting/Stopping, and Reconfiguring the Sensors




   •  Read the License Agreement.
   •  If you accept the terms of the License Agreement, select I accept the terms in 
    the license agreement.
    • Click the Next button to display the Choose Destination Location page.
5. The Destination Folder page is shown below.




   • Choose the location of the Sensor installation directory. You can click the:
      ‐Change... button to choose a directory manually
      ‐Next button to choose the default location. (The default location is: 
      <installation folder>:\AppSecInc\Sensor\). 
   • Click the Next button to display the Sensor Type page.




                      Application Security, Inc.                                     95
     6. The Sensor Type page is shown below.




     Select Host‐based Sensor and click the Next button to display the Server Port 
     page.
     You can reconfigure an installed Windows‐based Sensor at anytime using the 
     Windows Start menu or the command line; for more information, see 
     Reconfiguring a Sensor (installed on Windows) using the DbProtect Sensor 
     Configuration tool or the command line.




96                     Application Security, Inc.
                     Installing, Starting/Stopping, and Reconfiguring the Sensors




7. The Server Port page is shown below.




   •  Specify which port number the Sensor should use to receive commands from 
   the Console. The default port (20000) is recommended for most configurations, 
   but you can specify a different port number (1-65535). For more information on 
   required open listen ports, see Networking, Port, and Firewall Considerations.
   • You must click the Test Port button to test the port information. If the 
   connection is successful, a green checkmark icon appears, and the Next button is 
   illuminated.
   • Click the Next button to display the Service Log On Credentials page.




                     Application Security, Inc.                                     97
     8. The Sensor Service Logon Details page is shown below.




     Important: If you want to specify a non-local user username and password for the Sensor to run under, you
                must do so in this step.

         You can select:
              ‐Run service as Local System, if you want to use the ʺlocal systemʺ 
              account, which has full access rights and privileges on the host computer.
              ‐Run service as: to specify a domain user login and password.
     Important: The Sensor logs in to the monitored database, and the Sensor service runs, under this user
                profile. This profile must be a Windows user with administrator rights. Also, the account name
                specified must have the "log on as service" permission set in the Local Security Policy of the
                server (for more information, see your Windows help). If you select Run service as:, then you must
                enter a valid domain name\user name and password. Also, the domain user must be a Windows
                user with administrative rights on both the host server and SQL Server, and must have domain
                administrator rights to install a host-based Sensor for SQL Server in a cluster.
         •   Click the Next button to display the Install DbProtect Sensor page.




98                            Application Security, Inc.
                       Installing, Starting/Stopping, and Reconfiguring the Sensors




9. The Install DbProtect Sensor page is shown below.




   • If want to review or change any settings you can click the Back button.
   • Click the Install button. When the installation finishes, a Sensor installation 
   success page appears.




                       Application Security, Inc.                                       99
  10.The Sensor installation success page is shown below.




      •Review the installation details at the bottom of the page.
      •Click the Finish button to close the installer.
  11.A congratulations pop‐up appears.




     • Click the OK button to close the congratulations pop‐up.
  DbProtect allows you to use the DbProtect Sensor Configuration tool to 
  reconfigure the Sensor installation parameters (for example, server port number). 
  For more information, see Reconfiguring a Sensor (installed on Windows) using 
  the DbProtect Sensor Configuration tool.




100                  Application Security, Inc.
                            Installing, Starting/Stopping, and Reconfiguring the Sensors




Host-based Sensor for DB2 (on Red Hat Enterprise Linux) -
installation steps
You can configure your host‐based Sensor for DB2 (on Red Hat Enterprise Linux) to 
start automatically upon system reboot; for more information, see Appendix R: 
Configuring Your Host‐Based Sensor (Installed on a *nix Platform) to Start 
Automatically Upon System Reboot.
Important: For information on performing an ASAP update of a host-based Sensor for DB2 on a *nix host, see the
           DbProtect Administrator’s Guide.

To install a host‐based Sensor for DB2 on Red Hat Enterprise Linux 3, 4, or 5 (32‐bit 
x86 and 64‐bit x64): 
1.   Application Security, Inc. strongly recommends you create a unique DbProtect 
     user called appradar, and use this account for host‐based Sensor for DB2 installa‐
     tion. While creating this user is not mandatory, it will ensure that other database 
     administrators canʹt turn off your host‐based DB2 Sensors. 

     The appradar user must belong to the primary group of the DB2 instance owner. In 
     many cases db2inst1 is the default DB2 user name, while the default group name 
     is typically db2iadm1. The user (i.e., appradar) must be a member of the same 
     db2iadm1 group as DB2 user on the host. 

  To determine your DB2 group name, enter the following command: id db2inst1. 
  Your DB2 user name (uid) and group name (gid) should display, e.g., 
  uid=1001(db2inst1) gid=503(db2iadm1).
Caution! A host-based Sensor for DB2 can only monitor one DB2 instance. If you want to monitor
           multiple instances on an DB2 server, see Appendix C: Modifying the Sensor Listener Port
           Number and Appendix P: Monitoring Multiple Instances on a DB2 Server.
2. The DB2 administrator must grant the following privileges to the appradar user 
   for every DB2 database in the instance you want to monitor:
    • SYSADM if you want to monitor unsuccessful authentication attempts
    • DBADM if you do not want to monitor unsuccessful authentication attempts.




                            Application Security, Inc.                                                   101
  3. The person installing the host‐based DB2 Sensor logs in as the user who will 
     run the host‐based DB2 Sensor, i.e., appradar, or the user created by the Unix 
     administrator (root) in Step 1.
  Caution! The account running the DB2 database must be in the same user group as the
           account running the host-based Sensor for DB2 installation script.




102                   Application Security, Inc.
                             Installing, Starting/Stopping, and Reconfiguring the Sensors




4. Download or copy the host‐based Sensor file to your target database host. The file 
   names are:
    • DbProtect_Sensor_<version number>_Linux32.tgz.sh for Red Hat Enterprise 
    Linux (32‐bit x86)
    • DbProtect_Sensor_<version number>_Linux64.tgz.sh for Red Hat Enterprise 
    Linux (64‐bit x64).
5. Install the host‐based Sensor file as follows:
    •   sh "./DbProtect_Sensor_<version      number>_Linux32.tgz.sh"       install <installation_dir>



    for Red Hat Enterprise Linux (32‐bit x86), where <installation_dir> is the 
    directory where you want to install the Sensor, e.g. /opt.
    •   sh "./DbProtect_Sensor_<version      number>_Linux64.tgz.sh"       install <installation_dir>



    for Red Hat Enterprise Linux (64‐bit x64), where <installation_dir> is the 
    directory where you want to install the Sensor, e.g. /opt.
If the filename contains spaces, then donʹt forget to quote these spaces in the 
command.

The host‐based Sensor is installed in the "<installation_dir>/ASIappradar/" direc‐
tory.
6. Start your Sensor; for more information, see Starting and stopping the Sensors on Windows.
Important: The Sensor uses default port 20000 to receive commands from the Console. This port is
           recommended for most configurations, but you can specify a different port number (1-65535).

            To change the default port number for host-based Sensors installed on a *nix platform, you must
            manually modify the sensor.xml and sensor_original.xml files; for more information, see
            Appendix C: Modifying the Sensor Listener Port Number.

            For more information on required open listen ports, see Networking, Port, and Firewall
            Considerations.




                             Application Security, Inc.                                                 103
  Host-based Sensor for DB2 (on Solaris) - installation steps
  You can configure your host‐based Sensor for DB2 (on Solaris) to start 
  automatically upon system reboot; for more information, see Appendix R: 
  Configuring Your Host‐Based Sensor (Installed on a *nix Platform) to Start 
  Automatically Upon System Reboot.
  Important: For information on performing an ASAP update of a host-based Sensor for DB2 on a *nix host,
             see the DbProtect Administrator’s Guide.

  To install a host‐based Sensor for DB2 on Solaris 8, 9, and 10 (64‐bit SPARC): 
  1.   Application Security, Inc. strongly recommends you create a unique DbProtect 
       user called appradar, and use this account for host‐based Sensor for DB2 instal‐
       lation. While creating this user is not mandatory, it will ensure that other data‐
       base administrators canʹt turn off your host‐based DB2 Sensors. 

       The appradar user must belong to the primary group of the DB2 instance 
       owner. In many cases db2inst1 is the default DB2 user name, while the default 
       group name is typically db2iadm1. The user (i.e., appradar) must be a member 
       of the same db2iadm1 group as DB2 user on the host. 

    To determine your DB2 group name, enter the following command: id
    db2inst1. Your DB2 user name (uid) and group name (gid) should display, e.g., 
    uid=1001(db2inst1) gid=503(db2iadm1).
  Caution! A host-based Sensor for DB2 can only monitor one DB2 instance. If you want to
             monitor multiple instances on an DB2 server, see Appendix C: Modifying the Sensor
             Listener Port Number and Appendix P: Monitoring Multiple Instances on a DB2
             Server.
  2. The DB2 administrator must grant the following privileges to the appradar 
     user for every DB2 database in the instance you want to monitor:
      • SYSADM if you want to monitor unsuccessful authentication attempts
      • DBADM if you do not want to monitor unsuccessful authentication attempts.
  3. The person installing the host‐based DB2 Sensor logs in as the user who will 
     run the host‐based DB2 Sensor, i.e., appradar, or the user created by the Unix 
     administrator (root) in Step 1.
  Caution! The account running the DB2 database must be in the same user group as the
             account running the host-based Sensor for DB2 installation script.




104                      Application Security, Inc.
                      Installing, Starting/Stopping, and Reconfiguring the Sensors




4. Download or copy the host‐based Sensor installation file to your target database 
   host. The file is: DbProtect_Sensor_<version number>__Solaris64.tgz.sh




                      Application Security, Inc.                                     105
  5. Install the host‐based Sensor file as follows:
  sh "./DbProtect_Sensor_<version number>__Solaris64.tgz.sh" install <installation_dir>


  where <installation_dir> is the directory where you want to install the Sensor, 
  e.g. /opt.

  If the filename contains spaces, then donʹt forget to quote these spaces in the com‐
  mand.

  The host‐based Sensor is installed in the ʺ<installation_dir>/ASIappradar/ʺ direc‐
  tory.
  6. Start your Sensor; for more information, see Starting and stopping the Sensors on Win‐
     dows.
  Important: The Sensor uses default port 20000 to receive commands from the Console. This port is
             recommended for most configurations, but you can specify a different port number (1-65535).

             To change the default port number for host-based Sensors installed on a *nix platform, you must
             manually modify the sensor.xml and sensor_original.xml files; for more information,
             see Appendix C: Modifying the Sensor Listener Port Number.

             For more information on required open listen ports, see Networking, Port, and Firewall
             Considerations.


  Host-based Sensor for DB2 (on AIX) - installation steps
  You can configure your host‐based Sensor for DB2 (on AIX) to start automatically 
  upon system reboot; for more information, see Appendix R: Configuring Your 
  Host‐Based Sensor (Installed on a *nix Platform) to Start Automatically Upon 
  System Reboot.
  Important: For information on performing an ASAP update of a host-based Sensor for DB2 on a *nix host,
             see the DbProtect Administrator’s Guide.




106                       Application Security, Inc.
                          Installing, Starting/Stopping, and Reconfiguring the Sensors




To install a host‐based Sensor for DB2 on a *nix host running AIX 5.2 Technology 
Level 5 and up:
1.   Application Security, Inc. strongly recommends you create a unique DbProtect 
     user called appradar, and use this account for host‐based Sensor for DB2 installa‐
     tion. While creating this user is not mandatory, it will ensure that other database 
     administrators canʹt turn off your host‐based DB2 Sensors. 

     The appradar user must belong to the primary group of the DB2 instance owner. In 
     many cases db2inst1 is the default DB2 user name, while the default group name 
     is typically db2iadm1. The user (i.e., appradar) must be a member of the same 
     db2iadm1 group as DB2 user on the host. 

  To determine your DB2 group name, enter the following command: id db2inst1. 
  Your DB2 user name (uid) and group name (gid) should display, e.g., 
  uid=1001(db2inst1) gid=503(db2iadm1).
Caution! A host-based Sensor for DB2 can only monitor one DB2 instance. If you want to monitor
           multiple instances on an DB2 server, see Appendix C: Modifying the Sensor Listener Port
           Number and Appendix P: Monitoring Multiple Instances on a DB2 Server.
2. The DB2 administrator must grant the following privileges to the appradar user 
   for every DB2 database in the instance you want to monitor:
    • SYSADM if you want to monitor unsuccessful authentication attempts
    • DBADM if you do not want to monitor unsuccessful authentication attempts.
3. The person installing the host‐based DB2 Sensor logs in as the user who will run 
   the host‐based DB2 Sensor, i.e., appradar, or the user created by the Unix adminis‐
   trator (root) in Step 1.
Caution! The account running the DB2 database must be in the same user group as the account
           running the host-based Sensor for DB2 installation script.
4. Download or copy the host‐based Sensor file to your target database host. The file 
   names are:
    • DbProtect_Sensor_<version number>_aix-ppc-32.tgz.sh for AIX (32‐bit)
    • DbProtect_Sensor_<version number>_aix-ppc-64.tgz.sh for AIX (64‐bit).




                          Application Security, Inc.                                          107
  5. Install the host‐based Sensor file as follows:
       •   sh "./DbProtect_Sensor_<version number>_aix-ppc-32.tgz.sh" install <installation_dir>



       for AIX (32‐bit), where <installation_dir> is the directory where you want to 
       install the Sensor, e.g. /opt.
       •   sh "./DbProtect_Sensor_<version number>_aix-ppc-64.tgz.sh" install <installation_dir>



      for AIX (64‐bit), where <installation_dir> is the directory where you want to 
      install the Sensor, e.g. /opt.
  If the filename contains spaces, then donʹt forget to quote these spaces in the 
  command.

  The host‐based Sensor is installed in the "<installation_dir>/ASIappradar/" 
  directory.
  6. Start your Sensor; for more information, see Starting and stopping the Sensors on Win‐
     dows.
  Important: The Sensor uses default port 20000 to receive commands from the Console. This port is
             recommended for most configurations, but you can specify a different port number (1-65535).

               To change the default port number for host-based Sensors installed on a *nix platform, you must
               manually modify the sensor.xml and sensor_original.xml files; for more information,
               see Appendix C: Modifying the Sensor Listener Port Number.

               For more information on required open listen ports, see Networking, Port, and Firewall
               Considerations.


  Host-based Sensor for DB2 (on Windows) - installation steps
  Important: To install a host-based Sensor for DB2, you must be a Windows user with administrative rights on
             the host server.

  To install a host‐based Sensor for DB2 on Windows:
  1. Locate the setup file on the Application Security, Inc.‐provided CD, or down‐
     load it from the Application Security, Inc. FTP site or website.
  2. Save the file to a convenient location (e.g., c:\temp).




108                         Application Security, Inc.
                       Installing, Starting/Stopping, and Reconfiguring the Sensors




3. Double click the executable file to display the installation wizard (Welcome page) 
   and begin the Sensor installation.

The installer indicates which version of the Sensor it will install.




Click the Install button to display the License Agreement page.
4. The License Agreement page is shown below.




                       Application Security, Inc.                                     109
      • Read the License Agreement.
      • If you accept the terms of the License Agreement, select I accept the terms 
      in the license agreement.
      • Click the Next button to display the Choose Destination Location page.
  5. The Destination Folder page is shown below.




      • Choose the location of the Sensor installation directory. You can click the:
         ‐Change... button to choose a directory manually
         ‐Next button to choose the default location. (The default location is: 
         c:\AppSecInc\Sensor\). 
      • Click the Next button to display the Sensor Type page.




110                  Application Security, Inc.
                     Installing, Starting/Stopping, and Reconfiguring the Sensors




6. The Sensor Type page is shown below.




Select Host‐based Sensor and click the Next button to display the Server Port page.
You can reconfigure an installed Sensor at anytime using the Windows Start menu or 
the command line; for more information, see Reconfiguring a Sensor (installed on 
Windows) using the DbProtect Sensor Configuration tool or the command line.




                     Application Security, Inc.                                     111
  7. The Server Port page is shown below.




      • Specify which port number the Sensor should use to receive commands from 
      the Console. The default port (20000) is recommended for most 
      configurations, but you can specify a different port number (1-65535). For 
      more information on required open listen ports, see Networking, Port, and 
      Firewall Considerations.
      • You must click the Test Port button to test the port information. If the 
      connection is successful, a green checkmark icon appears, and the Next button 
      is illuminated.
      • Click the Next button to display the Service Log On Credentials page.




112                  Application Security, Inc.
                             Installing, Starting/Stopping, and Reconfiguring the Sensors




8. The Sensor Service Logon Details page is shown below.




    •   Specify a database user login and password.
Important: If you want to specify a non-local user username and password for the Sensor to run under, you must
           do so in this step.

    You can select:
         ‐Run service as Local System, if you want to use the ʺlocal systemʺ account, 
         which has full access rights and privileges on the host computer.
         ‐Run service as: to specify a domain user login and password.
Important: The Sensor logs in to the monitored database, and the Sensor service runs, under this user profile.
           This profile must be a Windows user with administrator rights. Also, the account name specified must
           have the "log on as service" permission set in the Local Security Policy of the server (for more
           information, see your Windows help). If you select Run service as:, then you must enter a valid domain
           name\user name and password.
    •   Click the Next button to display the Install DbProtect Sensor page.




                             Application Security, Inc.                                                     113
  9. The Install DbProtect Sensor page is shown below.




      • If want to review or change any settings you can click the Back button.
      • Click the Install button. When the installation finishes, a Sensor installation 
      success page appears.




114                   Application Security, Inc.
                      Installing, Starting/Stopping, and Reconfiguring the Sensors




10.The Sensor installation success page is shown below.




   • Review the installation details at the bottom of the page.
   • Click the Finish button to close the installer.
11.A congratulations pop‐up appears.




12.Click the OK button to close the congratulations pop‐up.
DbProtect allows you to switch a host‐based Sensor to a network‐based Sensor, or 
vice‐versa, without having to uninstall the Sensor, then re‐install/reconfigure it. 
There are two ways to accomplish this. The first is using the DbProtect Sensor 
Configuration tool; for more information, see Reconfiguring a Sensor (installed on 
Windows) using the DbProtect Sensor Configuration tool. The second is using the 
command line; for more information, see Reconfiguring a Sensor (installed on 
Windows) using a command line.




                      Application Security, Inc.                                     115
  Host-based Sensor for Sybase (on Solaris) - installation steps

  To install a host‐based Sensor for Sybase on a *nix host running Solaris 8, 9, 10 (32‐ 
  and 64‐bit SPARC):
  1.Log in as a user that will run the Sensor, i.e., appradar.
  Caution! Do not log in as root

  2. Download or copy the installer to a writable directory on your target database 
     host. The file names are:
      • DbProtect_Sensor_<version number>_Solaris32.tgz.sh for Solaris (32‐bit 
      SPARC)
      • DbProtect_Sensor_<version number>_Solaris64.tgz.sh for Solaris (64‐bit 
      SPARC).
  3. Install the host‐based Sensor file as follows:
       •   sh "./DbProtect_Sensor_<version number>_Solaris32.tgz.sh" install <installation_dir>



       for Solaris (32‐bit SPARC), where <installation_dir> is the directory where 
       you want to install the Sensor, e.g. /opt.
       •   sh "./DbProtect_Sensor_<version number>_Solaris64.tgz.sh" install <installation_dir>



      for Solaris (64‐bit SPARC), where <installation_dir> is the directory where 
      you want to install the Sensor, e.g. /opt.
  If the filename contains spaces, then donʹt forget to quote these spaces in the 
  command.

  The host‐based Sensor is installed in the "<installation_dir>/ASIappradar/" 
  directory.
  4. Start your Sensor; for more information, see Starting and stopping the Sensors on Win‐
       dows.




116                         Application Security, Inc.
                            Installing, Starting/Stopping, and Reconfiguring the Sensors




Important: The Sensor uses default port 20000 to receive commands from the Console. This port is
           recommended for most configurations, but you can specify a different port number (1-65535).

           To change the default port number for host-based Sensors installed on a *nix platform, you must
           manually modify the sensor.xml and sensor_original.xml files; for more information, see
           Appendix C: Modifying the Sensor Listener Port Number.

           For more information on required open listen ports, see Networking, Port, and Firewall
           Considerations.


Host-based Sensor for Sybase (on AIX) - installation steps

To install a host‐based Sensor for Sybase on a *nix host running AIX 5.2 Technology 
Level 5 and greater:
1.Login as a user that will run the Sensor, i.e., appradar.
Caution! Do not log in as root

The user (i.e., appradar) must be a member of the same “dba” group as oracle on the 
host.
2. Download or copy the installer to a writable directory on your target database 
   host. The file names are:
    • DbProtect_Sensor_<version number>_aix-ppc-32.tgz.sh for AIX (32‐bit)
    • DbProtect_Sensor_<version number>_aix-ppc-64.tgz.sh for AIX (64‐bit).
3. Install the host‐based Sensor file as follows:
     • sh "./DbProtect_Sensor_<version number>_aix-ppc-32.tgz.sh" install
     <installation_dir>

     for AIX (32‐bit), where <installation_dir> is the directory where you want to 
     install the Sensor, e.g. /opt.
     • sh "./DbProtect_Sensor_<version number>_aix-ppc-64.tgz.sh" install
     <installation_dir>

    for AIX (64‐bit), where <installation_dir> is the directory where you want to 
    install the Sensor, e.g. /opt.
If the filename contains spaces, then donʹt forget to quote these spaces in the 
command.


                            Application Security, Inc.                                                   117
  The host‐based Sensor is installed in the "<installation_dir>/ASIappradar/" 
  directory.
  4. Start your Sensor; for more information, see Starting and stopping the Sensors on Win‐
     dows.
  Important: The Sensor uses default port 20000 to receive commands from the Console. This port is
             recommended for most configurations, but you can specify a different port number (1-65535).

             To change the default port number for host-based Sensors installed on a *nix platform, you must
             manually modify the sensor.xml and sensor_original.xml files; for more information,
             see Appendix C: Modifying the Sensor Listener Port Number.

             For more information on required open listen ports, see Networking, Port, and Firewall
             Considerations.


  Host-based Sensor for Oracle (on Solaris) - installation steps
  You can configure your host‐based Sensor for Oracle (on Solaris) to start 
  automatically upon system reboot; for more information, see Appendix R: 
  Configuring Your Host‐Based Sensor (Installed on a *nix Platform) to Start 
  Automatically Upon System Reboot.

  Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle 
  relational database management system (RDBMS) software simultaneously while 
  accessing a single database, thus providing a clustered database. For more 
  information on configuring a host‐based Sensor to monitor databases on an 
  Oracle RAC, see Appendix B: Installing and Configuring a Host‐Based Sensor for 
  Oracle to Monitor Oracle Databases on an Oracle RAC.
  Important: For information on performing an ASAP update of a host-based Sensor for Oracle on a *nix host,
             see the DbProtect Administrator’s Guide.

  To install a host‐based Sensor for Oracle on a *nix host running Solaris 8, 9, 10 (32‐ 
  and 64‐bit SPARC):
  1.Login as a user that will run the Sensor, i.e., appradar.
  Caution! Do not log in as root

  The user (i.e., appradar) must be a member of the same “dba” group as oracle on 
  the host.



118                       Application Security, Inc.
                      Installing, Starting/Stopping, and Reconfiguring the Sensors




2. Download or copy the host‐based Sensor file to your target database host. The file 
   names are:
    • DbProtect_Sensor_<version number>_Solaris32.tgz.sh for Solaris (32‐bit SPARC)
    • DbProtect_Sensor_<version number>_Solaris64.tgz.sh for Solaris (64‐bit SPARC).




                      Application Security, Inc.                                     119
  3. Install the host‐based Sensor file as follows:
      •   sh "./DbProtect_Sensor_<version number>_Solaris32.tgz.sh" install <installation_dir>



      for Solaris (32‐bit SPARC), where <installation_dir> is the directory where 
      you want to install the Sensor, e.g. /opt.
      •   sh "./DbProtect_Sensor_<version number>_Solaris64.tgz.sh" install <installation_dir>



      for Solaris (64‐bit SPARC), where <installation_dir> is the directory where 
      you want to install the Sensor, e.g. /opt.
  If the filename contains spaces, then donʹt forget to quote these spaces in the 
  command.

  The host‐based Sensor is installed in the "<installation_dir>/ASIappradar/" 
  directory.
  4. Finally, you must configure your host‐based Sensor for Oracle DDL triggers, 
     and configure your host‐based Sensor for Oracle audit trail to monitor failed 
     logins. For more information, see Appendix E: Working with Oracle DDL Triggers (for Host‐
     Based Sensors for Oracle Installed on *nix Platforms Only) and Appendix J: Configuring Your 
     Oracle Audit Trail in Order to Monitor Logins, respectively.
  If you remove and re‐add a DDL trigger for any reason, you must re‐start the 
  Sensor afterwards. Most DDL rules will not fire until this is done.
  5. Start your Sensor; for more information, see Starting and stopping the Sensors on Win‐
     dows.
  Important: The Sensor uses default port 20000 to receive commands from the Console. This port is
             recommended for most configurations, but you can specify a different port number (1-65535).

              To change the default port number for host-based Sensors installed on a *nix platform, you must
              manually modify the sensor.xml and sensor_original.xml files; for more information,
              see Appendix C: Modifying the Sensor Listener Port Number.

              For more information on required open listen ports, see Networking, Port, and Firewall
              Considerations.




120                        Application Security, Inc.
                            Installing, Starting/Stopping, and Reconfiguring the Sensors




Host-based Sensor for Oracle (on AIX) - installation steps
You can configure your host‐based Sensor for Oracle (on AIX) to start automatically 
upon system reboot; for more information, see Appendix R: Configuring Your Host‐
Based Sensor (Installed on a *nix Platform) to Start Automatically Upon System 
Reboot.

Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle 
relational database management system (RDBMS) software simultaneously while 
accessing a single database, thus providing a clustered database. For more 
information on configuring a host‐based Sensor to monitor databases on an Oracle 
RAC, see Appendix B: Installing and Configuring a Host‐Based Sensor for Oracle to 
Monitor Oracle Databases on an Oracle RAC.
Important: For information on performing an ASAP update of a host-based Sensor for Oracle on a *nix host, see
           the DbProtect Administrator’s Guide.

To install a host‐based Sensor for DB2 on a *nix host running AIX 5.2 (64‐bit) Technol‐
ogy Level 5 and up (or AIX 5.3 Technology Level 5 for Sensors prior to version 3.3):
1.Login as a user that will run the Sensor, i.e., appradar.
Caution! Do not log in as root.

The user (i.e., appradar) must be a member of the same “dba” group as oracle on the 
host.
2. Download or copy the host‐based Sensor file to your target database host. The file 
   name is: DbProtect_Sensor_<version number>_aix-ppc-64.tgz.sh for 64‐bit AIX.
3. Install the host‐based Sensor file as follows:
sh "./DbProtect_Sensor_<version number>_aix-ppc-64.tgz.sh" install <installation_dir>


for AIX 5.2 (64‐bit), where <installation_dir> is the directory where you want to 
install the Sensor, e.g. /opt.
If the filename contains spaces, then donʹt forget to quote these spaces in the 
command.

The host‐based Sensor is installed in the "<installation_dir>/ASIappradar/" direc‐
tory.



                            Application Security, Inc.                                                  121
  4. Finally, you must configure your host‐based Sensor for Oracle DDL triggers, 
     and configure your host‐based Sensor for Oracle audit trail to monitor failed 
     logins. For more information, see Appendix E: Working with Oracle DDL Triggers (for Host‐
     Based Sensors for Oracle Installed on *nix Platforms Only) and Appendix J: Configuring Your 
     Oracle Audit Trail in Order to Monitor Logins, respectively.
  If you remove and re‐add a DDL trigger for any reason, you must re‐start the 
  Sensor afterwards. Most DDL rules will not fire until this is done.
  5. Start your Sensor; for more information, see Starting and stopping the Sensors on Win‐
     dows.
  Important: The Sensor uses default port 20000 to receive commands from the Console. This port is
             recommended for most configurations, but you can specify a different port number (1-65535).

             To change the default port number for host-based Sensors installed on a *nix platform, you must
             manually modify the sensor.xml and sensor_original.xml files; for more information,
             see Appendix C: Modifying the Sensor Listener Port Number.

             For more information on required open listen ports, see Networking, Port, and Firewall
             Considerations.


  Host-based Sensor for Oracle (on HP-UX) - installation steps
  You can configure your host‐based Sensor for Oracle (on HP‐UX) to start 
  automatically upon system reboot; for more information, see Appendix R: 
  Configuring Your Host‐Based Sensor (Installed on a *nix Platform) to Start 
  Automatically Upon System Reboot.

  Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle 
  relational database management system (RDBMS) software simultaneously while 
  accessing a single database, thus providing a clustered database. For more 
  information on configuring a host‐based Sensor to monitor databases on an 
  Oracle RAC, see Appendix B: Installing and Configuring a Host‐Based Sensor for 
  Oracle to Monitor Oracle Databases on an Oracle RAC.
  Important: For information on performing an ASAP update of a host-based Sensor for Oracle on *nix host,
             see the DbProtect Administrator’s Guide.

  To install a host‐based Sensor for Oracle on a *nix host running HP‐UX 11i v1 
  (11.11) and greater on the PA‐RISC processor and HP‐UX 11i v2 (11.23) and 
  greater on the Itanium (IA64) processor:


122                       Application Security, Inc.
                       Installing, Starting/Stopping, and Reconfiguring the Sensors




1.Login as a user that will run the Sensor, i.e., appradar.
Caution! Do not log in as root.

The user (i.e., appradar) must be a member of the same “dba” group as oracle on the 
host.




                       Application Security, Inc.                                     123
  2. Download or copy the host‐based Sensor file to your target database host. If 
     you are installing a host‐based Sensor on a *nix host running:
      • HP‐UX 11i v1 (11.11) and greater on the PA‐RISC processor, the name if the 
      file is: DbProtect_Sensor_<version number>_hpux-hppa-64.tgz.sh
      • HP‐UX 11i v2 (11.23) and greater on the Itanium (IA64) processor, the name 
      if the file is: DbProtect_Sensor_<version number>_aix-ia64-64.tgz.sh
  3. Install the host‐based Sensor file as follows:
      •   sh “./DbProtect_Sensor_<version number>_aix-ia64-64.tgz.sh" install <installation_dir>



      for HP‐UX 11i v1 (11.11) and greater on the PA‐RISC processor, where 
      <installation_dir> is the directory where you want to install the Sensor, e.g. 
      /opt.
      •   sh "./DbProtect_Sensor_<version number>_hpux-ia64-64.tgz.sh" install <installation_dir>



      for HP‐UX 11i v2 (11.23) and greater on the Itanium (IA64) processor, where 
      <installation_dir> is the directory where you want to install the Sensor, e.g. 
      /opt.
  If the filename contains spaces, then donʹt forget to quote these spaces in the 
  command.

  The host‐based Sensor is installed in the "<installation_dir>/ASIappradar/" 
  directory.
  4. Finally, you must configure your host‐based Sensor for Oracle DDL triggers, 
     and configure your host‐based Sensor for Oracle audit trail to monitor failed 
     logins. For more information, see Appendix E: Working with Oracle DDL Triggers (for Host‐
     Based Sensors for Oracle Installed on *nix Platforms Only) and Appendix J: Configuring Your 
     Oracle Audit Trail in Order to Monitor Logins, respectively.
  If you remove and re‐add a DDL trigger for any reason, you must re‐start the 
  Sensor afterwards. Most DDL rules will not fire until this is done.
  5. Start your Sensor; for more information, see Starting and stopping the Sensors on Win‐
      dows.




124                        Application Security, Inc.
                            Installing, Starting/Stopping, and Reconfiguring the Sensors




Important: The Sensor uses default port 20000 to receive commands from the Console. This port is
           recommended for most configurations, but you can specify a different port number (1-65535).

           To change the default port number for host-based Sensors installed on a *nix platform, you must
           manually modify the sensor.xml and sensor_original.xml files; for more information, see
           Appendix C: Modifying the Sensor Listener Port Number.

           For more information on required open listen ports, see Networking, Port, and Firewall
           Considerations.


Host-based Sensor for Oracle (on Red Hat Enterprise Linux) -
installation steps
You can configure your host‐based Sensor for Oracle (on Red Hat Enterprise Linux) 
to start automatically upon system reboot; for more information, see Appendix R: 
Configuring Your Host‐Based Sensor (Installed on a *nix Platform) to Start 
Automatically Upon System Reboot.

Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle 
relational database management system (RDBMS) software simultaneously while 
accessing a single database, thus providing a clustered database. For more 
information on configuring a host‐based Sensor to monitor databases on an Oracle 
RAC, see Appendix B: Installing and Configuring a Host‐Based Sensor for Oracle to 
Monitor Oracle Databases on an Oracle RAC.
Important: For information on performing an ASAP update of a host-based Sensor for Oracle on a *nix host, see
           the DbProtect Administrator’s Guide.
Caution! The host-based Sensor installer may display a warning message if you run it on Red Hat
           Enterprise Linux 3 to inform you DB2 is not supported on version 3. You may safely
           ignore this warning.

To install a host‐based Sensor for Oracle on a host running Red Hat Enterprise Linux 
3, 4, or 5 (32‐bit x86 and 64‐bit x64): 
1.Login as a user that will run the Sensor, i.e., appradar.
Caution! Do not log in as root.

The user (i.e., appradar) must be a member of the same “dba” group as oracle on the 
host.



                            Application Security, Inc.                                                   125
  2. Download or copy the host‐based Sensor file to your target database host. The 
     file names are:
      • DbProtect_Sensor_<version number>_Linux32.tgz.sh for Red Hat 
      Enterprise Linux (32‐bit x86)
      • DbProtect_Sensor_<version number>_Linux64.tgz.sh for Red Hat 
      Enterprise Linux (64‐bit x64).
  3. Install the host‐based Sensor file as follows:
      • sh "./DbProtect_Sensor_<version number>_Linux32.tgz.sh" install <installation_dir>

      for Red Hat Enterprise Linux (32‐bit x86), where <installation_dir> is the 
      directory where you want to install the Sensor, e.g. /opt.
      • sh "./DbProtect_Sensor_<version number>_Linux64.tgz.sh" install <installation_dir>

      for Red Hat Enterprise Linux (64‐bit x64), where <installation_dir> is the 
      directory where you want to install the Sensor, e.g. /opt.
  If the filename contains spaces, then donʹt forget to quote these spaces in the 
  command.

  The host‐based Sensor is installed in the "<installation_dir>/ASIappradar/" 
  directory.
  4. Finally, you must configure your host‐based Sensor for Oracle DDL triggers, 
     and configure your host‐based Sensor for Oracle audit trail to monitor failed 
     logins. For more information, see Appendix E: Working with Oracle DDL Triggers (for Host‐
     Based Sensors for Oracle Installed on *nix Platforms Only) and Appendix J: Configuring Your 
     Oracle Audit Trail in Order to Monitor Logins, respectively.
  If you remove and re‐add a DDL trigger for any reason, you must re‐start the 
  Sensor afterwards. Most DDL rules will not fire until this is done.
  5. Start your Sensor; for more information, see Starting and stopping the Sensors on Win‐
      dows.




126                    Application Security, Inc.
                             Installing, Starting/Stopping, and Reconfiguring the Sensors




Important: The Sensor uses default port 20000 to receive commands from the Console. This port is
           recommended for most configurations, but you can specify a different port number (1-65535).

           To change the default port number for host-based Sensors installed on a *nix platform, you must
           manually modify the sensor.xml and sensor_original.xml files; for more information, see
           Appendix C: Modifying the Sensor Listener Port Number.

           For more information on required open listen ports, see Networking, Port, and Firewall
           Considerations.


Host-based Sensor for Oracle (on Windows) - installation steps
Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle 
relational database management system (RDBMS) software simultaneously while 
accessing a single database, thus providing a clustered database. For more 
information on configuring a host‐based Sensor to monitor databases on an Oracle 
RAC, see Appendix B: Installing and Configuring a Host‐Based Sensor for Oracle to 
Monitor Oracle Databases on an Oracle RAC.

Windows‐only Oracle Fail Safe is another type of Oracle cluster. It is a core feature 
included with every Oracle 11gR1, Oracle 10g and Oracle9i license for Microsoft 
Windows 2000 and Microsoft Windows 2003. Oracle Fail Safe is integrated with 
Microsoft Cluster Server to allow you to configure and verify Microsoft Windows 
clusters and to automatically fail over Oracle databases and applications. For more 
information on configuring a host‐based Sensor for Oracle on Windows to monitor 
databases in an Oracle Oracle Fail Safe environment, see Appendix Q: Monitoring 
Oracle Databases in an Oracle Fail Safe Environment: Sensor and Cluster 
Configuration Steps.
Important: To install a host-based Sensor for Oracle, you must be a Windows user with administrative rights on
           the host server.
Hint:      Make sure you install your host‐based Sensor for Oracle (on Windows) in a 
           path that does not include Oracle‐reserved characters such as parentheses. 
           This is an Oracle restriction. For example: C:\Program Files (x86). In a case 
           such as this, you must install the host‐based Sensor for Oracle (on Windows) 
           in another location.




                             Application Security, Inc.                                                    127
  To install a host‐based Sensor for Oracle on Windows:
  1. Locate the setup file on the Application Security, Inc.‐provided CD, or down‐
     load it from the Application Security, Inc. FTP site or website.
  2. Save the file to a convenient location (e.g., c:\temp).
  3. Double click the executable file to display the installation wizard (Welcome 
     page) and begin the Sensor installation.

  The installer indicates which version of the Sensor it will install.




                                        FIGURE: Welcome page


  Click the Install button to display the License Agreement page.




128                  Application Security, Inc.
                      Installing, Starting/Stopping, and Reconfiguring the Sensors




4. The License Agreement page is shown below.




                                       FIGURE: License Agreement page

   • Read the License Agreement.
   • If you accept the terms of the License Agreement, select I accept the terms in 
   the license agreement.
   • Click the Next button to display the Choose Destination Location page.




                      Application Security, Inc.                                     129
  5. The Destination Folder page is shown below.




                                        FIGURE: Destination Folder page

      •   Choose the location of the Sensor installation directory. You can click the:
           ‐Change... button to choose a directory manually
           ‐Next button to choose the default location. (The default location is: 
           c:\AppSecInc\Sensor\). 
      •   Click the Next button to display the Sensor Type page.




130                     Application Security, Inc.
                     Installing, Starting/Stopping, and Reconfiguring the Sensors




6. The Sensor Type page is shown below.




                                          FIGURE: Sensor Type page


Select Host‐based Sensor and click the Next button to display the Server Port page.
You can reconfigure an installed Sensor at anytime using the DbProtect Sensor 
Configuration tool or the command line; for more information, see Reconfiguring a 
Sensor (installed on Windows) using the DbProtect Sensor Configuration tool or the 
command line.




                     Application Security, Inc.                                     131
  7. The Server Port page is shown below.




                                        FIGURE: Server Port page

      • Specify which port number the Sensor should use to receive commands from 
      the Console. The default port (20000) is recommended for most 
      configurations, but you can specify a different port number (1-65535). For 
      more information on required open listen ports, see Networking, Port, and 
      Firewall Considerations.
      • You must click the Test Port button to test the port information. If the 
      connection is successful, a green checkmark icon appears, and the Next button 
      is illuminated.
      • Click the Next button to display the Service Log On Credentials page.




132                  Application Security, Inc.
                             Installing, Starting/Stopping, and Reconfiguring the Sensors




8. The Sensor Service Logon Details page is shown below.




                                          FIGURE: Sensor Service Logon Details page

    •   Specify a database user login and password.
Important: If you want to specify a non-local user username and password for the Sensor to run under, you must
           do so in this step.

    You can select:
         ‐Run service as Local System, if you want to use the ʺlocal systemʺ account, 
         which has full access rights and privileges on the host computer.
         ‐Run service as: to specify a domain user login and password.
Important: The Sensor logs in to the monitored database, and the Sensor service runs, under this user profile.
           This profile must be a Windows user with administrator rights. Also, the account name specified must
           have the "log on as service" permission set in the Local Security Policy of the server (for more
           information, see your Windows help). If you select Run service as:, then you must enter a valid domain
           name\user name and password.
    •   Click the Next button to display the Install DbProtect Sensor page.




                             Application Security, Inc.                                                     133
  9. The Install DbProtect Sensor page is shown below.




                                    FIGURE: Install DbProtect Sensor page

      • If want to review or change any settings you can click the Back button.
      • Click the Install button. When the installation finishes, a Sensor installation 
      success page appears.




134                   Application Security, Inc.
                      Installing, Starting/Stopping, and Reconfiguring the Sensors




10.The Sensor installation success page is shown below.




                                    FIGURE: Sensor installation success page

   • Review the installation details at the bottom of the page.
   • Click the Finish button to close the installer.
11.A congratulations pop‐up appears.




                                    FIGURE: Sensor installation success page

Click the OK button to close the congratulations pop‐up. DbProtect allows you to 
switch a host‐based Sensor to a network‐based Sensor, or vice‐versa, without having 
to uninstall the Sensor, then re‐install/reconfigure it. There are two ways to 
accomplish this. The first is using the DbProtect Sensor Configuration tool; for more 
information, see Reconfiguring a Sensor (installed on Windows) using the DbProtect 
Sensor Configuration tool. The second is using the command line; for more 




                      Application Security, Inc.                                     135
  information, see Reconfiguring a Sensor (installed on Windows) using a 
  command line.




136                 Application Security, Inc.
                            Installing, Starting/Stopping, and Reconfiguring the Sensors




Network-based Sensor for Sybase, Oracle, and DB2 - installation
steps
Caution! Network-based Sensors only run on the Windows OS, but the databases they monitor do
           not need to be running on Windows.
Important: To install the network-based Sensor, you must have administrative privileges on Windows. To run the
           network-based Sensor, you must have administrative and “run as a service" privileges on Windows.

To install a network‐based Sensor for DB2, Oracle, or Sybase:
1. Locate the setup file on the Application Security, Inc.‐provided CD, or download it 
   from the Application Security, Inc. FTP site or website.
2. Save the file to a convenient location (e.g., c:\temp).
3. Double click the executable file to display the installation wizard (Welcome page) 
   and begin the Sensor installation.

The installer indicates which version of the Sensor it will install.




                                                  FIGURE: Welcome page


Click the Install button to display the License Agreement page.




                            Application Security, Inc.                                                    137
  4. The License Agreement page is shown below.




                                     FIGURE: License Agreement page

      • Read the License Agreement.
      • If you accept the terms of the License Agreement, select I accept the terms 
      in the license agreement.
      • Click the Next button to display the Choose Destination Location page.




138                  Application Security, Inc.
                      Installing, Starting/Stopping, and Reconfiguring the Sensors




5. The Destination Folder page is shown below.




                                        FIGURE: Destination Folder page

   • Choose the location of the Sensor installation directory. You can click the:
      ‐Change... button to choose a directory manually
      ‐Next button to choose the default location. (The default location is: 
      c:\AppSecInc\Sensor\). 
   • Click the Next button to display the Sensor Type page.




                      Application Security, Inc.                                     139
  6. The Sensor Type page is shown below.




                                      FIGURE: Sensor Type page


  Select Network‐based Sensor and click the Next button to display the Server Port 
  page.
  You can reconfigure an installed Windows‐based Sensor at anytime using the 
  DbProtect Sensor Configuration tool or the command line; for more information, 
  see Reconfiguring a Sensor (installed on Windows) using the DbProtect Sensor 
  Configuration tool or the command line.




140                 Application Security, Inc.
                     Installing, Starting/Stopping, and Reconfiguring the Sensors




7. The Server Port page is shown below.




                                          FIGURE: Server Port page

   • Specify which port number the Sensor should use to receive commands from 
   the Console. The default port (20000) is recommended for most configurations, 
   but you can specify a different port number (1-65535). For more information on 
   required open listen ports, see Networking, Port, and Firewall Considerations.
   • You must click the Test Port button to test the port information. If the 
   connection is successful, a green checkmark icon appears, and the Next button is 
   illuminated.
   • Click the Next button to display the Service Log On Credentials page.




                     Application Security, Inc.                                     141
  8. The Sensor Service Logon Details page is shown below.




                                          FIGURE: Sensor Service Logon Details page

      •   Specify a database user login and password.
  Important: If you want to specify a non-local user username and password for the Sensor to run under, you
             must do so in this step.

      You can select:
           ‐Run service as Local System, if you want to use the ʺlocal systemʺ 
           account, which has full access rights and privileges on the host computer.
           ‐Run service as: to specify a domain user login and password.
  Important: The Sensor logs in to the monitored database, and the Sensor service runs, under this user
             profile. This profile must be a Windows user with administrator rights. Also, the account name
             specified must have the "log on as service" permission set in the Local Security Policy of the
             server (for more information, see your Windows help). If you select Run service as:, then you must
             enter a valid domain name\user name and password.
      •   Click the Next button to display the Install DbProtect Sensor page.




142                        Application Security, Inc.
                       Installing, Starting/Stopping, and Reconfiguring the Sensors




9. The Install DbProtect Sensor page is shown below.




                                      FIGURE: Install DbProtect Sensor page

   • If want to review or change any settings you can click the Back button.
   • Click the Install button. When the installation finishes, a Sensor installation 
   success page appears.




                       Application Security, Inc.                                       143
  10.The Sensor installation success page is shown below.




                                  FIGURE: Sensor installation success page

      •Review the installation details at the bottom of the page.
      •Click the Finish button to close the installer.
  11.A congratulations pop‐up appears.




                                  FIGURE: Sensor installation success page

  12.Click the OK button to close the congratulations pop‐up.
  DbProtect allows you to switch a network‐based Sensor to a host‐based Sensor, or 
  vice‐versa, without having to uninstall the Sensor, then re‐install/reconfigure it. 
  There are two ways to accomplish this. The first is using the DbProtect Sensor 
  Configuration tool; for more information, see Reconfiguring a Sensor (installed 
  on Windows) using the DbProtect Sensor Configuration tool. The second is using 




144                  Application Security, Inc.
                          Installing, Starting/Stopping, and Reconfiguring the Sensors




the command line; for more information, see Reconfiguring a Sensor (installed on 
Windows) using a command line.
Starting and stopping the Sensors on Windows

There are four DbProtect services:
     •   DbProtect   Message Collector
     •   DbProtect   Console
     •   DbProtect   Scan Engine
     •   DbProtect   Sensor

You only need to start the DbProtect Sensor service in order for DbProtect to collect 
data from Sensors, and for you to connect to DbProtect. These services are configured 
to start whenever Windows starts.

There are several ways to start and stop the services on Windows.

Starting a Sensor from the command line:

To start a Sensor from the command line: 
1. Choose Start > Run to display the Run dialog box.
2. Enter cmd.exe in the Open field.
3. Click the OK button to display a command window.
4. Enter the following to start the service:
C:\> net start DbProtect_Sensor

The following messages display:
The DbProtect Sensor service is starting.
The DbProtect Sensor service was started successfully.

Stopping a Sensor from the command line:

To stop a Sensor from the command line:
1.   Choose Start > Run to display the Run dialog box.


                          Application Security, Inc.                                     145
  2. Enter cmd.exe in the Open field.
  3. Click the OK button to display a command window.




146                Application Security, Inc.
                          Installing, Starting/Stopping, and Reconfiguring the Sensors




4. Enter the following to stop the service:
C:\> net stop ServiceName

where ServiceName is one of the following:
     •   DbProtect   Message Collector
     •   DbProtect   Console
     •   DbProtect   Scan Engine
     •   DbProtect   Sensor

The following messages display:
The ServiceName service is stopping.
The ServiceName service was stopped successfully.

Starting a Sensor from the Control Panel:

To start a Sensor from the Control Panel: 
1. Choose Start > Control Panel to display the Control Panel dialog box.
2. Double click the Administrative Tools icon to display the Administrative Tools 
   dialog box.
3. Double click the Services icon to display the Services dialog box.
4. Highlight any of the following services:
     •   DbProtect   Message Collector
     •   DbProtect   Console
     •   DbProtect   Scan Engine
     •   DbProtect   Sensor
5. Click the Start link to display the Service Control pop‐up. The service starts. The 
   Status column in the Services dialog box should read Started.

Stopping a Sensor from the Control Panel:

To stop a Sensor from the Control Panel: 
1.   Choose Start > Control Panel to display the Control Panel dialog box.



                          Application Security, Inc.                                     147
  2. Double click the Administrative Tools icon to display the Administrative 
     Tools dialog box.
  3. Double click the Services icon to display the Services dialog box.
  4. Highlight any of the following services:
       •   DbProtect   Message Collector
       •   DbProtect   Console
       •   DbProtect   Scan Engine
       •   DbProtect   Sensor
  5. Click the Stop link to display the Service Control pop‐up. The service stops. 
     The Status column in the Services dialog box should be blank.
  Starting and Stopping the Sensors on *nix Platforms

  To start and stop the Sensors on a *nix platform: 
  1. To start a host‐based Sensor on a *nix platform, do the following:
      • Log in as the DbProtect Sensor user you created during the installation 
      process (appradar, for example).
      • Once you are successfully authenticated as this user, go to the /util 
      directory where you installed the host‐based Sensor (for example:
      <sensor installation path>/opt/ASIappradar/sensor/util).
      • Run the command: ./appradar_start
  2. To start a host‐based Sensor on a *nix platform, do the following:
      • Log in as the user you created in during the installation process (appradar, 
      for example).
      • Once you are successfully authenticated as this user, go to the /util 
      directory where you installed the host‐based Sensor (for example:
      <sensor installation path>/opt/ASIappradar/sensor/util).
      • Run the command: ./appradar_stop




148                      Application Security, Inc.
                       Installing, Starting/Stopping, and Reconfiguring the Sensors




Reconfiguring a Sensor (installed on Windows) using the
DbProtect Sensor Configuration tool or the command line

DbProtect allows you to switch a network‐based Sensor to a host‐based Sensor, or 
vice‐versa, without having to uninstall the Sensor, then re‐install/reconfigure it. You 
can accomplish this using the:
   • DbProtect Sensor Configuration tool; for more information, see Reconfiguring 
   a Sensor (installed on Windows) using the DbProtect Sensor Configuration tool
   • command line; for more information, see Reconfiguring a Sensor (installed on 
   Windows) using a command line.

The DbProtect Sensor Configuration tool also allows you to reconfigure additional 
Sensor installation parameters for a Sensor installed on Windows. Specifically, you 
can reconfigure the:
   •   server port number
   •   the Windows user that is used to run the Sensor.

For more information, see Reconfiguring a Sensor (installed on Windows) using the 
DbProtect Sensor Configuration tool.




                       Application Security, Inc.                                     149
  Reconfiguring a Sensor (installed on Windows) using the
  DbProtect Sensor Configuration tool

  To reconfigure a Sensor installed on Windows using the DbProtect Sensor Con‐
  figuration tool:
  1.   Choose Start > All Programs > AppSecInc > Sensor > Configure Sensor to dis‐
       play the DbProtect Sensor Configuration tool.




                                       FIGURE: DbProtect Sensor Configuration tool

  2.   Click the Next button.

       The DbProtect Sensor Configuration tool pages that follow are identical to the Sen‐
       sor installation pages (for Sensor installations on Windows).

       If you want to:
        • switch a network‐based Sensor to a host‐based Sensor, or vice‐versa, see 
        Step 3
        • reconfigure the Sensor installation parameters (i.e., the server port number 
        and/or the Windows user that is used to run the Sensor), see Step 4.




150                         Application Security, Inc.
                             Installing, Starting/Stopping, and Reconfiguring the Sensors




3. The DbProtect Sensor Configuration tool allows you to switch a network‐based Sensor to a 
   host‐based Sensor, or vice‐versa, without having to uninstall the Sensor, then re‐install/reconfigure it.

   If you want to switch a:
    • Network‐based Sensor to a host‐based Sensor, see Host‐based Sensor for DB2 
    (on Windows) ‐ installation steps or Host‐based Sensor for Oracle (on Windows) ‐ 
    installation steps (depending on the database type).
    Step 6 of each (identical) topic explains how to specify the Sensor type, i.e., host‐ 
    or network‐based. If all you want to do is switch the Sensor type, follow the 
    wizard steps until the end. If you want to reconfigure additional Sensor 
    installation parameters (i.e., the server port number and/or the Windows user that 
    is used to run the Sensor), go to the next step, below.
    • Host‐based Sensor to a network‐based Sensor, see Host‐based Sensor for DB2 
    (on Windows) ‐ installation steps or Host‐based Sensor for Oracle (on Windows) ‐ 
    installation steps.
    Step 6 of each (identical) topic explains how to specify the Sensor type, i.e., host‐ 
    or network‐based. If all you want to do is switch the Sensor type, follow the 
    wizard steps until the end. If you want to reconfigure additional Sensor 
    installation parameters (i.e., the server port number and/or the Windows user that 
    is used to run the Sensor), go to the next step, below.
Important: After you switch a network-based Sensor to a host-based Sensor, or vice-versa, you must re-register
           the Sensor using the Console; for more information, see Registering a Sensor in the DbProtect 
          User Guide.
4. The DbProtect Sensor Configuration tool allows you to reconfigure the Sensor 
   installation parameters (i.e., the server port number and/or the Windows user that 
   is used to run the Sensor) of a Sensor installed on Windows.

   Again, the DbProtect Sensor Configuration tool pages are identical to the Sensor 
   installation pages (for Sensor installations on Windows). For more information on 
   reconfiguring the installation parameters of a:
    • Host‐based Sensor for SQL Server (on Windows), see Host‐based Sensor for 
    SQL Server (on Windows) ‐ installation steps.




                             Application Security, Inc.                                                        151
       • Host‐based Sensor for DB2 (on Windows), see Host‐based Sensor for DB2 
       (on Windows) ‐ installation steps. 
       • Host‐based Sensor for Oracle (on Windows), see Host‐based Sensor for 
       Oracle (on Windows) ‐ installation steps.
       • Network‐based Sensor for Sybase, Oracle, and DB2 (on Windows), see 
       Network‐based Sensor for Sybase, Oracle, and DB2 ‐ installation steps.
       In each of these topics, Step 7 explains how to reconfigure the server port 
       number. Step 8 explains how to reconfigure the Windows user that is used to 
       run the Sensor.
  Important: If you reconfigure the server port number, you must re-register the Sensor using the Console; for
             more information, see Registering a Sensor in the DbProtect User Guide. However, if you
             only reconfigure the Windows user that is used to run the Sensor, you do not need to register the
             Sensor.

  Reconfiguring a Sensor (installed on Windows) using a
  command line

  DbProtect allows you to use a command line to switch a network‐based Sensor to 
  a host‐based, or vice‐versa, without having to uninstall the Sensor, then re‐install/
  reconfigure it.

  To reconfigure a Sensor installed on Windows using the command line:
  1. Choose Start > Run to display the Run dialog box.
  2. Enter cmd.exe in the Open field.
  3. Click the OK button to display a command window.
  4. Switch your directory path to: <sensor installation folder>\AppSecInc\
       Sensor\bin
  5. If you want to:
      • switch a network‐based Sensor to a host‐based Sensor, or vice‐versa, see 
      Step 5
      • reconfigure the Sensor server port number for a Sensor installed on 
      Windows, see Step 6.




152                       Application Security, Inc.
                             Installing, Starting/Stopping, and Reconfiguring the Sensors




6. Enter the following command to switch a:
    • host‐based Sensor to a network‐based Sensor: appradar_sensor.exe -z -m
    network-based
    • network‐based Sensor to a host‐based Sensor: appradar_sensor.exe -z -m host-
    based
Important: After you switch a network-based Sensor to a host-based Sensor, or vice-versa, you must re-register
           the Sensor using the Console; for more information, see Registering a Sensor in the DbProtect 
           User Guide.




                             Application Security, Inc.                                                    153
  7. Enter the following command to reconfigure the Sensor server port number for 
     a Sensor installed on Windows:

      appradar_sensor.exe –z –p <new sensor port number>

      For example, if you want to switch the port number to 20001, enter the follow‐
      ing command: 

      appradar_sensor.exe –z –p 20001
  Important: If you reconfigure the server port number, you must re-register the Sensor using the Console; for
             more information, see Registering a Sensor in the DbProtect User Guide.
  Hint:      You can run the command appradar_sensor.exe –h to display a help 
             screen that lists all your command line options.




154                       Application Security, Inc.
Chapter 6               Your Initial DbProtect Login

This section explains how to log in to the DbProtect Console for the first time, and 
how to troubleshoot common login issues.

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

Caution!      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.

To log into the DbProtect Console:
1.   Open Internet Explorer 6.0 or greater with JavaScript enabled, and the screen reso‐
     lution set to a minimum of 1024x768, or;
     Enter https://YourMachineName: InstallPort in the Address line, where:
       YourMachineName is the computer name of your Console machine

       InstallPort is the port number entered during installation.

A Security Alert pop‐up appears, prompting you to accept a security certificate from 
Application Security, Inc. DbProtect uses this certificate to communicate with users 
over a secure channel.
  If you experience difficulty logging into DbProtect and connecting to DbProtect, 
  you may need to troubleshoot the Java Runtime Environment (JRE) security 
  settings on your Internet Explorer 6 or greater web browser. For more information 
  on a workaround, see Troubleshooting the Java Run Time Environment (JRE) 
  Security Settings on Internet Explorer 6 or Troubleshooting the Java Run Time 
  Environment (JRE) Security Settings on Internet Explorer 7.

  Another possible solution is to clear your Java cache. For more information, see 
  Clearing Your Java Cache.
  2. Click the OK button to display the DbProtect Console login page.




                                  FIGURE: DbProtect Console login page

  3. Enter your login credentials:
      • In the Username field, enter your DbProtect user name. Use any of the 
      following formats:
        -username: local user
        -<computername>\username
        -<netbios domain name>\username




153                 Application Security, Inc.
                      Logging In to the Console




        -<dns domain name>\username
        -username@<dns domain name>
   • 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. DbPro‐
tect then uses the Windows Authentication subsystem to verify the credentials.

Hint:    You can check the Remember settings on this computer checkbox to store 
         your Username:, Password: and Domain: login values. You can click the 
         Rest button to reset the entered Username:, Password: and Domain: login 
         values.

4. Click the Login button to display the DbProtect Console. For more information on 
   navigating the DbProtect Console, see Global Navigation in DbProtect in the DbPro‐
   tect User Guide.




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

Logging Into the DbProtect Console Using SSO

Starting with version 6.1, DbProtect allows you to use Windows authentication to log 
into the DbProtect Console using a login mechanism known as single sign‐on (SSO).


                      Application Security, Inc.                                 154
  SSO capability only works on Microsoft Windows systems.

  If Windows authentication is properly configured, you can log into the DbProtect 
  Console using Internet Explorer 6.0 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 environ‐
  ment. 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 con‐
  figuration 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 6.0 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.




155                    Application Security, Inc.
                      DbProtect Console Login Troubleshooting




A Security Alert pop‐up appears,, prompting you to accept a security certificate from 
Application Security, Inc. DbProtect uses this certificate to communicate with users 
over a secure channel.

Caution!   If an “access denied” pop‐up appears, prompting you to enter your 
           credentials, this means you don’t have access to the DbProtect system, 
           even though you’re 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.




DbProtect Console Login Troubleshooting
After you have installed DbProtect, your first login attempt may require some trou‐
bleshooting.

Troubleshooting the Java Run Time Environment (JRE) Security
Settings on Internet Explorer 6

If you have difficulty logging on to the DbProtect Console, you may need to trouble‐
shoot the Java Runtime Environment (JRE) security settings on your Internet 
Explorer (6 or greater) web browser.




                      Application Security, Inc.                                  156
  If your web browser is IE 6, Active X controls and “enable third‐party browser 
  extensions” security settings may not be enabled on your IE 6 browser. If this is 
  the case, you will encounter an error message you attempt to authenticate, and 
  you can’t log in to the DbProtect Console.
  The following security settings should be the default values in your IE 6 web 
  browser. You should only change the settings if you are having difficulty logging 
  into the DbProtect Console.

  To enable proper Active X controls and “enable third‐party browser extensions” 
  security settings on IE 6, do the following:
  1.   Launch IE 6.
  2.   Do the following to display the Security Settings dialog box:
        • Choose: Tools > Internet Options. 
        • Click the Security tab.
        • Click the Custom Level button.
  3.   Set the following security settings to Enable or Prompt:
        • Download signed ActiveX controls
        • Run ActiveX controls and plug‐ins.
  4.   Click the OK button.
  5.   Click the Advanced tab.

  The Security Settings dialog box appears.




157                    Application Security, Inc.
                      DbProtect Console Login Troubleshooting




                            FIGURE: Internet Explorer Advanced Settings dialog box

6. Check Enable Third‐party browser extensions (requires restart).
7. Click the OK button.
8. Close and re‐launch IE 6.

Try to log back into the DbProtect Console. If you continue to experience trouble, 
contact Application Security, Inc. Customer Support at support@appsecinc.com.

Troubleshooting the Java Run Time Environment (JRE) Security
Settings on Internet Explorer 7

If your web browser is IE 7, JRE 1.6 may be disabled and/or multiple JREs may be 
enabled on your client (i.e., the location from which your IE 7 browser is running). 
JRE 1.6 must be enabled in order for you to connect to the DbProtect Console. If JRE 
1.6 is disabled, or if multiple JREs of different versions are enabled on your client, 
then you will encounter an error message when you attempt to authenticate, and you 
can’t log in to the DbProtect Console.

To ensure JRE 1.6 is enabled, and to temporarily disable multiple JREs on your client 
machine (using IE 7), do the following:


                      Application Security, Inc.                                     158
  1. Launch IE 7.
  2. Do the following to display the Settings dialog box:
      • Choose: Tools > Internet Options. 
      • Click the Advanced tab.
  3. Scroll down to the Java (Sun) portion of the dialog box and verify the follow‐
     ing:
      • JRE 1.6 is enabled (i.e., the box must be checked)
      • multiple JRE installations are listed.

  JRE 1.6 must be enabled in order for you to connect to the DbProtect Console. If it 
  is not, check the JRE 1.6 box.

  If JRE 1.6 is enabled, and other JRE versions are also enabled, then you must tem‐
  porarily disable them by un‐checking the boxes.
  4. Click the Apply button.
  5. Click the OK button.
  6. Close and re‐launch IE 7.
  Try to log back into the DbProtect Console. If you continue to experience trouble, contact Applica‐
  tion Security, Inc. Customer Support at support@appsecinc.com.


  Clearing Your Java Cache

  If you are having difficulty logging into the DbProtect Console, you may need to 
  clear your Java cache. Application Security, Inc. also recommends you clear your 
  Java cache after an upgrade. The Java cache does not get automatically cleared 
  following a reboot.

  To clear your Java cache:
  1.   Choose Start > Control Panel to display the Control Panel.




159                     Application Security, Inc.
                             DbProtect Console Login Troubleshooting




2. Double click the Java icon to display the Java Control Panel dialog box.
3. With the default General tab selected, click the Settings... button (in the Tempo‐
   rary Internet Files section of the dialog box) to display the Temporary Files Set‐
   tings dialog box.
4. Click the Delete Files... button to clear your Java cache.

Close your web browser and attempt to log into the DbProtect Console again.

Adding the DbProtect URL to Your List of Trusted Intranet Sites In
Internet Explorer

In order for single sign‐on (SSO) to function properly, you may need to configure 
Internet Explorer by adding the DbProtect URL to your list of trusted intranet sites.
The following steps explain how to configure Internet Explorer 7. Steps may vary 
slightly for other browser versions.

In Internet Explorer, do the following:
1.   Choose Tools > Internet Options to display the Internet Options dialog box.
2.   Select the Security tab.
3.   Select Local Intranet from the list of zone sites (at the top of the Internet Options 
     dialog box).
4.   Click the Sites button to display a Local intranet pop‐up.
5.   Click the Advanced button to display a second Local intranet pop‐up.
6.   Add https://<dbprotecturl> to the Add this website to the zone: field, where 
     <dbprotecturl> is the DbProtect Console URL; for more information, see Logging 
     Into the DbProtect Console Using SSO.
7. Click the Add button to add DbProtect to your list of trusted local intranet sites.
8. Click the Close button to close the second Local intranet pop‐up.
9. Click the Close button to close the first Local intranet pop‐up.
10.Click the Apply button on the Internet Options dialog box to apply your changes.
11.Click the OK button to close the Internet Options dialog box.




                             Application Security, Inc.                                160
161   Application Security, Inc.
Chapter 7                Uninstalling the DbProtect Components

This chapter explains how to uninstall the following DbProtect components: the Con‐
sole, Sensors, and Scan Engines.

Uninstalling the DbProtect Suite 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. This topic consists of the following sub‐topics:
     •   Before You Uninstall the DbProtect Suite Components
     •   Uninstalling the DbProtect Suite Components from the Start Menu.

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 back‐
       ing up your back‐end database, see the DbProtect Administrator’s Guide.

  Uninstalling the DbProtect Suite Components from the Start
  Menu

  To uninstall the DbProtect suite components from the Start Menu: 
  1. Choose Start > AppSecInc > DbProtect > Uninstall DbProtect to display the 
     uninstallation wizard.
  2. Follow the prompts. The order of the uninstallation process is the exact oppo‐
     site of the DbProtect suite component installation process (for more informa‐
     tion, see Installing the DbProtect Suite Components).
  Caution! The DbProtect suite component uninstallation process does not delete your back-
             end database.
  3. A message informs you when the uninstallation is complete. Click the Finish 
     button.

  Uninstalling and Unregistering a Sensor
  This section provides uninstallation and unregistration (including forced unregis‐
  tration) steps for a Sensor.

  Uninstallation vs. unregistration

  DbProtect Audit and Threat Management allows you to uninstall and/or unregis‐
  ter 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).


162                    Application Security, Inc.
                        Uninstalling and Unregistering a Sensor




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 
Unregistering a Sensor.

You can uninstall any host‐based or network‐based sensor (installed on Windows) 
from the Start Menu or the Control Panel.
Uninstalling a Sensor (on Windows) from the Start Menu

To uninstall a sensor (on Windows) from the Start Menu: 
1. Choose Start > AppSecInc > Sensor > Uninstall Sensor to display the uninstalla‐
   tion wizard.
2. Follow the prompts.
3. A message informs you when the uninstallation is complete. Click the Finish but‐
   ton.
Uninstalling a Sensor (on Windows) from the Control Panel

To uninstall a sensor (on Windows) from the Control Panel: 
1.   Choose Start > Control Panel to display the Control Panel.
2.   Double click the Add or Remove Programs icon.
3.   Select Sensor.
4.   Click the Change/Remove button.
5.   Follow the prompts.
6.   A message informs you when the uninstallation is complete. Click the Finish but‐
     ton.

Uninstalling a Host-Based Sensor for Oracle (on a *nix platform)

To uninstall a host‐based sensor for Oracle (on a *nix platform): 




                        Application Security, Inc.                                 163
  1.   If you installed a DDL trigger, use remove.sql (located in <Sensor Install
       Directory>/ASIappradar/sensor/java) to remove it.
  2. If you turned on native auditing for failed logins, do the following (if neces‐
     sary):
      • Modify the audit_trail value in the pfile init.ora file
      • Truncate the dba_audit_session table.
  3. Unregister the host‐based sensor for Oracle; for more information, see Unin‐
     stalling and Unregistering a Sensor.
  4. Stop the host‐based sensor for Oracle; for more information, see Starting and 
     stopping the sensors in the DbProtect User Guide or DbProtect Administrator’s 
     Guide.
  5. Delete the installation directory of the host‐based sensor for Oracle.

  Uninstalling a Host-Based Sensor for DB2 (on a *nix platform)

  To uninstall a host‐based sensor for DB2 (on a *nix platform): 
  1. Unregister the host‐based sensor for DB2; for more information, see Uninstall‐
     ing and Unregistering a Sensor.
  2. Stop the host‐based sensor for Oracle; for more information, see Starting and 
     stopping the Sensors in the DbProtect User Guide or DbProtect Administrator’s 
     Guide.
  3. Delete the installation directory of the host‐based sensor for DB2.

  Unregistering a Sensor

  When you unregister a sensor using the Sensor Manager, the sensor stops send‐
  ing messages and Alerts. Unregistration returns the sensor to its original, uncon‐
  figured installation state ‐‐ but it is not removed.
  An unregistered sensor continues to log events to a notification file 
  (appradar_app.txt located in the sensor’s log directory), but only whether the 
  sensor is “up” or “down”.




164                   Application Security, Inc.
                      Uninstalling and Unregistering a Sensor




You can forcibly unregister a sensor in the rare event it does not respond to an unreg‐
istration request using the Sensor Manager.
Unregistering a Sensor using the Sensor Manager

To unregister a sensor using the Sensor Manager: 
1. Log into the Console and select Audit & Threat Management.
2. Do one of the following to display the Sensor Manager:
    • Click the Sensors ‐ Manage Sensor workflow link on the Home page.
    • Click the Sensors tab from anywhere on the page.




3. Highlight a registered sensor, and click the Unregister button. An unregistration 
   confirmation pop‐up appears.




                                  FIGURE: Unregistration confirmation pop-up


Click the Yes button. DbProtect unregisters your sensor. 
If unregistration is unsuccessful, DbProtect prompts you to let it attempt a forced 
unregistration; for more information, see Forcibly unregistering a Sensor (if 
unregistration using the Sensor Manager fails).




                      Application Security, Inc.                                   165
  Forcibly unregistering a Sensor (if unregistration using the
  Sensor Manager fails)

  You can forcibly unregister a sensor in the rare event it does not respond to an 
  unregistration request using the Sensor Manager.

  To forcibly unregister a sensor: 
  1.   Do the following (in any order):
       • On the Sensor Manager, click the Yes button when you are prompted to 
       forcibly unregister a sensor.
       • Run force_unregister.bat (on Windows) or force_unregister (on *nix 
       platforms) on the sensorʹs host, located by default in the following directories:
           ‐On Windows installations: <Sensor Install Directory>\AppSecInc\
           Sensor\utils
           ‐On *nix installations: <Sensor Install Directory>/ASIappradar/sensor/
           util

  Your sensor is forcibly unregistered.
  You can register the sensor again, if necessary; for more information, see the 
  DbProtect User Guide.

  Uninstalling and Unregistering a Scan Engine
  This section provides uninstallation and unregistration steps for a Scan Engine.

  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.
  You should unregister your Scan Engine before you uninstall it.

  To unregister a Scan Engine: 



166                    Application Security, Inc.
                        Uninstalling and Unregistering a Scan Engine




1. Log into DbProtect and select Vulnerability Management.
2. Click the Scan Engines button 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. The Confirm Unregister pop‐up prompts you to confirm the unregistration. Click 
   the Yes button.

Uninstalling a Scan Engine

You can uninstall an Scan Engine from the Control Panel.
You should unregister an Scan Engine before you uninstall it; for more information, 
see Unregistering a Scan Engine.

To uninstall a Scan Engine: 
1.   Choose Start > Control Panel to display the Control Panel.
2.   Double click the Add or Remove Programs icon.
3.   Select DbProtect Scan Engine.
4.   Click the Change/Remove button.
5.   Follow the prompts.




                        Application Security, Inc.                                167
168   Application Security, Inc.
Chapter 8              Installation Troubleshooting

This chapter provides answers to some troubleshooting questions.

How Do I contact Customer Support?

A: Email support@appsecinc.com; for more information, see What should I do if I’m 
not receiving any Alerts?.

How Can I Watch (or "Tail") Log files?

A: DbProtect provides a tail program if you wish to watch the sensor and DbProtect 
log files. To watch the:
   • sensor log file, on Windows execute the tailSensor.bat file, stored in C:\<Sensor
   installation directory>\util
   • DbProtect log file, execute the tailconsole.bat file, stored in C:\<DbProtect
   Installation Folder>\AppSecInc\DbProtect\GUI\util.


What Happens if I Uninstall the SQL Server Instance a Sensor is
monitoring?

A: The sensor will not receive any new Alerts. You should unregister the sensor and 
then uninstall it. For more information on unregistering a sensor, see the DbProtect 
User Guide. For more information on uninstalling a sensor, see Uninstalling and 
Unregistering a Sensor.
  Alternately, you can reconfigure your sensor to monitor another database 
  instance. For more information on reconfiguring a sensor, see the DbProtect User 
  Guide.

  I uninstalled DbProtect without unregistering my Sensors. What
  can I do so I can register my Sensors again without reinstalling
  them?

  A: Application Security, Inc. 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:\<Sensor installation direc-
  tory>\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.




168                  Application Security, Inc.
How can I find out my SQL Server virtual server name?

A: You can find the SQL_virtual_server_name in the Cluster Administrator, located 
in the clusterʹs Resources folder. To display: right click the SQL Network Name 
Resource, and select Properties. In the dialog box that appears, click the Parameters 
tab. Your SQL_virtual_server_name appears in the Name field.

How can I review the audit events in a log file?

A: The log file (appradar_notifications.txt) is stored in c:\<Sensor installation
directory>\AppSecInc\Sensor\logs. Optionally, you can specify a different target 
location on this page. Audit logs, when configured to go to a file, are in the \logs 
sub‐folder in the sensor installation directory; for more information Installing, Start‐
ing/Stopping, and Reconfiguring the Sensors.

The DbProtect or Sensor service failed to start, and when I look at
the DbProtect or Sensor log file located in the log directory, they
indicate a "bind to port" error. What should I do?

A: Make sure no other application is using the ports you specified during installa‐
tion of the sensor and DbProtect. Restart the service after you’ve shut down any soft‐
ware that is using or blocking the ports.

My Sensor is using a Policy with only the Select from User Table
Rule enabled. I executed a SQL DELETE statement against my
database, and the Select from User Table Rule fired. Why?

A: When SQL Server executes a DELETE statement, its underlying engine first does a 
SELECT statement on the target table before proceeding with the deletion.




                       Application Security, Inc.                                    169
  Are there any firewall issues I should consider?

  A: 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 
  Application Security, Inc. 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. Application Security, Inc. recom‐
  mends you disallow all traffic to that port except from the sensors.

  Sensors listen on port 20000 for HTTPS traffic from DbProtect (unless you config‐
  ure them differently during installation), or you can reconfigure sensor to change 
  the port number; for more information, see Installing, Starting/Stopping, and 
  Reconfiguring the Sensors.

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

  Do I require domain administrator rights after I install a Sensor
  on a Cluster?

  A: No. For more information on installing sensors on a SQL Server Cluster, see 
  Appendix A: Installing/Uninstalling Sensors in a SQL Server Cluster.

  Is a Windows account created when I install a Sensor on SQL
  Server?

  A: No.




170                  Application Security, Inc.
Are any accounts created within SQL Server?

A: No.
I see my Sensor listed as timed out in the Sensor Manager. What
can I do to reactivate my Sensor?

A: When a sensor times out, it means DbProtect is unable to communicate with it. 
Do the following: 
   • The sensor may be under heavy load. Wait two minutes and check again.
   • Determine if the IP address of either DbProtect or the sensor has changed since 
   you registered the sensor. If either one has, change the IP address back to its 
   original value, or, if that’s not possible, unregister and register the sensor. For 
   more information on unregistering a sensor, see the DbProtect Administrator’s 
   Guide. For more information on manually removing a sensor, if necessary, see 
   Uninstalling and Unregistering a Sensor.
   • Use your ping utility to verify your DbProtect machine can communicate with 
   your sensor machine.
   • On the sensor machine, ensure the DbProtect Sensor service is running. If the 
   service was stopped, try starting it again; for more information on starting and 
   stopping DbProtect services, see the DbProtect Administrator’s Guide.
   • Verify that you have correctly configured any firewalls between DbProtect and 
   the sensor; for more information, see Are there any firewall issues I should 
   consider?
   • Make sure the following services are running:

   On the DbProtect Console host:
       -DbProtect Message Collector
       -DbProtect Console
       -DbProtect Scan Engine

   On the sensor host:
       -DbProtect Sensor




                      Application Security, Inc.                                   171
      For more information on starting and stopping DbProtect services, see the 
      DbProtect Administrator’s Guide.
      • Check the dbprotect.log file for errors; for more information, see Appendix 
      H: DbProtect Log Files.
      • Email support@appsecinc.com; for more information, see What should I do if 
      I’m not receiving any Alerts?

  What should I do if the following error message appears: “Error
  Occurred. The DbProtect database is not available at the
  moment. Please retry your request later.”?

  A: Make sure the database instance that DbProtect uses (i.e., MSSQL) is running, 
  and make sure the database credentials you specified during installation are cor‐
  rect. 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.

  Email support@appsecinc.com; for more information, see What should I do if I’m 
  not receiving any Alerts?

  What should I do if I’m not receiving any Alerts?

  A: If you’re not receiving any Alerts, make sure you have:
      • met all of the minimum system requirements, including required patches 
      and permissions; for more information, see Minimum System Requirements.
      • properly installed your sensor; for more information, see Installing, Starting/
      Stopping, and Reconfiguring the Sensors.
      • properly connected to the Console; for more information, see the DbProtect 
      User Guide.
      • no firewall issues that may be blocking communication between DbProtect 
      and your sensors; for more information, see Are there any firewall issues I 
      should consider?




172                  Application Security, Inc.
A: If you are still not receiving any Alerts, here are some Alert considerations:
   • A security Alert is a notification of a monitored security event on the database 
   host or network. DbProtect fires an Alert when the criteria for the Rule in the 
   associated Policy is met (unless an exception or Filter prevents the Alert from 
   firing). The level of a security Alert is either High, Medium, or Low. For more 
   information on Policies, see the DbProtect User Guide.
   • An Informational Alert (also known as an audit) is a record of standard 
   database activity. The level of an Informational Alert can be Info‐1, Info‐2, Info‐3, 
   or Info‐4.
The Alert Manager only displays security Alerts. It does not display Informational 
Alerts. For more information, see the DbProtect User Guide.
   If you want to view your Informational Alerts, must run the Auditing Event 
   Summary Report or create a new report template that includes the Informational 
   risk level. For more information, see the DbProtect User Guide.
The default settings for new report templates do not include Informational Alerts.
   • Alternately, you can view your most recent Informational Alerts using the 
   Dashboard; for more information, see the DbProtect User Guide
   • Informational Alerts may only show up every 15 minutes depending on the 
   configuration.

A: If you are still not receiving any Alerts, here are some sensor considerations:
For network‐based sensors:
   • Make sure you have properly configured your SPAN port; for more 
   information, see Network‐based Sensor for Sybase, Oracle, and DB2 ‐ installation 
   steps.
   • Ensure that your SPAN port is detecting network traffic. Do the following:
       ‐On your sensor machine, double click c:\<Sensor installation
       directory>\bin\net_cfg_test.exe to display the Network Configuration Test 
       Tool. 




                       Application Security, Inc.                                    173
          ‐Use the drop‐down to select the network card that is connected to your 
          SPAN port. The tool should display a list of servers which are either 
          sending or receiving network traffic.
          ‐If this list does not include your database server, confirm you have 
          correctly configured the SPAN port.
      • If you SPAN port is detecting network activity, verify you have properly 
      configured your network‐based sensor. Specifically, did you configure the 
      network‐based sensor with the correct IP address(es) and port(s)?
      • For Oracle, is the network‐based sensor configured with the correct SID and 
      service name?
      For more information, see the DbProtect User Guide.

  For host‐based sensors:
      •   Is the host‐based sensor pointing to the correct database?
      •   Is the database active right now?
      For more information, see the DbProtect User Guide.
      •  Are you specifically not receiving DDL Alerts? Open the appsensor.log. See 
      if it contains something similar to the following error message:

      2010-01-14_20:27:42.743800 [error] (67636144) [TcpServer::open] Error
      opening TCP server port (icp_server.cpp:57))

      If so, this means the IPC port is already in use.

  A: If you are still not receiving any Alerts, here are some Policy considerations:
      • What Policy did you deploy?
      • Will the deployed Policy fire Alerts based on the database events you want 
      to monitor?
      • Edit the deployed Policy. Change a rule to display a common, Informational 
      Alert event (i.e., Info‐1, Info‐2, Info‐3, or Info‐4) as a Low event, i.e., an event 
      that will trigger a Low security Alert and display in the Alert Manager; for 



174                    Application Security, Inc.
   more information, see for more information, see the DbProtect User Guide.

   Then, go to the Alert Manager to see if Low security alert appears; for more 
   information, see the DbProtect User Guide.

A: If you are still not receiving any Alerts, here are some SSL‐related considerations:
   • Is the time the same on the DbProtect and the sensor machines? Time zone 
   differences are acceptable as long as both machines represent the same point in 
   time (within a few minutes).
   • Has the IP address or hostname of the DbProtect or the sensor machine changed 
   recently? If so, un‐register and re‐register the sensor. You may need to forcibly 
   unregister the sensor.

A: Finally, if you are still not receiving any Alerts, contact Application Security, Inc. 
Customer Support.

Execute the collectinfo.bat files on both your DbProtect and sensor machines.

On your DbProtect machine, you must execute two separate collectinfo.bat files 
(i.e., one for the MessageCollector service, and one for the GUI). These col-
lectinfo.bat files are located in the following folders:

   • c:\<Sensor installation directory>\util
   • c:\<DbProtect Installation Folder>\DbProtect\MessageCollector\util

Executing these .bat files creates a .zip file in each folder, i.e., one for the Message-
Collector service, and one for the GUI.

Caution! The GUI and MessageCollector.zip files are both named
         AppsecIncConsole.zip. Re-name one before sending to Application Security, Inc.
         Customer support.

On your sensor machine, execute the collectinfo.bat files located here: C:\<DbPro-
tect Installation Folder>\DbProtect\GUI\util. Executing this .bat file creates a 
.zip file (one for each sensor). This .zip file contains configuration and log files 
which allow Application Security, Inc. Customer Support to troubleshoot your issue.


                       Application Security, Inc.                                     175
  Attach all three generated .zip files (i.e., two from your DbProtect machine and 
  one from your sensor server) to an email, and send to support@appsecinc.com for 
  analysis.

  Why am I displaying a blank page on the DbProtect Console UI?

  A: You must enable Javascript on your web browser.
  I’m having trouble establishing a connection between the
  Console and my Sensor installed on Microsoft Windows 2008

  If you’re having trouble establishing a connection between the Console and a sen‐
  sor 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.




176                 Application Security, Inc.
                      Appendix A: Installing/Uninstalling Sensors in a SQL Server Cluster




Chapter 9:   Appendices

Appendix A: Installing/Uninstalling Sensors in a
SQL Server Cluster
This appendix explains how to configure sensors in a clustered environment.
DbProtect allows you to build one (or multiple) database instances within one (or 
multiple) virtual servers. For more information, see Installing Sensors in a SQL 
Server Cluster (single instance) and Installing DbProtect in a SQL Server Cluster 
(Sensors installed on multiple instances), respectively.

Assumptions

This appendix assumes you:
   • have a strong working knowledge of implementation and administration of 
   Windows and SQL Server Clustering
   • have a Windows Cluster configured with SQL Server in a Cluster Group
   • are logged in as a user with both domain and SQL Server administrative 
   privileges
   • your shared drive (referred to as X:, in this appendix) is currently located in the 
   same Resource Group as the Virtual SQL Server instance your sensor will monitor 
   (applies to single instance installations only)
   • all necessary Cluster resources are currently online, and you have identified the 
   Cluster’s Active Node (applies to single instance installations only)
   • are working with multiple virtual servers, each one containing at least one 
   database instance (applies to multiple instance installations only)




                      Application Security, Inc.                                            176
  Working with a SQL Server Cluster (Sensors Installed on a
  Single Instance)

  This topic explains how to install/uninstall sensors on a single instance of a SQL 
  Server Cluster.
  SQL Server Cluster Diagram (Sensors Installed on a Single
  Instance)

  The following diagram displays a SQL Server Cluster setup, where the sensor 
  files are installed on a shared drive. The DbProtect Sensor service is installed on 
  each Node.




177                  Application Security, Inc.
                       Appendix A: Installing/Uninstalling Sensors in a SQL Server Cluster




Installing Sensors in a SQL Server Cluster (single instance)

To install a single instance of sensors in a SQL Server Cluster:
1. Open the Cluster Administrator and determine which Node is Active, i.e., the 
   owner of the SQL Server Cluster Resource.
2. Log in to the Active Node.
3. Install a sensor on the shared drive (X:); for more information, see Installing, Start‐
   ing/Stopping, and Reconfiguring the Sensors.
When installing a host‐based sensor for SQL Server, you must install the sensor on 
your shared drive, not in the default location. 

Also, when initializing a host‐based sensor for SQL Server, note whether you select 
Existing domain user or the “Local System” Account. You will need this information 
in Step 7, below.

The sensor files are copied to your shared drive (X:), and a service called DbProtect
Sensor is created, pointing to the DbProtect .exe file on your shared drive (X:).

4. Since the DbProtect Sensor service is only installed on the Active Node (Node A) 
   at this point, you must also install the service on the other Node (Node B) in your 
   Cluster.

Use the Cluster Administrator to change ownership to the Node where you need to 
install the DbProtect Sensor service (i.e., Node B).
5. Log in to the new Active Node (e.g., Node B), i.e., the owner of the resources. 
   Make sure it has access to the shared drive (X:).
6. Open a command prompt and go to the bin directory where you installed the sen‐
   sor in Step 3.
7. Run the following command:

     appradar_sensor -i -S "user" -P "password"

  where ʺuserʺ and ʺpasswordʺ specify the logon account used to run the service.
The local system account does not require a password.


                       Application Security, Inc.                                            178
  Examples:
  appradar_sensor -i -S "".\LocalSystem”

  or
  appradar_sensor -i -S "DomainName\DomainUser" -P "password"
  8. Repeat Steps 4‐7 for other Nodes in the Cluster.
  9. From the Active Node, open the Cluster Administrator and locate the Group 
     with the shared drive and SQL Server resources.
  10.Choose File > New > Resource to display the New Resource dialog box.
  11.Add a new Resource to the same Group to which the shared (X) drive belongs.
      • Enter a name in the Name field, e.g., DbProtect
      • Under Resource Type, select Generic Service.
      • Select a Group type from the drop‐down. The correct Group may (or may 
      not) already display in the Group field as the default selection; it depends on 
      how you configured the cluster and where you installed the sensor. 
      Regardless, you must select the group that contains the shared (X)drive. 
      • Optionally, you can enter a Description.
      • Do not check Run this Resource in a separate Resource monitor.
      • Click the Next button.

  The Possible Owners dialog box appears.
  12.Verify all your Nodes in the Cluster display in the Possible owners: box. All 
     your Nodes must display in this list. If necessary, add a possible owner from 
     the Available Nodes list.

  Click the Next button to display the Dependencies dialog box.
  13.Move the shared drive (X:), the SQL Server, and the virtual IP address from 
     the Available resources: box to the Resource dependencies: box.

  Click the Next button to display the Generic Service Parameters dialog box.
  14.Specify the following parameters:
     • In the Service name: field enter: DbProtect_Sensor




179                  Application Security, Inc.
                     Appendix A: Installing/Uninstalling Sensors in a SQL Server Cluster




   •  Leave the Start parameters: field blank.
   •  Do not check Use Network Name for computer name.
   •  Click the Next button to display the Registry Replication dialog box.
15.Click the Finish button. The Resource (DbProtect, which you named in Step 11, 
   above) appears in the Resource Group in the Cluster Administrator. The Resource 
   is initially Offline (in the State column).
16.Right click your new Resource (DbProtect) and select Bring Online to bring your 
   new Resource online.




                     Application Security, Inc.                                            180
  17.To prevent the DbProtect Resource from causing an entire group to failover, do 
     the following:
      • Open the Cluster Administrator.
      • Right click the Resource.
      • Select Properties.
      • Select the Advanced tab.
      • Uncheck Affect The Group.

  When the DbProtect Resource fails over, it does not impact the other resources in 
  that group. On the other hand, when other resources in the group failover (e.g., 
  the disk or SQL Server), the DbProtect Resource also fails over because other 
  Resources in the group still have the Affect The Group option enabled.
  For more information on how to register a sensor, and on how to configure and 
  deploy a sensor, see the DbProtect User Guide.
  Upgrading Sensors in a SQL Server Cluster (Sensors installed on
  a single instance)
  This topic only applies to single instance SQL Server Cluster installations. For 
  multiple instance installations, see the DbProtect Administrator’s Guide.

  To upgrade sensors in a Cluster:
  1. Go to the Node where you initially ran the installer in Installing Sensors in a 
     SQL Server Cluster (single instance), and ensure this is the Active Node (i.e., 
     Node A).
  2. Take the DbProtect Resource offline. You can:
      • Open the Cluster Administrator.
      • Right click the DbProtect Resource.
      • Select Take Offline.

  Or, you can:
       •   Open the Cluster Administrator.
       •   Highlight the DbProtect Resource.
       •   Choose File > Take Offline.



181                    Application Security, Inc.
                         Appendix A: Installing/Uninstalling Sensors in a SQL Server Cluster




3. Run the sensor installer from Node A (it should automatically detect that it needs 
   to perform an upgrade install rather than a new install). You can also perform an 
   ASAP Update from Node A; for more information on ASAP Updates, see the 
   DbProtect Administrator’s Guide.
4. Bring the DbProtect Resource back online. You can:
    • Open the Cluster Administrator.
    • Right click the DbProtect Resource.
    • Select Bring Online.

Or, you can:
     •   Open the Cluster Administrator.
     •   Highlight the DbProtect Resource.
     •   Choose File > Bring Online.
Uninstalling Sensors in a SQL Server Cluster (Sensors installed on
a single instance)
For multiple instance installations, you must uninstall the sensor on each Node. For 
more information, see Uninstalling the DbProtect Components.

Uninstalling DbProtect in a SQL Server Cluster is somewhat more complex than a 
standard DbProtect uninstallation.
You must perform the uninstallation steps in the order specified, or you will not have 
a “clean slate”.

There are two prerequisites:
     • Node B must start out as the Active Node; if it is not already the Active Node, 
     simulate a failover to create this condition.
     • If you registered/configured the clustered sensor using the UI, you should first 
     unregister it using the UI prior to uninstallation; for more information, see the 
     DbProtect User Guide.

To uninstall DbProtect in a SQL Server Cluster:
1.   Take the DbProtect Resource offline.


                         Application Security, Inc.                                            182
  Steps 9‐16 in Installing Sensors in a SQL Server Cluster (single instance) explain 
  how to create a Resource. You must take this Resource offline prior to uninstalla‐
  tion.

  To take the Resource offline:
      •   Open the Cluster Administrator.
      •   Right click the Resource.
      •   Select Take Offline.

  Or, you can:
      • Open the Cluster Administrator.
      • Highlight the Resource.
      • Choose File > Take Offline.
  2. With the secondary Node (i.e., Node B) the Active Node, delete the DbProtect
     Sensor service from this Node.
      • Open a command prompt on the Node where you installed the sensor 
      manually (i.e., Node B).
      • Go to the bin directory of the shared drive where you installed the sensor in 
      Step 3 of Installing Sensors in a SQL Server Cluster (single instance), e.g., 
      c:\<Sensor installation directory>\bin.
      • Run the following command: appradar_sensor -u.
      • Press <ENTER>.

  The DbProtect Sensor service is uninstalled on the secondary Node.
  3. Delete the DbProtect Resource using the Cluster Administrator.

  To delete the DbProtect Resource:
      •   Open the Cluster Administrator.
      •   Right click the Resource.
      •   Select Delete.

  Or, you can:
      •   Open the Cluster Administrator.


183                   Application Security, Inc.
                       Appendix A: Installing/Uninstalling Sensors in a SQL Server Cluster




   • Highlight the Resource.
   • Choose File > Delete.
4. Make Node A your Active Node.
   • Open the Cluster Administrator.
   • Right click the SQL Server Resource.
   • Select Initiate Failure.

Or, you can: 
   •  Open the Cluster Administrator.
   •  Highlight the Resource.
   •  Choose File > Initiate Failure.
You must perform these steps four times before the simulated failover actually 
occurs.
5. Uninstall the sensor from Node A.
    • Go to the Node where you installed the sensor (i.e., Node A, which is now the 
    Active Node).
    • Uninstall the sensor; for more information, see Uninstalling the DbProtect 
    Components.
6. At this point, the DbProtect Sensor service should no longer be running or pres‐
   ent, and the SQL Server Cluster should be both online and functioning normally. 

Working with a SQL Server Cluster (Sensors installed on multiple
instances)

This topic explains how to install/uninstall sensors on a Cluster consisting of multi‐
ple virtual servers, each with at least one instance of SQL Server. It consists of the fol‐
lowing sub‐topics:
   • SQL Server Cluster diagram (Sensors installed on multiple instances)
   • Installing DbProtect in a SQL Server Cluster (Sensors installed on multiple 
   instances)
   • Upgrading DbProtect in a Cluster (Sensors installed on multiple instances)
   • Uninstalling DbProtect in a SQL Server Cluster (Sensors installed on multiple 
   instances).



                       Application Security, Inc.                                            184
  SQL Server Cluster diagram (Sensors installed on multiple
  instances)

  The following diagram displays a SQL Server Cluster setup, where the sensor is 
  installed on multiple Cluster Nodes.




185                 Application Security, Inc.
                      Appendix A: Installing/Uninstalling Sensors in a SQL Server Cluster




Installing DbProtect in a SQL Server Cluster (Sensors installed on
multiple instances)

DbProtect allows you to build multiple database instances within one (or multiple) 
virtual servers.

To install sensors on a Cluster consisting of multiple virtual servers, each with at 
least one instance of SQL Server: 
1. Install a sensor on each Node in your SQL Server Cluster. For more information, 
   see the Installing, Starting/Stopping, and Reconfiguring the Sensors.
2. In a multiple instance installation, you must register each sensor using the Nodeʹs 
   hostname or IP address, not the virtual host or IP address. 

Example: Using the diagram in SQL Server Cluster Diagram (Sensors Installed on a 
Single Instance) as an example, register one sensor as IP address 192.168.0.1 (Node 
A), and the other sensor as IP address 192.168.0.2 (Node B).

For more information on registering a sensor, see Registering a Sensor in the DbProtect 
User Guide.
3. When you install multiple instances of DbProtect in a SQL Server Cluster, you 
   must configure and deploy each sensor.
For more information on configuring a sensor, see the DbProtect User Guide.

DbProtect does not allow you to use the same database instance alias twice, so you 
must use aliases like:
     • MySQLServerInstance1_Node1 and MySQLServerInstance2_Node1 on the first 
     sensor
     • MySQLServerInstance1_Node2 and MySQLServerInstance2_Node2 on the second 
   sensor
Alerts will appear as if they come from a different database instance if your primary 
Node fails over to the secondary Node.




                      Application Security, Inc.                                            186
  Upgrading DbProtect in a Cluster (Sensors installed on multiple
  instances)

  For more information on multiple instance upgrades, see the DbProtect Adminis‐
  trator’s Guide.
  Uninstalling DbProtect in a SQL Server Cluster (Sensors
  installed on multiple instances)

  For multiple instance installations, you must uninstall the sensor on each Node. 
  For more information, see Uninstalling and Unregistering a Sensor.

  Appendix B: Installing and Configuring a Host-
  Based Sensor for Oracle to Monitor Oracle
  Databases on an Oracle RAC
  Oracle Real Application Clusters (RAC) allows multiple computers to run Ora‐
  cle relational database management system (RDBMS) software simultaneously 
  while accessing a single database, thus providing a clustered database. In a non‐
  RAC Oracle database, by contrast, a single instance accesses a single database.

  In order to configure a host‐based sensor to monitor databases on an Oracle RAC, 
  do the following:
  1.   Install a host‐based sensor for Oracle on each node in your Oracle RAC. For 
       more information, go to the appropriate operating system‐dependent topic:
        • Host‐based Sensor for Oracle (on Solaris) ‐ installation steps
        • Host‐based Sensor for Oracle (on AIX) ‐ installation steps
        • Host‐based Sensor for Oracle (on HP‐UX) ‐ installation steps
        • Host‐based Sensor for Oracle (on Red Hat Enterprise Linux) ‐ installation 
        steps
        • Host‐based Sensor for Oracle (on Windows) ‐ installation steps.




187                    Application Security, Inc.
                        Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Ora-




2. In the DbProtect Console, register each host‐based sensor for Oracle you installed 
   in Step 1. If you installed your host‐based sensor for Oracle on:
    • Windows, see Configuring a host‐based Sensor to monitor Oracle SIDs and services 
    and deploying the configuration information (when Sensor is installed on Windows) in 
    the DbProtect User Guide for more information
    • any supported *nix operating system (i.e., Solaris, AIX, HP‐UX, or Red Hat 
    Enterprise Linux), see Configuring a host‐based Sensor to monitor Oracle SIDs and 
    services and deploying the configuration information (when Sensor is installed on a *nix‐
    based operating system) in the DbProtect User Guide for more information.




                        Application Security, Inc.                                                      188
  3. In the DbProtect Console, configure an instance for each host‐based Sensor for 
     Oracle you registered in Step 2. Make sure your Instance Alias is:
      • unique for each registered host‐based Sensor for Oracle
      • is easily identifiable for the database you are monitoring
      • easily identifies the node where the Sensor is installed (e.g., Oracle RAC 
      Node 1, Oracle RAC Node 2, etc.).

  If you installed your host‐based Sensor for Oracle on:
      • Windows, see Configuring a host‐based Sensor to monitor Oracle SIDs and 
      services and deploying the configuration information (when Sensor is installed on 
      Windows) in the DbProtect User Guide for more information
      • any supported *nix operating system (i.e., Solaris, AIX, HP‐UX, or Red Hat 
      Enterprise Linux), see Configuring a host‐based Sensor to monitor Oracle SIDs and 
      services and deploying the configuration information (when Sensor is installed on a 
      *nix‐based operating system) in the DbProtect User Guide for more information.
  4. When configuring each instance, also ensure you deploy the exact same Policy 
     for each host‐based Sensor for Oracle (otherwise, you may get inconsistent 
     results for the Alerts you are expecting to see).

  Again, if you installed your host‐based Sensor for Oracle on:
      • Windows, see Configuring a host‐based Sensor to monitor Oracle SIDs and 
      services and deploying the configuration information (when Sensor is installed on 
      Windows) in the DbProtect User Guide for more information
      • any supported *nix operating system (i.e., Solaris, AIX, HP‐UX, or Red Hat 
      Enterprise Linux), see Configuring a host‐based Sensor to monitor Oracle SIDs and 
      services and deploying the configuration information (when Sensor is installed on a 
      *nix‐based operating system) in the DbProtect User Guide for more information.




189                   Application Security, Inc.
                       Appendix C: Modifying the Sensor Listener Port Number




Appendix C: Modifying the Sensor Listener Port
Number
Host‐based and network‐based Sensors listen on port 20000 for HTTPS traffic from 
DbProtect (e.g., reconfiguration or status requests) unless you configure them differ‐
ently during installation, or you change the port number using a utility option of the 
appradar_sensor executable.

As explained in Appendix P: Monitoring Multiple Instances on a DB2 Server, one 
reason you may want to change the port number used by DbProtect Sensor is because 
you want to monitor multiple Sensor instances on server. To do so, you must install 
one host‐based Sensor for DB2 for each instance you want to monitor. You must then 
modify each host‐based Sensor for DB2 installation and to assign a unique port num‐
ber.

To modify a Sensor listen port number:
1. Open a command prompt and go to the directory where you installed the Sensor, 
   e.g., <Sensor installation directory>.
2. Stop the DbProtect Sensor by running one of the following commands: 
   bin\appradar_sensor –k (on Microsoft Windows), or util/appradar_stop (on any 
   *nix platform)

     Change the port and optionally the logging level by running the following com‐
     mand: bin/appradar_sensor –z –p <port number> -m <sensor type> -L <log-
     ging level>

     Substitute the new port number for <port Number> and host‐based or network‐
     based for <sensor type>: e.g., bin/appradar_sensor –z –p 20020 -m host-based
     -L info




                       Application Security, Inc.                                  190
     Run the command appradar_sensor –h to see a full list of options, arguments, 
     and defaults.
  3. Re‐start the Sensor by running the command bin\appradar_sensor –s (on 
     Microsoft Windows), or util/appradar_start (on any *nix platform)

  Appendix D: 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 com‐
  ponent and describes how they each use the network.

                    Application
      Application                 Type   Port     Encrypted               Direction
                     Protocol

 Sensors
 All Sensors        SOAP          TCP    2000     Over 
                                         0        SSL
 Host‐based         Internal      UDP    7777     No          Database to Sensor, local only.
 Oracle with 
 DDL Triggers 
 Installed
 Scan Engines
 All Scan Engines   SOAP          TCP    2000     Over        Console to Scan Engine
                                         1        SSL
                    SQL                  1433     No          Scan Engine to Database
 Enterprise Services Host




191                  Application Security, Inc.
                       Appendix E: Working with Oracle DDL Triggers (for Host-Based Sensors for Oracle




                    Application
    Application                   Type      Port     Encrypted                    Direction
                     Protocol

DbProtect Suite     HTTP          TCP      2008                   User to Web Server
                                           0
                    SQL                    1433                   Console to Database


                    LDAP                   2038                   All Services to Naming and 
                                           9                      Directory Service, local only
Message Collector
All Message         HTTP          TCP      2008     Over          Sensor to Message Collector
Collectors                                 1        SSL
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 Engine Proxy, 
Proxy                                                             local only




Appendix E: Working with Oracle DDL Triggers (for
Host-Based Sensors for Oracle Installed on *nix
Platforms Only)
DbProtect relies on the use of Oracle DDL triggers to capture traffic that does not 
pass through Oracleʹs SGA memory structures. This appendix explains how to 
upgrade the Oracle DDL triggers on your host‐based Sensors for Oracle (on *nix plat‐
forms only) from a prior Sensor release. It also explains how to specify a schema 
(other than the default SYS) for DDL trigger execution.


                       Application Security, Inc.                                                    192
  This appendix consists of the following topics:
       • Upgrading the Oracle DDL Triggers for Your Host‐Based Sensor for Oracle 
       (From a Prior Sensor Release)
       • Specifying a Schema (Other Than the Default SYS) For DDL Trigger 
       Execution.

  Upgrading the Oracle DDL Triggers for Your Host-Based Sensor
  for Oracle (From a Prior Sensor Release)

  To upgrade the Oracle DDL triggers from a prior host‐based Sensor for Oracle 
  release (on *nix platforms only).
  1. Find the Sensor installation subdirectory util (typically <Sensor installation
     directory>/util).
  2. Run sqlplus from this location and login as sysdba. Remember to set the 
     appropriate ORACLE_HOME and ORACLE_SID values for your environment. If this 
     Sensor is monitoring multiple SIDs, then you will need to perform this 
     sequence multiple times changing the environment variables each time to point 
     to the next SID.




193                  Application Security, Inc.
                           Appendix E: Working with Oracle DDL Triggers (for Host-Based Sensors for Oracle




3. Run the command @remove (or @removeJava.sql if you are upgrading from Sensor 
   version 3.10 or prior), and enter the schema name for the DDL trigger (default: 
   SYS) to remove, update, or disable DDL triggers.

     If you specified a schema in the prior release (other than the default SYS) for DDL 
     trigger execution, supply that schema to these scripts.

     Example:

     @remove

     Enter the schema name for the trigger (default is SYS)

     SYS


Specifying a Schema (Other Than the Default SYS) For DDL Trigger
Execution

To configure the DDL triggers for your host‐based Sensors for Oracle (on *nix plat‐
forms only) to use a schema other than the default SYS, for the following:
1.   Find the Sensor installation subdirectory util (typically <Sensor installation
     directory>/util).
2. Run sqlplus from this location and login as sysdba. Remember to set the appropri‐
   ate ORACLE_HOME and ORACLE_SID values for your environment. If this Sensor is 
   monitoring multiple SIDs and you wish to change the user/schema for more than 
   one SID, then you need to perform this sequence multiple times changing the envi‐
   ronment variables each time to point to the next SID where you want to change the 
   user/schema from the default SYS.
3. Run the command @triggerGrant to grant required permissions to a user/schema 
   (if your DDL trigger resides in a schema other than the default SYS). To do so:
    • run the command @triggerGrant
    • grant the required DDL trigger permissions to another user by entering the 
    user/schema name.
Important: You do not need to run this command if you have wish to use SYS as the schema where you want to
           execute DDL triggers.



                           Application Security, Inc.                                                    194
      Example:
      Below is example of how to use the command @triggerGrant to grant correct 
      permissions to a non‐SYS user/schema named ABC.
      @triggerGrant

      Enter a non‐SYS schema name for the trigger (no default)
      ABC

  4. Re‐start your Sensor; for more information, see the DbProtect Administratorʹs 
     Guide.
  5. Use the DbProtect Console to configure your host‐based Sensor for Oracle (on 
     *nix platforms only) to specify a schema (other than the default SYS) for DDL 
     trigger execution. Specifically, enter the name of the schema where the DDL 
     trigger resides in the DDL Trigger Name Schema field of the Sensor Manager 
     page for each SID you want to have an user/schema other than the default SYS.

     For more information, see Configuring a host‐based Sensor to monitor Oracle SIDs 
     and services and deploying the configuration information (when Sensor is installed on 
     a *nix‐based operating system) in the DbProtect Userʹs Guide.
  6. Deploy the Sensor configuration.

  Appendix F: Modifying the "Log On As" User for
  the DbProtect Sensor and DbProtect Message
  Collector Services
  In this appendix:
      •   What is the ʺLog On Asʺ User?
      •   Modifying the Windows Authentication LocalSystem Account.




195                   Application Security, Inc.
                        Appendix F: Modifying the "Log On As" User for the DbProtect Sensor and DbProtect




What is the "Log On As" User?

When you install DbProtect (see Installing the DbProtect Components), 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.

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 the Browse button to 
      display the Select User pop‐up and locate a valid user) \
      • password for the specified user.
7.   Click the Apply button.

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




                        Application Security, Inc.                                                    196
  Appendix G: DB2 Administrative Client Driver
  Installation
  To download and install DB2 client drivers:
  1. Do one of the following to download and install a DB2 client driver:
      • Contact your system administrator, who can provide the DB2 installation 
      CD containing the client drivers.
      • Visit the IBM website (http://www.ibm.com/support/all_download_
      drivers.html) and search for an appropriate driver.
      • As a final alternative, you can download an evaluation version of DB2 from 
      the IBM website, and install the client drivers which come with the installation 
      package. For more information, see http://www.ibm.com/software/data/db2/.
  2. Locate the downloaded client driver on your hard drive (a .zip file), and install 
     using the wizard.

  Appendix H: DbProtect Log Files
  During normal installation of DbProtect suite components, log files are generated 
  and placed in a directory, typically C:\Program Files\AppSecInc\Logs. Appli‐
  cation Security, Inc. Customer Support will ask you to send these files if you con‐
  tact them for assistance.

 Caution!      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 Application Security, 
               Inc. Customer Support professionals.


  DbProtect Log Files

  DbProtect log files come in two categories:
       •   Normal Operations Console Log Files



197                     Application Security, Inc.
                      Appendix H: DbProtect Log Files




  •   DbProtect Installation and Upgrade Log Files
Normal Operations Console Log Files

         Log file:                         Description:                    Location:

dbprotect.log           This is the main application log that is    \Program Files\
                        written to during system usage.             AppSecInc\
                                                                    DbProtect\GUI\
                        Log entries are in the following            logs\
                        format:
                        Sat 01 Jan 23:59:59
                        [ThreadIdentifer] LEVEL Component 
                        – Log Message
                        where the date and time are 
                        presented first, followed by the 
                        DbProtect thread identifier, the level 
                        of the log message (which will be 
                        either INFO, WARN or ERROR), the 
                        DbProtect Audit and Threat 
                        Management component and then 
                        the log message.
                        Each log message entry can span 
                        multiple lines.
gui_wrapper.log         Log for the component that manages 
                        the service life cycle of the DbProtect
                        service.




                      Application Security, Inc.                                       198
            Log file:                         Description:                     Location:

      catalina*.log           Application logs for the Tomcat           \Program
                              engine used by DbProtect.                 Files\AppSecInc\
                                                                        DbProtect\GUI\
                                                                        tomcat\logs\
                                                                        and
                                                                        \Program
                                                                        Files\AppSecInc\
                                                                        DbProtect\Message
                                                                        Collector\tomcat\
                                                                        logs\

      messagecollector_w      Log for the component that manages        \Program Files\
      rapper.log              the service life cycle of the Message     AppSecInc\
                                                                        DbProtect\Message
                              Collector service.
                                                                        Collector\logs\
      messagecollector.l      This is a log file for DbProtect. It 
      og                      tracks the error entries for the Alert‐
                              collecting component of DbProtect.




199                     Application Security, Inc.
                       Appendix H: DbProtect Log Files




DbProtect Installation and Upgrade Log Files

The following DbProtect log files are related to installation and upgrade. Once instal‐
lation 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


Sensor Log Files

The section of the appendix explains:
   •   Archiving
   •   Normal Operations Sensor Log Files
   •   Replay Log Files
Archiving

Log files automatically archive themselves when they reach a certain size, e.g. 100 
MB. For example, when a log file named appsensor.log reaches its limit, the file is 
renamed appsensor.log.1 and a new appsensor.log file is started.

When appsensor.log again reaches its limit, appsensor.log.1 is renamed appsen-
sor.log.2, appsensor.log is renamed appsensor.log.1, a new appsensor.log is 




                       Application Security, Inc.                                  200
  started, and so on. Each type of log listed below has a different file size limit at 
  which archiving occurs, and each has a different maximum number of archives.




201                  Application Security, Inc.
                   Appendix H: DbProtect Log Files




Normal Operations Sensor Log Files

      Log file:                         Description:                              Location:

appsensor.log         Sensor application log (created                      \Program Files\
                      during normal operations).                           AppSecInc\Sensor
                                                                           \logs\
                      This file generally contains 
                      warnings and errors, and at the 
                      default Warning level the file size 
                      grows slowly. However, you can 
                      configure this file to include also 
                      debug messages for 
                      troubleshooting, if the AppSecInc 
                      Support Team asks you to set the 
                      level to Debug or Development. In 
                      this case, the file size grows rapidly.
                      Note:This file “rolls over” at 100MB and does so a
                           maximum of three times.

sga-segments.log      A log file created by host‐based                     <install directory>/
                      Sensors for Oracle installed on *nix                 ASIappradar/sensor/
                                                                           logs
                      platforms (monitoring one or more 
                      Oracle instances). This log file 
                      describes shared memory segments 
                      in use by Oracle. The host‐based 
                      Sensor requires this information so 
                      it may attach to those same shared 
                      memory segments in order to read 
                      database traffic. It extracts shared 
                      memory information by using an 
                      Oracle function which writes SGA 
                      information to a trace file. This 
                      occurs only when you start or re‐
                      configure the Sensor.




                   Application Security, Inc.                                                 202
  Replay Log Files

  Also in the logs directory are Sensor log files related to “store‐&‐forward”, i.e., 
  AppSecInc’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’s 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 DbPro‐
  tect becomes available.
  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).




203                   Application Security, Inc.
                        Appendix H: DbProtect Log Files




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.
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 Set-
tings\<user>\Local Settings\Temp

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

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 DbProtect Version 
Compatibility Matrix, and Determining the Current Version of Installed DbProtect 
Applications.




                        Application Security, Inc.                                 204
  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%>\AppSecInc\AppDetective\logs\
  Hint:    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\<UserName>\Local
           Settings\Application Data\AppSecInc\AppDetective\logs\. On 
           Windows 2008: 
           C:\Users\<UserName>\AppData\Local\AppSecInc\AppDetective\logs\


  If the Scan Engine runs as a LocalSystem account, <UserName> 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\AppSecInc\ScanEngine\logs or 
      C:\Program Files\AppSecInc\adse\logs

  The name of the Scan Engine application log file is: adscanengine.exe.<PID>.log 
  (e.g., adscanengine.exe.1508.log).
  Key Configuration and Log Files

  Sometimes it may be necessary for Support personnel to investigate a problem in 
  more detail. In order to help us in this process, it is beneficial to collect the follow‐
  ing files/directories with key information.
  <DbProtect Installation Root>/Reporting/media/c8/logs
  <DbProtect Installation Root>/Reporting/media/c8/configuration/
  cogstartup.xml
  <DbProtect Installation Root>/GUI/logs
  <DbProtect Installation Root>/GUI/tomcat/conf/wrapper.conf
  <DbProtect Installation Root>/GUI/tomcat/conf/Catalina/localhost




205                   Application Security, Inc.
                       Appendix I: Using App DSN, the Repair ODBC Utility




<DbProtect Installation Root>/GUI/tomcat/logs

In addition to these, it is also useful to record how the DbProtect Console and Analyt‐
ics services are run. To verify this, do the following:
     • Choose Start > Control Panel > Administrative Tools > Services.
     • Locate the services DbProtect Console, DbProtect Analytics, and Cognos 8.
     • Right‐click the service name and select Properties to display the Properties 
     dialog box.
     • Click the Log On tab.

Record the current selection for Local System Account, or the account specified 
under This account.

Appendix I: Using App DSN, the Repair ODBC
Utility
App DNN is a built‐in Repair OBDC (Open Database Connectivity) utility that 
allows you to synch the database where your Scan Engine results are stored with the 
DbProtect Data Repository component.

App DNN also allows you to change the type of authentication DbProtect Vulnerabil‐
ity Management. uses to authenticate to the database server (i.e., from Windows 
authentication to SQL Server authentication ‐‐ or vice‐versa).

To use App DSN:
1.   Choose Start > Programs > AppSecInc > AppDetective Scan Engine > AppDSN to 
     display the App DSN utility.




                       Application Security, Inc.                                      206
                                               FIGURE: App DSN utility


  Use the Server drop‐down to select the SQL Server 2005 instance where the Scan 
  Engine stores its results, or enter the SQL Server 2005 instance name.
  Important: This must be the same database DbProtect Vulnerability Management uses.
  Hint:     Click the Locate instances... button to search for/display all SQL Server 
            instances on your network.
  2. Select to authenticate to the database server using: Windows Authentication 
     (strongly recommended) or SQL Server Authentication. 

  If you select: 
      • Windows Authentication, then the DbProtect Scan Engine service uses the 
      login/password credentials supplied in the Sensor installation section of the 
      DbProtect Installation Guide. If you want to change or verify these values, you 
      must run services.msc
      • SQL Server Authentication, then you must enter a SQL Server 
      authentication Login Name: and Password:




207                      Application Security, Inc.
                         Appendix J: Configuring Your Oracle Audit Trail in Order to Monitor Logins




3. Click the OK button.

The Repair ODBC utility changes the database server the Scan Engine uses to store 
its results, and/or changes the type of authentication DbProtect Vulnerability Man‐
agement uses to authenticate to the database server.

Appendix J: Configuring Your Oracle Audit Trail in
Order to Monitor Logins
You can configure your Oracle audit trail settings in order for your host‐based Sensor 
for Oracle to monitor logins. Specifically, the following DbProtect Rules can monitor 
failed and successful logins:
     •   “Login attempt – successful”
     •   “Failed Login”
     •   “Password guessing”
     •   “Password scripted attack”.

To configure your Oracle audit trail settings so your host‐based Sensor for Oracle can 
monitor logins, you must set the Oracle audit trail of the database to db so that it logs 
the logins (failed and successful) to the dba_audit_session table.
Because this step is optional, you only need to complete these steps for SIDs that you 
want to monitor for logins. You should complete these steps for each SID that resides 
on a server, assuming the host‐based Sensor is going to monitor these SIDs.

You can complete the following steps for each Oracle database instance that your 
host‐based Sensor for Oracle is configured to monitor (assuming you want to moni‐
tor logins).

To configure your host‐Oracle audit trail to enable your host‐based Sensor for Oracle 
to monitor logins: 
1.   Using an Oracle client such as sqlplus, set the audit trail to db:

alter system set audit_trail='db' scope=spfile;



                         Application Security, Inc.                                                   208
  shutdown
  startup
  2. Enable session auditing:

  audit session;

  If your host‐based Sensor for Oracle is already running, you need to re‐start it; for 
  more information, see the DbProtect Administrator’s Guide.

  Appendix K: Required Client Drivers for Audits
  DB2 client driver installation

  To perform an Audit on a DB2 server, you must install the DB2 administrative cli‐
  ent. If you do not have these drivers and privileges, DbProtect Vulnerability Man‐
  agement cannot access tables that are critical for information gathering.

  If you are already a DB2 user, and you have the administrative client installed, 
  you do not need to reinstall the client drivers. You only need your login name and 
  password.

  In this help topic:
      •   Supported and non‐supported client configurations
      •   Downloading and installing the DB2 client drivers.
  Supported and non-supported client configurations

  DB2 version 7 client local connections to a DB2 version 8 server are not supported. 
  For example, you cannot use a DB2 version 7 client to catalog a DB2 version 8 
  instance on the same machine as a local node.

  A detailed matrix on the DB2 website describes the standard and gateway config‐
  uration support for DB2 clients. For more information, see the following: http://
  publib.boulder.ibm.com/infocenter/db2help/index.jsp?topic=/
  com.ibm.db2.udb.doc/start/r0009731.htm.



209                     Application Security, Inc.
                      Appendix K: Required Client Drivers for Audits




Downloading and installing the DB2 client drivers

To download and install DB2 client drivers:
1. The client drivers needed are Administration. Do one of the following:
    • Contact your system administrator, who can provide the DB2 installation CD 
    containing the client drivers.
    • Visit the IBM website (http://www-1.ibm.com/support/
    all_download_drivers.html) and search for an appropriate driver.
    • As a final alternative, you can download an evaluation version of DB2 from the 
    IBM website, and install the client drivers which come with the installation 
    package. For more information, see http://www-3.ibm.com/software/data/db2/.
2. Locate the downloaded client driver on your hard drive (a .zip file).
3. Use a utility like Winzip to unzip the contents into a temporary install directory.
4. Once the files are extracted into the temporary install directory, double click the 
   setup file (setup.exe) to begin the installation process.
5. Click the Next button to choose the DB2 Administration client.
6. Choose Typical.
7. Click the Next button.
8. Choose to install the client in the default location.
9. Click the Next button. A dialog box informs you if there is enough information to 
   complete the installation.
10.Click the Next button.
11.Click the Finish button.
12.Reboot your system.

The DB2 client drivers are now installed. You can now perform Audits on an DB2 
server.

Lotus Notes client driver installation

To perform an Audit of a Lotus Notes‐based Domino Mail Server, you must install 
the Lotus Notes client drivers. If you are already a Lotus Notes user, you do not need 



                      Application Security, Inc.                                   210
  to re‐install the client drivers. You only need to find your .id file, typically 
  located in your C:\Lotus\Notes\Data folder. You must also know your password.

  In this help topic:
      •   Downloading and installing Lotus Notes client software
      •   Starting Lotus Notes for the first time.




211                     Application Security, Inc.
                      Appendix K: Required Client Drivers for Audits




Downloading and installing Lotus Notes client software

To download and install Lotus Notes client software: 
1. Open http://www.lotus.com in your browser.
2. Click the Downloads link.
3. Click the most appropriate Lotus Notes client software download link.
You must register to access the download site.
4. Download the Lotus Notes client software setup file to a convenient location (e.g., 
   C:\temp).
5. Double click the setup file you downloaded from the Lotus website to display the 
   welcome dialog box.
6. Click the Next button to display the license dialog box.
7. Read the License Agreement.
8. If you consent to the License Agreement, press the Yes button to display the name 
   and company dialog box.
9. Enter your name and company name.
10.Click the Next button to display the default installation directory dialog box.
11.Do not change the default installation directories.
12.Click the Next button to display the setup dialog box.
13.Select Typical Setup.
14.Click the Next button to display the Lotus Notes program icons dialog box.
15.Specify the folder where you want to install the Lotus Notes program icons.
16.Lotus Notes is installed.
Starting Lotus Notes for the first time

Your Domino administrator must set up a valid Lotus Notes account for you. He/she 
can provide you with a password as well as an .id file which you must copy to your 
C:\Lotus\Notes\Data folder. Contact your Domino administrator if you are unsure 
about the proper responses to give in the following procedure.




                      Application Security, Inc.                                   212
  To start Lotus Notes for the first time:
  1. Choose Start > Lotus Applications > Lotus Notes to display the set up connec‐
     tions dialog box.
  2. Click the Next button to display the Connect to Domino Server dialog box.
  3. Click the Next button.
  4. Choose your desired method of connecting to the server. If you are in an office, 
     select Connect through a LAN.
  5. Click the Next button to display the Server dialog box.
  6. Enter your server name. (Ask your Domino administrator if you are unsure.)
  7. Click the Next button to display the Browse for Your ID File/Lotus Notes 
     Name dialog box.
  8. Browse for your .id file, or use your Lotus Notes name. (Ask your Domino 
     administrator if you are unsure.)
  9. Click the Next button.
  10.Setup is complete.
  You may or may not want to set up your email, news, directory server, and proxy 
  servers. This is usually done by your Domino administrator. At this point, you 
  have provided enough information to run DbProtect Vulnerability Management 
  for Lotus Domino.

  Sybase Client/Client Driver/.NET Driver Installation

  To perform an Audit on a Sybase ASE data server, you must have the following 
  installed on your workstation:
       •   the Sybase client
       •   a Sybase ASE ODBC driver
       •   a client‐appropriate ADO.NET driver.

  DbProtect uses both the Sybase ASE ODBC and ADO.NET drivers to access your 
  Sybase dataserver. For more information on supported Sybase client versions, see 
  Minimum System Requirements.




213                    Application Security, Inc.
                      Appendix K: Required Client Drivers for Audits




An issue exists in the current Sybase 15.0.2/3 ODBC driver that results in a DbProtect 
connection failure when a Sybase 15.0.2/3 ODBC driver is installed. This is a known 
issue with the Sybase ODBC driver, and not with DbProtect. The current suggested 
workaround is to use an older Sybase ODBC driver, even if you have Sybase 15.0.3 
installed (Sybase 15, for example).




                      Application Security, Inc.                                   214
  This topic consists of the following sub‐topics:
       • Checking If You Have the Proper Sybase ASE ODBC Drivers Installed
       • Checking If You Have the ADO.NET Driver Installed
       • Downloading and Installing Sybase ASE ODBC Drivers and the Sybase Client‐Appropriate .NET Driver.

  Checking If You Have the Proper Sybase ASE ODBC Drivers
  Installed

  To check if you have the proper Sybase ASE ODBC driver installed:
  1.   Choose Start > Settings > Control Panel.
  2.   Double click the Administrative Tools icon.
  3.   Double click the Data Sources (ODBC) icon.
  4.   Click the Drivers tab.
  5.   Scroll down and check if you have either the Sybase ASE ODBC Driver or the 
       Adaptive Server Enterprise ODBC Driver installed (in the Name column)
  6.   If you:
        • have the drivers on your machine, you are ready to use DbProtect’s security 
        Audit feature (assuming you have the proper ADO.NET driver installed, as 
        explained in Checking If You Have the ADO.NET Driver Installed)
        • do not have the driver installed, go to Downloading and Installing Sybase 
        ASE ODBC Drivers and the Sybase Client‐Appropriate .NET Driver.
  Checking If You Have the ADO.NET Driver Installed

  To check if you have the Sybase ADO.NET driver installed: 
  1.   For Sybase 12.5.x and 15.0.x, check the [install dir]\ado.net\dll directory 
       for the dll files listed in Step 3‐4 of Downloading and Installing Sybase ASE 
       ODBC Drivers and the Sybase Client‐Appropriate .NET Driver, respectively.

       For Sybase 15.5, check the [install dir]\DataAccess\ADONET\dll directory 
       for the dll files listed in Step 5 of Downloading and Installing Sybase ASE 
       ODBC Drivers and the Sybase Client‐Appropriate .NET Driver.




215                         Application Security, Inc.
                      Appendix K: Required Client Drivers for Audits




2. If the dlls are there, then the ADO.NET driver is installed and can be used after 
   you copy the dlls to [Common Files] folder (as explained in Downloading and 
   Installing Sybase ASE ODBC Drivers and the Sybase Client‐Appropriate .NET 
   Driver).
3. If the dlls are not present, then you must install the ADO.NET driver before you 
   can Audit a Sybase database.

  In Sybase 12.5.x and 15.0.x the option to install the ADO.NET driver is not selected 
  by default. Therefore you must perform a custom installation and select the driver 
  manually.

   However, in Sybase 15.5, the driver is installed by default. Therefore, you do not 
   need to perform a custom installation, but you still must copy the the dlls to [Com-
   mon Files] folder (as explained in Downloading and Installing Sybase ASE ODBC 
   Drivers and the Sybase Client‐Appropriate .NET Driver).
4. If you:
    • have the drivers on your machine, you are ready to use the DbProtect security 
    Audit feature (assuming you have the proper Sybase ASE ODBC drivers installed, 
    as explained in Checking If You Have the Proper Sybase ASE ODBC Drivers 
    Installed)
    • do not have the driver installed, go to Downloading and Installing Sybase ASE 
    ODBC Drivers and the Sybase Client‐Appropriate .NET Driver.
Downloading and Installing Sybase ASE ODBC Drivers and the
Sybase Client-Appropriate .NET Driver

Refer to the Sybase installation CDs shipped with your database installation to obtain 
the correct Sybase ASE ODBC drivers and ADO.NET drivers.

Alternately, you can obtain the Sybase ASE ODBC drivers in the Sybase Software 
Developer Kit (SDK). This is not a free download. You need to select the following 
drivers in the custom installation option: Sybase Open Client and ASE Data provid‐
ers (ODBC,OLEDB,ADODB.NET). For more information, see http://www.syb‐
ase.com.




                      Application Security, Inc.                                   216
  You can try to download a free copy of the Sybase SDK. However, Application 
  Security, Inc. is not responsible for when (and whether) Sybase is making this 
  available.




217                 Application Security, Inc.
                      Appendix K: Required Client Drivers for Audits




To download and install Sybase ASE ODBC drivers and the Sybase client and a cli‐
ent‐appropriate .NET driver: 
1. Select Custom in your Sybase driver installer and make sure you select ODBC and 
   ADO.NET.
2. To Audit a Sybase database, you must install both the Sybase client and a client‐
   appropriate ADO.NET driver (included in the Sybase client distribution). You 
   must also copy some files to the [Common Files] folder so DbProtect can retrieve 
   them. In all cases, the .NET Framework 1.1 must be installed in order for the driver 
   to work; for more information, see Minimum System Requirements.

   For more infomation on installing the Sybase client‐appropriate .NET driver for:
    • Sybase 12.5, see Step 3
    • Sybase 15, see Step 4
    • Sybase 15.5, see Step 5.
3. Sybase 12.5.

The ADO.NET drivers are not installed by default. You must select the ADO.NET 
drivers manually when you install the 12.5 Sybase client. After the installation, the 
driver files will be located in the following folder: [client install dir]/ado.net/dll

Copy the following files to the <installation folder>/AppSecInc/Common Files 
folder:
     • Sybase.Data.AseClient.dll
     • sybdrvado11.dll
     • sybdrvssl.dll
4. Sybase 15.0.

The ADO.NET drivers are not installed by default. You must select the ADO.NET 
drivers manually when you install the 15.0 Sybase client. After the installation, the 
driver files will be located in the following folder: [client install dir]/ado.net/dll

Copy the following files to the <installation folder>/AppSecInc/Common Files 
folder:
     • Sybase.Data.AseClient.dll


                      Application Security, Inc.                                    218
      •   sybdrvado115.dll
      •   sybdrvkrb.dll
      •   sybdrvssl.dll
      •   sbgse2.dll
      •   policy.1.15.Sybase.Data.AseClient
      •   policy.1.15.Sybase.Data.AseClient.dll




219                  Application Security, Inc.
                      Appendix K: Required Client Drivers for Audits




5. Sybase 15.5.

The ADO.NET drivers are installed by default, including both a .NET v.1.1 driver and 
a .NET v.2.0 driver. There is no need to perform a custom installation.

DbProtect cannot use the ADO.NET v2.0 driver, even if it’s installed.

After the installation, the driver files will be located in the following folder: 
[installdir]\DataAccess\ADONET\dll. However, DbProtect cannot read these files 
in the default location. Therefore, in order to Audit a Sybase database, you must copy 
the following files to the <installation folder>/AppSecInc/Common Files folder:
   •   policy.1.15.Sybase.Data.AseClient
   •   policy.1.15.Sybase.Data.AseClient.dll
   •   sbgse2.dll
   •   Sybase.Data.AseClient.dll
   •   sybcsi_certicom_fips26.dll
   •   sybcsi_core26.dll
   •   sybdrvado115a.dll
   •   sybdrvkrb.dll


DB2 Connect installation

There are certain requirements to Audit IBM DB2 for Mainframe (OS/390 and z/OS). 
You must have DB2 Connect installed on the same computer where the Scan Engine 
is installed. DbProtect does not support the use of a DB2 Connect in a gateway con‐
figuration. All DB2 Connect editions require you to obtain a proper license from IBM.

IBM DB2 OS/390 and z/OS Audits work when using:
   • DB2 Connect Personal Edition 8.1 or 8.2 (any FP), which you can obtain from: 
   http://www-1.ibm.com/software/data/db2/udb/support/downloadv8.html
If you are installing an IBM DB2 v8.x driver, you must install the Microsoft .NET 
Framework 1.1 on your system first. 
    • DB2 Connect Personal Edition 9.1 (any FP), which you can obtain from: http:/
   /www-1.ibm.com/software/data/db2/udb/support/downloadv9.html




                      Application Security, Inc.                                   220
       • DB2 Connect Personal Edition 9.5 (any FP), which you can obtain from: 
       http://www.ibm.com/support/docview.wss?rs=71&uid=swg21287889

  If you have a computer with an IBM Data Server Client installed, you can activate 
  DB2 Connect Personal Edition by registering your DB2 Connect Personal Edition 
  license to that computer.

  Enterprise editions of DB2 Connect (at the versions listed above or higher) should 
  also work, as long as they are not used in a gateway configuration.

  Finally, there are certain requirements when accessing a host database at a lower 
  level than the DB2 Connect installation.
       • For version 8, refer to: http://publib.boulder.ibm.com/infocenter/
       db2luw/v8/topic/com.ibm.db2.udb.doc/conn/r0011119.htm
       • For version 9.1, refer to: http://publib.boulder.ibm.com/infocenter/
       db2luw/v9/topic/com.ibm.db2.udb.uprun.doc/doc/r0011119.htm
       • For version 9.5, refer to: http://publib.boulder.ibm.com/infocenter/
       db2luw/v9r5/topic/com.ibm.db2.luw.qb.dbconn.doc/doc/r0011119.html


  MySQL client driver installation

  To perform an Audit on MySQL, you must have the MySQL ODBC driver 
  installed on your Scan Engine machine. DbProtect uses the MySQL ODBC driver 
  to access your MySQL. For more information on supported versions of MySQL, 
  see Scan Engine System Requirements.

  This topic consists of the following sub‐topics:
       •   Checking If You Have the Proper MySQL ODBC Drivers Installed
       •   Downloading and Installing MySQL ODBC Drivers.
  Checking If You Have the Proper MySQL ODBC Drivers Installed

  To check if you have the proper MySQL ODBC driver installed: 
  1.   Choose Start > Settings > Control Panel.



221                    Application Security, Inc.
                       Appendix L: Required Audit Privileges




2. Double click the Administrative Tools icon.
3. Double click the Data Sources (ODBC) icon.
4. Click the Drivers tab.
5. Scroll down and check if you have either the MySQL ODBC 3.51 Driver or the 
   MySQL ODBC 5.1 Driver installed (in the Name column).
6. If you:
    • have the drivers on your machine, you are ready to use DbProtect’s security 
    Audit feature
    • do not have the driver installed, go to Downloading and Installing MySQL 
    ODBC Drivers.
Downloading and Installing MySQL ODBC Drivers

To download and install MySQL ODBC drivers:
1.   You can download MySQL ODBC drivers here: http://dev.mysql.com/down-
     loads/connector/odbc/5.1.html


Appendix L: Required Audit Privileges
In this appendix:
     •IBM DB2 Audit Privileges
     •IBM DB2 z/OS Audit Privileges
     •Lotus Domino Groupware Audit Privileges
     •Microsoft SQL Server Audit Privileges and User Creation Scripts
     •MySQL Audit Privileges
     •Oracle Audit Privileges and User Creation Script
     •Sybase Audit Privileges
     •Operating System Considerations (for Audits)


IBM DB2 Audit Privileges

For more information on IBM DB2 OS check requirements, see Operating System 
Considerations (for Audits).


                       Application Security, Inc.                                222
  To conduct a full IBM DB2 Audit, you need the following privileges. Make sure 
  the account you are using has rights to use the following tables, views, and func‐
  tions:
      • CONNECT
      • GET DATABASE MANAGER CONFIGURATION & LIST DATABASE DIRECTORY
      •   Service Info (on Windows only)
      •   SYSIBM.SYSCOLAUTH
      •   SYSIBM.SYSINDEXAUTH
      •   SYSIBM.SYSPASSTHRUAUTH
      •   SYSIBM.SCHEMAAUTH
      •   SYSIBM.SYSDBAUTH
      •   SYSIBM.SYSTABAUTH
      •   SYSIBM.SYSFUNCTIONS
      •   SYSIBM.SYSPROCEDURES
      •   SYSIBM.SYSVERSIONS
      •   SYSPROC.SNAPSHOT_DATABASE
  SYSPROC.SNAPSHOT_DATABASE requires the Audit user to have SYSMON authority. 
  Users with SYSADM, SYSCTRL, or SYSMAINT authority automatically inherit SYSMON 
  authority.




223                   Application Security, Inc.
                     Appendix L: Required Audit Privileges




Below is a list of checks within DbProtect Vulnerability Assessment for an IBM DB2 
Audit, and the tables and views they need permission to access in order to function 
properly:
   • CLIENT authentication: GET DATABASE MANAGER CONFIGURATION & LIST
   DATABASE DIRECTORY
   • SERVER authentication: GET DATABASE MANAGER CONFIGURATION & LIST
   DATABASE DIRECTORY
   • DCS authentication: GET DATABASE MANAGER CONFIGURATION & LIST DATABASE
   DIRECTORY
   • Trust All Client: GET DATABASE MANAGER CONFIGURATION & LIST DATABASE
   DIRECTORY
   • Authentication type: GET DATABASE MANAGER CONFIGURATION & LIST
   DATABASE DIRECTORY
   • Service runs as LocalSystem: Service Info (Windows ONLY)
   • Permissions granted to PUBLIC: SYSIBM.SYSCOLAUTH, SYSIBM.SYSINDEXAUTH,
   SYSIBM.SYSPASSTHRUAUTH, SYSIBM.SCHEMAAUTH, SYSIBM.SYSDBAUTH,
   SYSIBM.SYSTABAUTH
   • Permissions granted to user: SYSIBM.SYSCOLAUTH, SYSIBM.SYSINDEXAUTH,
   SYSIBM.SYSPASSTHRUAUTH, SYSIBM.SCHEMAAUTH, SYSIBM.SYSDBAUTH,
   SYSIBM.SYSTABAUTH
   • Permissions grantable: SYSIBM.SYSCOLAUTH, SYSIBM.SYSINDEXAUTH,
   SYSIBM.SYSPASSTHRUAUTH, SYSIBM.SCHEMAAUTH, SYSIBM.SYSDBAUTH,
   SYSIBM.SYSTABAUTH
   • Permissions on system catalog: SYSIBM.SYSDBAUTH, SYSIBM.SYSTABAUTH
   • Permissions to list users: SYSIBM.SYSDBAUTH, SYSIBM.SYSTABAUTH
   • db2ckpwd buffer overflow (Version verify): SYSIBM.SYSVERSIONS
   • Query Compiler DoS (Verify version): SYSIBM.SYSVERSIONS
   • Date/Varchar DoS (Verify version): SYSIBM.SYSVERSIONS
   • Latest FixPak not installed: SYSIBM.SYSVERSIONS
   • Control Center buffer overflow (Verify version): SYSIBM.SYSVERSIONS
   • Excessive DBADM connections

For the Excessive DBADM connections check, the IBM DB2 OS user must have:
   • SELECT or CONTROL privilege on the APPLICATIONS and SNAPAPPL_INFO 
   administrative views



                     Application Security, Inc.                                 224
      • SYSMON, SYSCTRL, SYSMAINT, or SYSADM authority which is required to access 
      snapshot monitor data.

  Some DB2 Audit checks need to differentiate between fixpaks such as 4/4a, 6/6a, 
  etc. These checks require specific permissions. Specifically, the checks affected 
  are:
      • Arbitrary code execution in a federated system (Verify version)
      • Arbitrary code execution when processing connection messages (Verify
      version)
      • Arbitrary file creation in XML Extender functions (Verify version)
      • Buffer overflow in CALL statement (Verify version)
      • Buffer overflow in db2fmp (Verify version)
      • Buffer overflow in generate_distfile procedure (Verify version)
      • Buffer overflow in REC2XML function (Verify version)
      • Buffer overflow in SATADMIN.SATENCRYPT function (Verify version)
      • Buffer overflow in the JDBC listener (Verify version)
      • Buffer overflows in XML Extender functions (Verify version)
      • DoS in string formatting functions (Verify version)
      • Latest FixPak not installed
      • Multiple Buffer overflows in libdb2.so.1 library (Verify version)
      • Multiple critical vulnerabilities in IBM DB2 (Verify version)
      • Multiple DoS vulnerabilities in SQLJRA protocol

  The IBM DB2 OS user must have access to the db2greg command on all Unix plat‐
  forms for the following IBM DB2 LUW checks:
      • Permission on files
      • Setuid bit enabled
      • Setgid bit enabled

  In order for DbProtect Vulnerability Assessment to work properly with any of 
  these checks, you must set special permissions, depending on what version of 




225                  Application Security, Inc.
                       Appendix L: Required Audit Privileges




DB2 is running on your server. The following table explains which permissions are 
required for which versions of DB2:  

              If your server is
                                                        Requirements:
           running DB2 version:

           9.10 or later          SELECT or CONTROL privilege on the 
                                  ENV_INST_INFO administrative view.
                                  OR
                                  SYSADM and/or ATTACH privileges.
                                  AND
                                  EXECUTE privilege on the 
                                  ENV_GET_INST_INFO table function 
                                  (required for IBM DB2 LUW v 8.2.2 and 
                                  later). 
           8.2.2 or later         EXECUTE privilege on the 
                                  ENV_GET_INST_INFO table function.

           8.1.0 or later         SYSADM or ATTACH privileges.

           7                      Registry access or OS access.




                       Application Security, Inc.                               226
  IBM DB2 z/OS Audit Privileges

  This topic consists of the following sub‐topics:
      •   Full IBM DB2 z/OS Audit Requirements
      •   Per Check IBM DB2 z/OS Audit Requirements.
  Full IBM DB2 z/OS Audit Requirements

  You require the following permissions (which SYSADM has by default) in order to 
  conduct a full IBM DB2 z/OS Audit with all checks enabled:
      • SELECT privileges on the following catalog tables:
         -SYSIBM.SYSCOLAUTH
         -SYSIBM.SYSDBAUTH
         -SYSIBM.SYSPACKAUTH
         -SYSIBM.SYSPLANAUTH
         -SYSIBM.SYSROUTINEAUTH
         -SYSIBM.SYSSCHEMAAUTH
         -SYSIBM.SYSTABAUTH
         -SYSIBM.SYSUSERAUTH
         -SYSIBM.GETVARIABLE
      • Permission to call the following function: SYSIBM.GETVARIABLE
      • Permission to call the following stored procedure: SYSPROC.DSNWZP

  Per Check IBM DB2 z/OS Audit Requirements

  To conduct an IBM DB2 z/OS Audit with selected checks enabled, the following 
  permissions are required in a per‐check basis:
      • All checks require permission to call the following function: 
      SYSIBM.GETVARIABLE
      • The following IBM DB2 z/OS Audit checks require permission to call the 
      stored procedure SYSPROC.DSNWZP:
          -Dual logging not enabled
          -Dual archiving not enabled
          -SMF accounting is not set to start automatically
          -Audit Trace is not set to start automatically
          -SMF statistics not set to start automatically
          -Authorization checking disabled



227                   Application Security, Inc.
                     Appendix L: Required Audit Privileges




        -Collection interval for statistics
        -System install administrators and operators
If the SYSPROC.DSNWZP and SYSPROC.ADMIN_DS_LIST stored procedures are not 
enabled, you must enable them and set up the proper environments so they can 
function correctly.




                     Application Security, Inc.                                 228
      • The IBM DB2 z/OS Audit check Connection and sign-on exits requires 
      permission to call the stored procedure SYSPROC.ADMIN_DS_LIST.
      • The following table lists IBM DB2 z/OS Audit checks which must have 
      SELECT privileges on the corresponding IBM DB2 z/OS tables: 


                                                 Corresponding IBM DB2 z/OS tables
                        Check
                                                     requiring SELECT privileges

           Access list of authorization          SYSIBM.SYSTABAUTH
           IDs

           Administrative authorities            SYSIBM.SYSUSERAUTH
           on DB2 Subsystem

           Privileges granted to PUBLIC          SYSIBM.SYSPACKAUTH
           on packages

           Administrative authorities            SYSIBM.SYSDBAUTH
           for DB2 catalog database

           Administrative authorities            SYSIBM.SYSDBAUTH
           over databases

           Privileges granted to PUBLIC          SYSIBM.SYSPLANAUTH
           on plans

           PUBLIC granted                        SYSIBM.SYSUSERAUTH
           Administrative authorities
           on DB2 Subsystem

           Privileges granted to PUBLIC          SYSIBM.SYSCOLAUTH
           on columns

           Privileges granted to PUBLIC          SYSIBM.SYSROUTINEAUTH
           on routines

           • Easily-guessed usernames            SYSIBM.SYSDBAUTH
             and passwords
           • No permission is required
           • Privileges granted to
             PUBLIC on databases




229                 Application Security, Inc.
                      Appendix L: Required Audit Privileges




                                                     Corresponding IBM DB2 z/OS tables
                         Check
                                                         requiring SELECT privileges

           Privileges granted to PUBLIC             SYSIBM.SYSUSERAUTH
           on DB2 subsystem

           Password same as username                SYSIBM.SYSDBAUTH
           for account                              SYSIBM.SYSTABAUTH
                                                    SYSIBM.SYSPLANAUTH
                                                    SYSIBM.SYSCOLAUTH
                                                    SYSIBM.SYSSCHEMAAUTH
                                                    SYSIBM.SYSPACKAUTH
                                                    SYSIBM.SYSROUTINEAUTH
                                                    SYSIBM.SYSUSERAUTH

           Privileges on the DB2                    PSYSTABAUTH
           catalog

           Privileges granted to PUBLIC             SYSIBM.SYSSCHEMAAUTH
           on schemas

           Privileges granted to PUBLIC             SYSTABAUTH
           on DB2 catalog tables

           Privileges granted to PUBLIC             SYSTABAUTH
           on tables

           Administrative authority                 SYSIBM.SYSDBAUTH
           for database granted to
           PUBLIC


Lotus Domino Groupware Audit Privileges
For more information on Lotus Domino OS check requirements, see Operating 
System Considerations (for Audits).

To conduct a full Lotus Domino Groupware Audit, you need the following privi‐
leges. Make sure the account you are using has rights to use the following tables and 
views:
   • Read all databases


                      Application Security, Inc.                                         230
      •   Read decsadm.nsf and all of its documents
      •   Read names.nsf and all of its documents
      •   Execute commands on the server
      •   Read all user documents

  At a document level, DbProtect Vulnerability Assessment checks certain fields, 
  including: $Author, $Readers, RM_MapFrom, $Readers, and fields of type 
  LNRTTYPE_AUTHORS_FIELD.

  DbProtect Vulnerability Assessment also verifies certain Lotus Domino Group‐
  ware properties (for example, if you have attachments and if they are encrypted). 
  If any of the required fields listed above are encrypted and the id does not have 
  access to it, then some of the checks below will not work properly.
  Caution! Despositor access that only has access to read public documents is sufficient to
             run a Lotus Domino Groupware Audit, with the exception of the names.nsf database
             which requires Reader access.

  Besides SHOW commands, the following Lotus Domino Groupware commands are 
  also executed:
      • TELL HTTP SHOW FILE ACCESS
      • SET SECURE

  Below is a list of checks within the DbProtect Vulnerability Assessment for a 
  Lotus Domino Audit, and the tables and views they need permission to access in 
  order to function properly:
      • Anonymous can create documents: Read all databases
      • Anonymous granted Designer or higher access: Read all databases
      • Anonymous user in Authors field: Read all databases
      • Default has Editor or higher access: Read all databases
      • Encrypted field full-text indexed: Read all databases
      • Unspecified user type in ACL: Read all databases
      • DECS password unencrypted: Read decsadm.nsf and all of its
      documents
      • Anonymous ACL missing: Read all databases, Read names.nsf and all
      of its documents




231                    Application Security, Inc.
                Appendix L: Required Audit Privileges




• Access server unrestricted: Read names.nsf and all of its documents
• All people can use monitors: Read names.nsf and all of its documents
• All users can run personal agents: Read names.nsf and all of its
documents
• Anonymous access using HTTPS: Read names.nsf and all of its documents
• Anonymous access using Notes RPC: Read names.nsf and all of its
documents
• Bindsock arbitrary file creation: Read names.nsf and all of its
documents
• CGI directory leak: Read names.nsf and all of its documents
• Check passwords on Notes IDs: Read names.nsf and all of its documents
• Create databases unrestricted: Read names.nsf and all of its documents
• Enumerate groups: Read names.nsf and all of its documents
• Failed access control on file attachments: Read names.nsf and all of
its documents
• iNotes client ActiveX control buffer overflow: Read names.nsf and all
of its documents
• iNotes s_ViewName buffer overflow: Read names.nsf and all of its
documents
• Latest maintenance release not applied: Read names.nsf and all of its
documents
• Long POST request DoS: Read names.nsf and all of its documents
• Maximum number of request headers: Read names.nsf and all of its
documents
• Maximum size of request contents: Read names.nsf and all of its
documents
• Maximum size of request headers: Read names.nsf and all of its
documents
• Maximum URL length: Read names.nsf and all of its documents
• Maximum URL path segments: Read names.nsf and all of its documents
• Non-admins can use monitors: Read names.nsf and all of its documents
• Notes RPC buffer overflow: Read names.nsf and all of its documents
• Notes_ExecDirectory buffer overflow: Read names.nsf and all of its
documents
• Password change interval for user: Read names.nsf and all of its
documents
• PATH buffer overflow: Read names.nsf and all of its documents



                Application Security, Inc.                          232
      • Public keys compared to directory: Read names.nsf and all of its
      documents
      • Restricted agents runlist: Read names.nsf and all of its documents
      • Restricted Java/COM runlist: Read names.nsf and all of its
      documents
      • Saved email not encrypted: Read names.nsf and all of its documents
      • Servlets disabled: Read names.nsf and all of its documents
      • Unrestricted agents runlist: Read names.nsf and all of its
      documents
      • Unrestricted Java/COM runlist: Read names.nsf and all of its
      documents
      • User can create new databases: Read names.nsf and all of its
      documents
      • Administration over HTTP: Read names.nsf and all of its documents,
      Execute a command on the server
      • Anonymous access using HTTP: Read names.nsf and all of its
      documents, Execute a command on the server
      • Anonymous access using IIOP: Read names.nsf and all of its
      documents, Execute a command on the server
      • Anonymous access using IIOPS: Read names.nsf and all of its
      documents, Execute a command on the server
      • Anonymous access using LDAP: Read names.nsf and all of its
      documents, Execute a command on the server
      • Anonymous access using LDAPS: Read names.nsf and all of its
      documents, Execute a command on the server
      • ESMTP buffer overflow: Read names.nsf and all of its documents,
      Execute a command on the server
      • Expired certificates allowed: Read names.nsf and all of its
      documents, Execute a command on the server
      • HTTP authenticate buffer overflow: Read names.nsf and all of its
      documents, Execute a command on the server
      • HTTP database browsing: Read names.nsf and all of its documents,
      Execute a command on the server
      • HTTP logging not enabled: Read names.nsf and all of its documents,
      Execute a command on the server
      • HTTP methods excluded from logging: Read names.nsf and all of its
      documents, Execute a command on the server




233                Application Security, Inc.
                Appendix L: Required Audit Privileges




• HTTP MIME types excluded from logging: Read names.nsf and all of its
documents, Execute a command on the server
• HTTP return codes excluded from logging: Read names.nsf and all of its
documents, Execute a command on the server
• HTTP user agents excluded from logging: Read names.nsf and all of its
documents, Execute a command on the server
• HTTPS allows anonymous access: Read names.nsf and all of its
documents, Execute a command on the server
• Inadequate amgr process logging: Read names.nsf and all of its
documents, Execute a command on the server
• Incomplete POST DoS: Read names.nsf and all of its documents, Execute
a command on the server
• Interface address leak in banner: Read names.nsf and all of its
documents, Execute a command on the server
• LDAP buffer overflow: Read names.nsf and all of its documents, Execute
a command on the server
• LDAP format string: Read names.nsf and all of its documents, Execute a
command on the server
• MS-DOS device web path leak: Read names.nsf and all of its documents,
Execute a command on the server
• Personal agents runlist: Read names.nsf and all of its documents,
Execute a command on the server
• Redirected host/location buffer overflow: Read names.nsf and all of
its documents, Execute a command on the server
• Routing loop DoS (Verify version): Read names.nsf and all of its
documents, Execute a command on the server
• SMTP buffer overflow: Read names.nsf and all of its documents, Execute
a command on the server
• Unencrypted HTTP: Read names.nsf and all of its documents, Execute a
command on the server
• Unencrypted IIOP: Read names.nsf and all of its documents, Execute a
command on the server
• Unencrypted IMAP: Read names.nsf and all of its documents, Execute a
command on the server
• Unencrypted LDAP: Read names.nsf and all of its documents, Execute a
command on the server
• Unencrypted NNTP: Read names.nsf and all of its documents, Execute a
command on the server



                Application Security, Inc.                           234
      • Unencrypted POP3: Read names.nsf and all of its documents, Execute
      a command on the server
      • Web retriever HTTP status buffer overflow: Read names.nsf and all
      of its documents, Execute a command on the server
      • Web Retriever logging: Read names.nsf and all of its documents,
      Execute a command on the server
      • Easily-guessed Internet password: Read all user documents
      • Easily-guessed Notes password: Read all user documents
      • Agent manager debugging not enabled: Execute a command on the
      server
      • Ambiguous webnames allowed: Execute a command on the server
      • Console password not set: Execute a command on the server
      • Inadequate console logging: Execute a command on the server
      • NDS password present: Execute a command on the server
      • NDS userid present: Execute a command on the server
      • Phone line logging not enabled: Execute a command on the server


  Microsoft SQL Server Audit Privileges and User Creation Scripts
  For more information on Microsoft SQL Server OS check requirements, see 
  Operating System Considerations (for Audits).

  This topic consists of the following sub‐topics:
      •   Microsoft SQL Server 2000 and MSDE Audit Privileges
      •   Running the Microsoft SQL Server 2000 User Creation Script
      •   Running the Microsoft SQL Server 2000 with Sysadmin User Creation Script
      •   Microsoft SQL Server 2005 and Microsoft SQL Server 2008 Audit Privileges
      •   Credentials for Microsoft SQL Server Audits
      •   Running the Microsoft SQL Server 2005 and 2008 User Creation Script
      •   Registry Access for Microsoft SQL Server 2000, 2005, and 2008.




235                   Application Security, Inc.
                      Appendix L: Required Audit Privileges




Microsoft SQL Server 2000 and MSDE Audit Privileges

To conduct a full Microsoft SQL Server 2000 or MSDE Audit, you need the follow‐
ing privileges. Make sure the account you are using has rights to use the following 
tables and views: 

                                                                 Privileges
                                   Check
                                                                 Required

                 master.dbo.xp_loginconfig                    EXECUTE

                 master.dbo.xp_regread

                 exec <db
                 name>.dbo.sp_helprotect

                 msdb.dbo.sp_get_sqlagent_pro
                 perties

                 master.dbo.xp_cmdshell

                 @@VERSION                                    SELECT

                 master.dbo.syslogins
                 (MSSQLSysLogins)

                 master.dbo.sysxlogins

                 master.dbo.sysdatabases

                 master.dbo.sysconfigures

                 master.dbo.syscurconfigs

                 master.dbo.syscharsets

                 <db name>.dbo.sysusers

                 <db name>.dbo.sysobjects

                 <db name>.dbo.syscomments




                      Application Security, Inc.                                 236
  In addition, certain Microsoft SQL Server 2000 DISA‐STIG Database Security Con‐
  figuration checks require you to be a member of the sysadmin fixed server role or 
  the db_owner fixed database role on the publication database. The following table 
  provides specific information about which checks require which roles (and why): 

             Microsoft SQL Server                          To run these checks, you
                                             Use:
            2000 DISA-STIG checks:                          must be a member of:

           DBMS                      Replication system    The sysadmin 
           replication               stored procedures.    fixed server role or 
           account                                         the db_owner fixed 
           privileges                                      database role on 
                                                           the publication 
           Replication                                     database.
           snapshot
           folder
           protection
           Database auditing         fn_trace_getinfo      The sysadmin 
           Auditing of               and                   fixed server role.
           Security Events           fn_trace_getevent
                                     info functions.
           Startup Stored
           Procedures

  Below is a list of checks within the DbProtect Vulnerability Assessment for a 
  Microsoft SQL Server 2000 Audit, and the tables and views they need permission 
  to access in order to function properly:
      • Agent jobs privilege escalation: exec <db name>.dbo.sp_helprotect,
      master.dbo.sysdatabases
      • Auditing of failed logins: master.dbo.xp_loginconfig
      • Auditing of successful logins: master.dbo.xp_loginconfig
      • Blank password: master.dbo.sysxlogins
      • Blank password for sa: master.dbo.sysxlogins
      • Blank password for well-known login: master.dbo.sysxlogins
      • BULK INSERT buffer overflow: @@VERSION




237                   Application Security, Inc.
                Appendix L: Required Audit Privileges




• C2 Audit Mode: @@VERSION, master.dbo.sysconfigures,
master.dbo.syscurconfigs
• Case-insensitive sort order: master.dbo.syscharsets,
master.dbo.sysconfigures,master.dbo.syscurconfigs
• Changing mode may leave sa password blank: @@VERSION
• Cleartext password written by installation: @@VERSION,
master.dbo.xp_cmdshell
• Computed Column UDF DoS: @@version
• Database ownership chaining not disabled: sysconfigures,syscurconfigs
• DBCC addextendedproc buffer overflow: @@VERSION
• DBCC BUFFER buffer overflow: @@VERSION
• DBCC CHECKCONSTRAINTS buffer overflow: @@VERSION
• DBCC CLEANTABLE buffer overflow: @@VERSION
• DBCC INDEXDEFRAG buffer overflow: @@VERSION
• DBCC PROCBUF buffer overflow: @@VERSION
• DBCC SHOWCONTIG buffer overflow: @@VERSION
• DBCC SHOWTABLEAFFINITY buffer overflow: @@VERSION
• DBCC UPDATEUSAGE buffer overflow: @@VERSION
• DBMS remote system credential use and access: master.dbo.sysxlogins,
[master].dbo.sysservers
• Default login enabled: @@VERSION, master.dbo.syslogins,
master.dbo.xp_loginconfig
• Direct updates on data dictionary: master.dbo.sysconfigures,
master.dbo.syscurconfigs
• DTS package procedures granted to public: sp_helprotect
• DTS package password publicly viewable: msdb.dbo.sysuser, exec
msdb.dbo.sp_helprotect
• DTS password exposed in properties dialog: @@VERSION
• DTS passwords publicly viewable: <db name>.dbo.sysuser, exec <db
name>.dbo.sp_helprotect, master.dbo.sysdatabases
• Easily-guessed password: @@VERSION
• Easily-guessed password for sa: @@VERSION
• Easily-guessed password for well-known login: @@VERSION
• Encoded password written by installation: @@VERSION,
master.dbo.xp_cmdshell
• Enterprise Manager improperly revokes proxy account: @@VERSION




                Application Security, Inc.                          238
      • Error logs can be overwritten: Registry access
  To learn more about enabling registry access for Microsoft SQL Server 2000, see 
  Registry Access for Microsoft SQL Server 2000, 2005, and 2008.
      • Escalated privileges in heterogeneous joins: @@VERSION
      • Extended stored proc privilege upgrade: exec <db
      name>.dbo.sp_helprotect, master.dbo.sysdatabases
      • Fixed server role granted: master.dbo.syslogins
      • Format string in C runtime DoS: @@VERSION
      • Format string vuln in xp_sprintf: @@VERSION
      • FORMATMESSAGE buffer overflow: @@VERSION
      • Global temporary stored proc exists: sysobjects,sysusers
      • Guest user exists in database: <db name>.dbo.sysuser,
      master.dbo.sysdatabases
      • Hello buffer overflow: @@VERSION
      • Infected with Spida worm: <db name>.dbo.sysobjects,
      master.dbo.sysdatabases, master.dbo.xp_cmdshell
      • Jet running in sandbox Mode: Registry access
  To learn more about enabling registry access for Microsoft SQL Server 2000, see 
  Registry Access for Microsoft SQL Server 2000, 2005, and 2008.
      • Job output file handling: @@VERSION
      • Latest service pack applied: @@VERSION
      • Lumigent Log Explorer buffer overflow: <db name>.dbo.sysobjects,
      master.dbo.sysdatabases
      • Malformed RPC request DoS: @@VERSION
      • Malformed TDS packet header DoS: @@VERSION
      • MDX Query buffer overflow: @@VERSION
      • Objects not owned by dbo: <db name>.dbo.sysobjects,
      master.dbo.sysdatabases, <db name>.dbo.sysuser
      • OLEDB ad hoc queries allowed: Registry access
  To learn more about enabling registry access for Microsoft SQL Server 2000, see 
  Registry Access for Microsoft SQL Server 2000, 2005, and 2008.
      • Orphaned user: @@VERSION, <db name>.dbo.sysuser,
      master.dbo.sysdatabases, master.dbo.syslogins
      • Password same as login name: @@VERSION
      • Permission grantable: exec <db name>.dbo.sp_helprotect,
      master.dbo.sysdatabases



239                 Application Security, Inc.
                Appendix L: Required Audit Privileges




• Permissions granted to public: <db name>.dbo.sp_helprotect
• Permission on mswebtasks: exec <db name>.dbo.sp_helprotect,
master.dbo.sysdatabases
• Permission on registry extended proc: exec <db name>.dbo.sp_helprotect,
master.dbo.sysdatabases
• Permission on sp_MSsetalertinfo: exec <db name>.dbo.sp_helprotect,
master.dbo.sysdatabases
• Permission on sp_MSSetServerProperties: exec <db
name>.dbo.sp_helprotect, master.dbo.sysdatabases
• Permission on sp_readwebtask: exec <db name>.dbo.sp_helprotect,
master.dbo.sysdatabases
• Permission on sp_runwebtask: exec <db name>.dbo.sp_helprotect,
master.dbo.sysdatabases
• Permission on xp_readerrorlog: exec <db name>.dbo.sp_helprotect,
master.dbo.sysdatabases
• Permission to select from syslogins: exec <db name>.dbo.sp_helprotect,
master.dbo.sysdatabases
• Permission to select from system table: <db name>.dbo.sysobjects, exec
<db name>.dbo.sp_helprotect, master.dbo.sysdatabases
• Permissions granted on sp_add_dtspackage: msdb.dbo.sysuser, exec
msdb.dbo.sp_helprotect
• Permissions granted on xp_cmdshell: @@VERSION, exec <db
name>.dbo.sp_helprotect, master.dbo.sysdatabases
• Permissions granted to user: <db name>.dbo.sysuser, exec <db
name>.dbo.sp_helprotect, master.dbo.sysdatabases
• Public can create Agent jobs: exec <db name>.dbo.sp_helprotect,
master.dbo.sysdatabases
• pwdencrypt buffer overflow: @@VERSION
• RAISERROR buffer overflow: @@VERSION
• Registry extended proc not removed: <db name>.dbo.sysobjects,
master.dbo.sysdatabases
• Remote access allowed: master.dbo.sysconfigures,
master.dbo.syscurconfigs
• Remote data source function unchecked buffer: @@VERSION
• Replication password publicly viewable:
xp_regread,sysobjects,@@version,sp_helprotect
• Resolution service DoS: @@VERSION




                Application Security, Inc.                            240
      • Resolution service heap overflow: @@VERSION
      • Resolution service stack overflow: @@VERSION
      • Reusable cached administrator connection: @@VERSION
      • sp_attachsubscription command injection: @@VERSION, <db
      name>.dbo.sysobjects, master.dbo.sysdatabases
      • sp_MScopyscriptfile command injection: <db name>.dbo.sysobjects,
      master.dbo.sysdatabases, @@VERSION
      • SQL Agent password publicly viewable: @@version,
      msdb.dbo.sp_get_sqlagent_properties, sp_helprotect
      • SQL Agent procedures granted to public: sp_helprotect
      • SQLServerAgent password in registry: @@VERSION, <db
      name>.dbo.sysobjects, master.dbo.sysdatabases
      • srv_paraminfo buffer overflow in sp_OACreate: @@VERSION
      • srv_paraminfo buffer overflow in sp_OADestroy: @@VERSION
      • srv_paraminfo buffer overflow in sp_OAGetProperty: @@VERSION
      • srv_paraminfo buffer overflow in sp_OAMethod: @@VERSION
      • srv_paraminfo buffer overflow in sp_OASetProperty: @@VERSION
      • srv_paraminfo buffer overflow in xp_displayparamstmt: @@VERSION
      • srv_paraminfo buffer overflow in xp_execresultset: @@VERSION
      • srv_paraminfo buffer overflow in xp_peekqueue: @@VERSION
      • srv_paraminfo buffer overflow in xp_printstatements: @@VERSION
      • srv_paraminfo buffer overflow in xp_proxiedmetadata: @@VERSION
      • srv_paraminfo buffer overflow in xp_SetSQLSecurity: @@VERSION
      • srv_paraminfo buffer overflow in xp_showcolv: @@VERSION
      • srv_paraminfo buffer overflow in xp_sqlagent_monitor: @@VERSION
      • srv_paraminfo buffer overflow in xp_sqlinventory: @@VERSION
      • srv_paraminfo buffer overflow in xp_updatecolvbm: @@VERSION
      • Standard SQL Server authentication allowed: @@VERSION, <db
      name>.dbo.sysobjects, master.dbo.sysdatabases,
      master.dbo.xp_loginconfig
      • Statement permission granted: master.dbo.sysdatabases, exec <db
      name>.dbo.sp_helprotect
      • SysAdmin only for CmdExec job steps: @@VERSION, <db
      name>.dbo.sysobjects, master.dbo.sysdatabases
      • sysadmin role granted: master.dbo.syslogins




241                Application Security, Inc.
                Appendix L: Required Audit Privileges




• Table to store DTS passwords publicly viewable: <db name>.dbo.sysuser,
master.dbo.sysdatabases, exec <db name>.dbo.sp_helprotect
• Temporary stored procedures bypass permissions: @@VERSION
• UDB broadcast buffer overflow: master.dbo.xp_cmdshell
• Unauthorized object permission grants: <db name>.dbo.sysuser, exec <db
name>.dbo.sp_helprotect, master.dbo.sysdatabases
• Windows account name shown as hostname: @@VERSION,
master.dbo.xp_loginconfig
• XMLHTTP control allows local file access: <db name>.dbo.sysobjects,
master.dbo.sysdatabases, @@VERSION
• xp_cmdshell not removed: <db name>.dbo.sysobjects,
master.dbo.sysdatabases replace for xp_cmdshell not removed/not
disabled: select object_id()
• xp_controlqueueservice buffer overflow: <db name>.dbo.sysobjects,
master.dbo.sysdatabases
• xp_createprivatequeue buffer overflow: @@VERSION, <db
name>.dbo.sysobjects, master.dbo.sysdatabases
• xp_createqueue buffer overflow: @@VERSION, master.dbo.sysdatabases, <db
name>.dbo.sysobjects
• xp_decodequeuecmd buffer overflow: @@VERSION, <db name>.dbo.sysobjects,
master.dbo.sysdatabases
• xp_deleteprivatequeue buffer overflow: @@VERSION, <db
name>.dbo.sysobjects, master.dbo.sysdatabases
• xp_deletequeue buffer overflow: @@VERSION, <db name>.dbo.sysobjects,
master.dbo.sysdatabases
• xp_dirtree buffer overflow: @@VERSION, <db name>.dbo.sysobjects,
master.dbo.sysdatabases
• xp_displayqueuemesgs buffer overflow: @@VERSION,
master.dbo.sysdatabases, <db name>.dbo.sysobjects
• xp_dsninfo buffer overflow: <db name>.dbo.sysobjects, @@VERSION,
master.dbo.sysdatabases
• xp_mergelineages buffer overflow: @@VERSION, master.dbo.sysdatabases,
<db name>.dbo.sysobjects
• xp_oledbinfo buffer overflow: @@VERSION, <db name>.dbo.sysobjects,
master.dbo.sysdatabases
• xp_proxiedmetadata buffer overflow: master.dbo.sysdatabases, <db
name>.dbo.sysobjects, @@VERSION




                Application Security, Inc.                            242
       • xp_readpkfromqueue buffer overflow: @@VERSION, <db
       name>.dbo.sysobjects, master.dbo.sysdatabases
       • xp_readpkfromvarbin buffer overflow: @@VERSION, <db
       name>.dbo.sysobjects, master.dbo.sysdatabases
       • xp_repl_encrypt buffer overflow: @@VERSION, <db
       name>.dbo.sysobjects, master.dbo.sysdatabases
       • xp_resetqueue buffer overflow: @@VERSION, <db name>.dbo.sysobjects,
       master.dbo.sysdatabases
       • xp_sprintf buffer overflow: @@VERSION
       • xp_sqlagent_param buffer overflow: @@VERSION, <db
       name>.dbo.sysobjects, master.dbo.sysdatabases
       • xp_sqlinventory buffer overflow: @@VERSION,
       master.dbo.sysdatabases, <db name>.dbo.sysobjects
       • xp_unpackcab buffer overflow: @@VERSION, <db name>.dbo.sysobjects,
       master.dbo.sysdatabases
       • xstatus backdoor: @@VERSION, master.dbo.sysxlogins

  Running the Microsoft SQL Server 2000 User Creation Script

  Application Security Inc. has written a convenient Microsoft SQL Server 2000 user 
  creation script (CreateUserSQLServer2k.sql) which creates an account with the 
  minimum privileges necessary to perform Audits on a Microsoft SQL 2000 
  instance.

  The contents of the CreateUserSQLServer2k.sql script follow:
  --create login
  use [master]
  EXEC sp_addlogin 'aduser', 'Admin123', 'master'
  GO


  --add user to each database
  EXEC sp_MSforeachdb '
  USE [?]
  DECLARE @isUpdateable sql_variant




243                 Application Security, Inc.
                      Appendix L: Required Audit Privileges




SELECT @isUpdateable = databasePropertyEx(name,''Updateability'') FROM mas-
ter.dbo.sysdatabases where databasePropertyEx(name,''Status'')=''ONLINE''
and name = ''?''


IF @isUpdateable = ''READ_WRITE''
BEGIN
       EXEC sp_adduser ''aduser''
END'
GO


--assign privileges needed for audit
USE [master]
GO
GRANT EXECUTE ON dbo.xp_loginconfig TO [aduser]
GRANT SELECT ON dbo.syslogins TO [aduser]
GRANT SELECT ON dbo.sysxlogins TO [aduser]
GRANT SELECT ON dbo.sysaltfiles TO [aduser]
GRANT SELECT ON dbo.sysdatabases TO [aduser]
GRANT SELECT ON dbo.sysconfigures TO [aduser]
GRANT SELECT ON dbo.syscurconfigs TO [aduser]
GRANT SELECT ON dbo.sysservers TO [aduser]
GRANT SELECT ON dbo.sysmembers TO [aduser]
GRANT SELECT ON dbo.sysprotects TO [aduser]
GRANT SELECT ON dbo.spt_values TO [aduser]
GRANT EXECUTE ON sp_helpreplicationdboption TO [aduser]
GRANT EXECUTE ON sp_helpsrvrolemember TO [aduser]
GRANT EXECUTE ON sp_helprolemember TO [aduser]



                      Application Security, Inc.                       244
  GRANT SELECT ON dbo.sysoledbusers TO [aduser]


  EXEC sp_MSforeachdb '
  DECLARE @isUpdateable sql_variant


  SELECT @isUpdateable = databasePropertyEx(name,''Updateability'') FROM
  master.dbo.sysdatabases where databasePropertyEx(name,''Sta-
  tus'')=''ONLINE'' and name = ''?''


  IF @isUpdateable = ''READ_WRITE''
  BEGIN
            GRANT EXECUTE ON [?].dbo.sp_helprotect TO [aduser]
            GRANT EXECUTE ON [?].dbo.sp_helpuser TO [aduser]
  END
  '


  EXEC sp_MSforeachdb '
  USE [?]


  DECLARE @isUpdateable sql_variant


  SELECT @isUpdateable = databasePropertyEx(name,''Updateability'') FROM
  master.dbo.sysdatabases where databasePropertyEx(name,''Sta-
  tus'')=''ONLINE'' and name = ''?''


  IF @isUpdateable = ''READ_WRITE''
  BEGIN
            GRANT SELECT ON dbo.sysusers TO [aduser]
            GRANT SELECT ON dbo.sysobjects TO [aduser]
            GRANT SELECT ON dbo.syscomments TO [aduser]




245                 Application Security, Inc.
                     Appendix L: Required Audit Privileges




END
'


use [msdb]
GRANT SELECT ON dbo.sysjobs TO [aduser]
GRANT SELECT ON dbo.sysjobhistory TO [aduser]


print 'all done.'

Running the Microsoft SQL Server 2000 with Sysadmin User
Creation Script

Application Security Inc. has written a convenient Microsoft SQL Server 2000 user 
creation script (CreateUserSQLServer2kwithSA.sql) which creates an account with 
the minimum privileges necessary to perform Audits on a Microsoft SQL 2000 
instance, and adds it to the SYSADMIN server role.

The contents of the CreateUserSQLServer2kwithSA.sql script follow:
USE master
GO
EXEC sp_addlogin 'aduser', 'Admin123'
GO
EXEC sp_MSforeachdb '
USE [?]
DECLARE @isUpdateable sql_variant
SELECT @isUpdateable = databasePropertyEx(name,''Updateability'') FROM mas-
ter.dbo.sysdatabases where databasePropertyEx(name,''Status'')=''ONLINE''
and name = ''?''
IF @isUpdateable = ''READ_WRITE''
BEGIN EXEC sp_grantdbaccess ''aduser'', ''aduser''
END'
GO
EXEC sp_addsrvrolemember "aduser", SYSADMIN




                     Application Security, Inc.                                246
  Microsoft SQL Server 2005 and Microsoft SQL Server 2008 Audit
  Privileges
  Important: Application Security Inc. wrote a convenient Microsoft SQL Server 2005 and Microsoft SQL Server
             2008 user creation script (CreateUserSQLServer2k52k8PublicRevoked.sql) that
             creates an account with the minimum privileges necessary to perform an Audit on a Microsoft
             SQL Server instance. If you want to run this script, just make sure whatever account you use to
             conduct your Audit has at least the SELECT privileges listed in the script. For more information,
             see Running the Microsoft SQL Server 2005 and 2008 User Creation Script.

  Any Audit check for Microsoft SQL Server 2005 and Microsoft SQL Server 2008 
  queries the following views:
       •   sys.databases
       •   sys.configurations
       •   sys.server_principals
       •   sys.server_role_members

  In Microsoft SQL Server 2005 and Microsoft SQL Server 2008 the public group can 
  select from these views but, due to metadata visibility concept, DbProtect Vulner‐
  ability Assessment may not return all records. For this reason, each of the checks 
  listed below requires the following permissions in order to retrieve data: VIEW
  DEFINITION, VIEW ANY DEFINITION, and CONTROL SERVER.

  In addition, you must have permission to select from system table: select all
  rows from master.sys.database_permissions, <dbname>.sys.system_objects
  views which implies VIEW DEFINITION on database scope permission.

  For the check Symmetric Keys: encrypting mechanism to work properly, the 
  auditing user should have access to all keys. The user must be a privileged user 
  have been granted access to all the keys. You can use one of the following state‐
  ments to grant access:
  for every database
  GRANT VIEW DEFINITION TO [aduser]

  or
  in master database



247                       Application Security, Inc.
                        Appendix L: Required Audit Privileges




GRANT VIEW ANY DEFINITION TO [aduser]

In addition, certain Microsoft SQL Server 2005 and 2008 DISA‐STIG Database Secu‐
rity Configuration checks require you to be a member of the sysadmin fixed server 
role or the db_owner fixed database role on the publication database. The following 
table provides specific information about which checks require which roles (and 
why): 

           Microsoft SQL Server 205
                                                                To run these checks, you
             and 2008 DISA-STIG                  Use:
                                                                 must be a member of:
                   checks:

           DBMS replication           Replication system        The sysadmin 
           account                    stored procedures.        fixed server role or 
           privileges
                                                                the db_owner fixed 
           Replication                                          database role on 
           snapshot folder                                      the publication 
           protection                                           database

Below is a list of DbProtect Vulnerability Assessment checks used to run a Microsoft 
SQL Server 2005 or and Microsoft SQL Server 2008 Audit, including the tables and 
views they need permission to access in order to function properly:
   • Agent XPs enabled: select from sys.configurations view.
   • Application user access to external objects: select from
   <dbname>.sys.objects, <dbname>.sys.database_permissions.
   • Asymmetric Keys: private key encryption type: select from
   master.dbo.sysdatabases, select from <dbname>.sys.asymmetric_keys, VIEW
   DEFINITION on database scope permission.
   • Auditing of failed logins: master.dbo.xp_loginconfig.
   • Auditing of failed/successful logins: execute xp_loginconfig.
   • Audit trace status: select from fn_trace_getinfo,
   fn_trace_geteventinfo.
   • Blank password checks: select password_hash column of sys.sql_logins
   for all sql logins which implies CONTROL SERVER permission.
   • BUILTIN\Administrators not removed: select all rows from
   sys.server_principals view which implies VIEW ANY DEFINITION permission.



                        Application Security, Inc.                                         248
      • C2 Audit Mode: select from sys.configurations view.
      • CLR objects allowed: select from sys.configurations view.
      • Common criteria compliance disabled: select from sys.configurations
      view.
      • Database job/batch queue monitoring: select from
      master.sys.procedures, select name, job_id columns from
      msdb.dbo.sysjobs and select job_id column from
      msdb.dbo.sysjobhistory.
      • Database Master Key: access control: select from
      master.dbo.sysdatabases, <dbname>.sys.database_principals,
      <dbname>.sys.database_permissions.
      • Database Master Key: encryption password: select from
      master.dbo.sysdatabases,<dbname>.sys.key_encryptions,<dbname>.sys.sym
      metric_keys, VIEW DEFINITION on database scope permission.
      • Database Master Key: is_master_key_encrypted_by_server: select from
      sys.databases.
      • Database Master Key: password storage: select from
      sys.master_key_passwords.
      • Database ownership chaining not disabled: select from
      sys.configurations view.
      • DBA OS privilege assignment: execute sp_helpsrvrolemember.
      • DBMS account password expiration: select from sys.sql_logins.
      • DBMS administration OS accounts: execute sp_helpsrvrolemember.
      • DBMS audit log backups: select from fn_trace_getinfo.
      • DBMS audit record access: select from sys.server_permissions,
      master.dbo.syslogins and master.dbo.sysusers, execute
      sp_helpsrvrolemember.
      • DBMS Password Policy Enforced: execute xp_loginconfig, select from
      sys.sql_logins.
      • DBMS remote system credential use and access: select from
      dbo.sysservers, sys.linked_logins.
      • DBMS services dedicated custom account: Registry access.
      • DBMS software file backups: Registry access.
      • DBMS dedicated software directory and partition: Registry access.
      • DBMS network port, protocol, and services (PPS) configuration:
      Registry access*.




249                Application Security, Inc.
                      Appendix L: Required Audit Privileges




To learn more about enabling registry access for Microsoft SQL Server 2005 and 2008, 
see Registry Access for Microsoft SQL Server 2000, 2005, and 2008.
   • Dedicated data file directories: select from sys.master_files,
   sys.databases, Registry access*.
   • Default password for well-known login: makes connection attempts.
   • Default Trace Disabled: select from sys.configurations view.
   • DTS package password publicly viewable: select all rows from
   msdb.sys.database_permissions, sys.types, sys.all_objects,
   sys.certificates, sys.fulltext_catalogs, sys.routes,
   sys.remote_service_bindings, sys.services, sys.service_contracts,
   sys.service_message_types, sys.xml_schema_collections, sys.assemblies
   views which implies VIEW DEFINITION on database scope permission.
   • DTS package procedures granted to public: select from
   msdb.sys.database_permissions view.
   • DTS procedures granted to PUBLIC: select from
   msdb.sys.database_principals, msdb.sys.database_permissions.
   • Easily-guessed password checks: select password_hash column of
   sys.sql_logins for all sql logins which implies CONTROL SERVER
   permission.
   • Encryption of DBMS sensitive data in transit: Registry access.
   • Error logs can be overwritten: Registry access.
   • Event forwarding not disabled: Registry access.
To learn more about enabling registry access for Microsoft SQL Server 2005 and 2008, 
see Registry Access for Microsoft SQL Server 2000, 2005, and 2008.
   • Fixed server role granted: select all rows from sys.server_principals,
   sys.server_role_members views which implies VIEW ANY DEFINITION
   permission.
   • Global temporary stored proc exists: select from
   tempdb.sys.all_objects.
   • Guest user exists in database: select all rows from sys.databases and
   <dbname>.sys.database_principals, and <dbname>.sys.database_permissions
   views.
   • Integration Services OS account least privileges: Windows Management
   Instrumentation (WMI).
   • Latest service pack/hot fix not applied: uses @@version - requires no
   privileges.




                      Application Security, Inc.                                 250
      • Linked Servers Definitions: select from sys.servers view.
      Permissions granted on sp_add_dtspackage: select all rows from
      msdb.sys.database_permissions, sys.types, sys.all_objects,
      sys.certificates, sys.fulltext_catalogs, sys.routes,
      sys.remote_service_bindings, sys.services, sys.service_contracts,
      sys.service_message_types, sys.xml_schema_collections, sys.assemblies
      views which implies VIEW DEFINITION on database scope permission.
      • Lumigent Log Explorer buffer overflow: select all rows from
      master.sys.objects view which implies VIEW DEFINITION on master
      database permission.
      • Not using NTFS partition: execute xp_instance_regread.
      • OLEDB ad hoc queries allowed: select from sys.configurations view,
      Registry access.
  To learn more about enabling registry access for Microsoft SQL Server 2005 and 
  2008, see Registry Access for Microsoft SQL Server 2000, 2005, and 2008.
      • Password same as login name: select password_hash column of
      sys.sql_logins view for all sql logins which implies CONTROL SERVER
      permission.
      • Permission grantable: select all rows from sys.databases,
      <dbname>.sys.database_permissions views which implies VIEW DEFINITION
      on database scope permission.
      • Permission on OLE automation procs: select all rows from
      master.sys.database_permissions view which implies VIEW DEFINITION on
      database scope permission.
      • Permission on registry extended proc: select all rows from
      master.sys.database_permissions view which implies VIEW DEFINITION on
      database scope permission.
      • Permission to select from system table: select all rows from
      master.sys.database_permissions view which implies VIEW DEFINITION on
      database scope permission.
      • Permissions granted on xp_cmdshell: select all rows from
      master.sys.database_permissions view which implies VIEW DEFINITION on
      database scope permission.
      • Permissions granted to PUBLIC: select all rows from sys.databases,
      <dbname>.sys.database_permissions views.
      • Permissions granted to user: select all rows from sys.databases,
      <dbname>.sys.database_permissions, sys.types, sys.all_objects,
      sys.certificates, sys.fulltext_catalogs, sys.routes,




251                 Application Security, Inc.
                Appendix L: Required Audit Privileges




sys.remote_service_bindings, sys.services, sys.service_contracts,
sys.service_message_types, sys.xml_schema_collections, sys.assemblies
views which implies VIEW DEFINITION on database scope permission.
• Permissions on files: execute xp_instance_regread.
• Protection of DBMS asymmetric encryption keys: select from
master.dbo.sysdatabases, <dbname>.sys.asymmetric_keys,
<dbname>.sys.database_principals, <dbname>.sys.database_permissions,
VIEW DEFINITION on database scope permission.
• Proxy account subsystem privileges: select subsystem, subsystem_id
columns from msdb.dbo.syssubsystems.
• Registry extended proc not removed: select from
master.sys.system_objects view.
• Registry permissions: execute xp_instance_regread.
• Remote access allowed: select from sys.configurations view.
• Remote admin connections allowed: select from sys.configurations view.
• Sample database not removed: select all rows from sys.databases view.
• Service Broker Endpoints exist: select from
sys.service_broker_endpoints.
• Service runs as LocalSystem: execute xp_instance_regread.
• SMO and DMO XPs enabled: select from sys.configurations view.
• SQL Server Agent account user rights: Windows Management
Instrumentation (WMI).
• SQL Server Agent proxy accounts are not dedicated: execute
sp_enum_login_for_proxy.
• SQL Server component service account user rights: Windows Management
Instrumentation (WMI).
• SQL Server file permissions: Registry access*, OS access (Permission to
read files in the installation directory of the database) also Windows
Management Instrumentation (WMI).
• SQL Server service account: Windows Management Instrumentation (WMI).
• SQL Server service account user rights: Windows Management
Instrumentation (WMI).
• Standard SQL Server authentication allowed: execute
xp_instance_regread.
• Statement permission granted: select all rows from sys.databases,
<dbname>.sys.database_permissions views which implies VIEW DEFINITION on
database scope permission.




                Application Security, Inc.                            252
      • Symmetric Keys: allowed encryption algorithms: select from
      master.dbo.sysdatabases, <dbname>.sys.symmetric_keys, VIEW DEFINITION
      on database scope permission.
      • Symmetric Keys: encrypting mechanism: select from
      master.dbo.sysdatabases, <dbname>.sys.symmetric_keys,
      <dbname>.sys.key_encryptions, VIEW DEFINITION on database scope
      permission.
      • sysadmin role granted: select all rows from sys.server_principals,
      sys.server_role_members views which implies VIEW ANY DEFINITION
      permission.
      • Unauthorized object permission grants: select all rows from
      sys.databases, <dbname>.sys.database_permissions, sys.types,
      sys.all_objects, sys.certificates, sys.fulltext_catalogs, sys.routes,
      sys.remote_service_bindings, sys.services, sys.service_contracts,
      sys.service_message_types, sys.xml_schema_collections, sys.assemblies
      views which implies VIEW DEFINITION on database scope permission.
      • XML web service access: select from sys.http_endpoints.
      • Web assistant procedures enabled: select from sys.configurations
      view.
      • xp_cmdshell not removed/not disabled: select from sys.configurations
      view.

  Credentials for Microsoft SQL Server Audits

  If you are unable to Audit a Microsoft SQL Server database using Windows 
  Authentication, you may be using an account that lacks the proper credentials. 
  There are a number of different ways to supply the proper credentials for Micro‐
  soft SQL Server. The appropriate method depends on your circumstances.

  The following table explains how to change your credentials under different sce‐
  narios when you attempt to perform an Audit on the Microsoft SQL Server TARGET 




253                 Application Security, Inc.
                      Appendix L: Required Audit Privileges




machine from another machine (HOST). Once you have valid credentials on the target 
HOST, you should be able to perform your Audit. 


  Part                   If                                                      Then

   1     TARGET and HOST are in the same          •   If you are logged in to HOST as a user that has Administrative
                                                      access to TARGET, you do not need to supply additional
         or trusted domain.                           credentials.

                                                      Or...

                                                  •   If you are logged in as user without Administrative access, you
                                                      will need to supply TARGET’s sa credentials.




                      Application Security, Inc.                                                            254
      Part                 If                                                   Then

       2     TARGET is in WORKGROUP_X             •   You can supply sa credentials in DbProtect Vulnerability
                                                      Assessment.
             and HOST is in DOMAIN_A
                                                      Or...
             Or...
                                                  •   You can create a local user on TARGET and a local user on
             TARGET is in WORKGROUP_X                 HOST with matching user names and passwords.
             and HOST is in WORKGROUP_Y           Note:You cannot use Domain names here.
             Or...                                  Or...
             TARGET is in WORKGROUP_X             •   Select the Properties branch option Connect to Microsoft
                                                      SQL Servers using Named Pipes in the DbProtect Vulnerability
             and HOST is in WORKGROUP_X               Assessment Properties branch, then use the Net Use
                                                      technique to establish credentials on TARGET. You must
                                                      select this option to force DbProtect Vulnerability Assessment
                                                      to use named pipes. You must check this option if you want to
                                                      Audit a Microsoft SQL Server database (using Windows
                                                      Authentication) against a machine on a different or untrusted
                                                      domain. Additional steps are required. For more information,
                                                      see Auditing Microsoft SQL Server (Using Windows
                                                      Authentication) Against a Machine on a Different or Untrusted
                                                      Domain.

                                                      To use the Net Use technique:

                                                              ‐Open a command prompt.
                                                              ‐Enter the net use command to log 
                                                              in to the target server with valid 
                                                              credentials.
                                                              ‐The command should adhere to the 
                                                              following format: net use
                                                              \\computerIP /
                                                              user:[domainname\]username
                                                              ‐DbProtect Vulnerability Assessment 
                                                              prompts you for a valid password on 
                                                              the TARGET.
                                                              ‐Verify access by re‐entering net
                                                              use.
                                                  Note:DbProtect Vulnerability Assessment does not support
                                                         Pen Testing any Microsoft SQL Server instances which use
                                                         named pipes for connection.


255                  Application Security, Inc.
                           Appendix L: Required Audit Privileges




     Part                      If                                                    Then

      3      TARGET is in DOMAIN_A and                 •   You can use any of the methods listed in Part 2, above.

             HOST is either in an untrusted                Or...
             DOMAIN_B or in 
             WORKGROUP_X                               •   You can add HOST to DOMAIN_A.



Auditing Microsoft SQL Server (Using Windows Authentication)
Against a Machine on a Different or Untrusted Domain

If you attempt to Audit a Microsoft SQL Server database (using Windows Authenti‐
cation) against a machine on a different or untrusted domain, the following error 
message may display:
            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 Microsoft SQL Server database (using Windows Authentication) against a 
machine on a different or untrusted domain: 
1.   Establish a connection to the target server.

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
2. Use named pipes to connect to an untrusted domain.

Select the Properties branch option Connect to Microsoft SQL Servers using Named 
Pipes. You must check this option when Auditing a Microsoft SQL Server database in 
an untrusted domain.
Important: You must enable the named pipes protocol on both the DbProtect host and the Microsoft SQL Server
           target server when using this option.




                           Application Security, Inc.                                                           256
  DbProtect does not support Pen Testing any Microsoft SQL Server instances 
  which use named pipes for connection.
  3. Make sure of 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
     • the login provides remote registry access and read‐only file access to the 
     remote machine. To check this, do the following: 
     • 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/XP/Vista. 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.
  4. Do the following to create and test a DSN connection to the target host:
     • Choose Control Panel > Administrative Tools > Data Sources (ODBC).
     • Open the System DSN tab and click the Add button.
     • Choose Microsoft SQL Server from the list.
     • Click the Finish button.
     • Enter a Name and Description for this data source entry.
     • In the Server field, enter the IP address and listening port of the target server, 
     e.g., 172.27.190.58,1756.
     • Click the Next button.
     • Select SQL Server Authentication and enter your database credentials in the 
     Login ID and Password fields. 
     • Click the Next button.
     • Follow the steps in the wizard.

  You should be able to test the connection to the data source. If this test is success‐
  ful, you should also be able to perform the Audit with DbProtect. 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).




257                   Application Security, Inc.
                         Appendix L: Required Audit Privileges




Running the Microsoft SQL Server 2005 and 2008 User Creation
Script

Application Security Inc. has written a convenient Microsoft SQL Server 2005 and 
Microsoft SQL Server 2008 user creation script 
(CreateUserSQLServer2k52k8PublicRevoked.sql) which creates an account with the 
minimum privileges necessary to perform Audits on either a Microsoft SQL Server 
2005 or a Microsoft SQL Server 2008 instance.
Caution! If you want to run this script, make sure whatever account you use to conduct your
          Audit has at least the SELECT privileges listed in the script (see below).

The contents of the CreateUserSQLServer2k52k8PublicRevoked.sql script follow:
CREATE LOGIN [aduser] WITH PASSWORD=N'Admin123', DEFAULT_DATABASE=[master]
GO


EXEC sp_MSforeachdb '
USE [?]
DECLARE @isUpdateable sql_variant


SELECT @isUpdateable = databasePropertyEx(name,"Updateability") FROM mas-
ter.dbo.sysdatabases where databasePropertyEx(name,"Status")="ONLINE" and
name = "?"


IF @isUpdateable = "READ_WRITE"
BEGIN
       CREATE USER [aduser] FOR LOGIN [aduser] WITH DEFAULT_SCHEMA=[dbo]
END'
GO


USE [master]




                         Application Security, Inc.                                           258
  GO
  GRANT EXECUTE ON dbo.xp_loginconfig TO [aduser]
  GRANT SELECT ON dbo.syslogins TO [aduser]
  GRANT SELECT ON dbo.sysdatabases TO [aduser]
  GRANT SELECT ON dbo.sysconfigures TO [aduser]
  GRANT SELECT ON dbo.syscurconfigs TO [aduser]
  GRANT SELECT ON dbo.syscharsets TO [aduser]
  GRANT SELECT ON sys.configurations TO [aduser]
  GRANT SELECT ON sys.server_principals TO [aduser]
  GRANT SELECT ON sys.server_role_members TO [aduser]
  GRANT ALTER TRACE TO [aduser]
  GRANT SELECT ON sys.fn_trace_getinfo TO [aduser]




  EXEC sp_MSforeachdb '
  DECLARE @isUpdateable sql_variant


  SELECT @isUpdateable = databasePropertyEx(name,"Updateability") FROM
  master.dbo.sysdatabases where databasePropertyEx(name,"Status")="ONLINE"
  and name = "?"


  IF @isUpdateable = "READ_WRITE"
  BEGIN
         GRANT EXECUTE ON [?].dbo.sp_helprotect TO [aduser]
  END'




  GRANT SELECT ON sys.servers TO [aduser]




259                  Application Security, Inc.
                   Appendix L: Required Audit Privileges




GRANT EXECUTE ON dbo.sp_helpsrvrolemember TO [aduser]
GRANT SELECT ON dbo.fn_trace_geteventinfo TO [aduser]
GRANT SELECT ON dbo.fn_trace_getinfo TO [aduser]
GRANT SELECT ON sys.databases TO [aduser]
GRANT SELECT ON sys.master_key_passwords TO [aduser]
GRANT SELECT ON sys.sql_logins TO [aduser]
GRANT SELECT ON sys.master_files TO [aduser]
GRANT SELECT ON sys.procedures TO [aduser]
GRANT SELECT ON sys.server_permissions TO [aduser]
GRANT SELECT ON sys.all_objects TO [aduser]
GRANT SELECT ON sys.certificates TO [aduser]
GRANT SELECT ON sys.fulltext_catalogs TO [aduser]
GRANT SELECT ON sys.routes TO [aduser]
GRANT SELECT ON sys.remote_service_bindings TO [aduser]
GRANT SELECT ON sys.services TO [aduser]
GRANT SELECT ON sys.service_contracts TO [aduser]
GRANT SELECT ON sys.service_message_types TO [aduser]
GRANT SELECT ON sys.xml_schema_collections TO [aduser]
GRANT SELECT ON sys.assemblies TO [aduser]
GRANT SELECT ON sys.http_endpoints TO [aduser]
GRANT SELECT ON dbo.sysservers TO [aduser]
GRANT SELECT ON dbo.sysservers TO [aduser]
GRANT SELECT ON sys.linked_logins         TO [aduser]
GRANT SELECT ON sys.service_broker_endpoints TO [aduser]
GRANT SELECT ON sys.credentials TO [aduser]
GRANT EXECUTE ON dbo.sp_helppublication TO [aduser]
GRANT EXECUTE ON dbo.sp_helpmergepublication TO [aduser]




                   Application Security, Inc.              260
  GRANT EXECUTE ON dbo.sp_helpmergesubscription TO [aduser]
  GRANT EXECUTE ON dbo.sp_helpsubscription TO [aduser]
  GRANT EXECUTE ON dbo.sp_help_publication_access TO [aduser]
  GRANT EXECUTE ON dbo.sp_helpuser TO [aduser]
  GRANT SELECT ON sys.dm_os_cluster_nodes TO [aduser]
  GRANT SELECT ON sys.database_files TO [aduser]
  GRANT EXECUTE ON dbo.sp_helpreplicationdboption TO [aduser]
  GRANT EXECUTE ON dbo.sp_helprolemember TO [aduser]
  GRANT SELECT ON dbo.sysprocesses TO [aduser]
  grant view any definition to [aduser]
  GRANT VIEW SERVER STATE TO [aduser]
  GO




  USE [msdb]
  GO
  GRANT EXECUTE ON dbo.sp_get_sqlagent_properties TO [aduser]
  GRANT SELECT ON dbo.sysproxysubsystem TO [aduser]
  GRANT SELECT ON dbo.sysproxies TO [aduser]
  GRANT EXECUTE ON dbo.sp_enum_login_for_proxy TO [aduser]
  GRANT SELECT ON dbo.sysjobs ([name],[job_id]) TO [aduser]
  GRANT SELECT ON dbo.sysjobhistory ([job_id]) TO [aduser]
  GRANT SELECT ON dbo.syssubsystems ([subsystem],[subsystem_id]) TO
  [aduser]
  GRANT SELECT ON [dbo].[sysjobsteps] ([proxy_id],[subsystem], [job_id])
  TO [aduser]
  GRANT SELECT ON dbo.sysjobs TO [aduser]




261               Application Security, Inc.
                   Appendix L: Required Audit Privileges




GO




EXEC sp_MSforeachdb '
USE [?]
DECLARE @isUpdateable sql_variant
SELECT @isUpdateable = databasePropertyEx(name,"Updateability") FROM mas-
ter.dbo.sysdatabases where databasePropertyEx(name,"Status")="ONLINE" and
name = "?"


IF @isUpdateable = "READ_WRITE"
BEGIN
GRANT SELECT ON dbo.sysusers TO [aduser]
GRANT SELECT ON dbo.sysobjects TO [aduser]
GRANT SELECT ON dbo.syscomments TO [aduser]
GRANT VIEW DEFINITION TO [aduser]
GRANT SELECT ON sys.database_permissions TO [aduser]
GRANT SELECT ON sys.objects TO [aduser]
GRANT SELECT ON sys.asymmetric_keys TO [aduser]
GRANT SELECT ON sys.database_principals TO [aduser]
GRANT SELECT ON sys.key_encryptions TO [aduser]
GRANT SELECT ON sys.symmetric_keys TO [aduser]
GRANT SELECT ON sys.types TO [aduser]
GRANT SELECT ON sys.sysmembers TO [aduser]
GRANT SELECT ON sys.database_role_members TO [aduser]
GRANT SELECT ON sys.schemas TO [aduser]
GRANT SELECT ON sys.system_objects TO [aduser]
END'



                   Application Security, Inc.                          262
  GO

  Registry Access for Microsoft SQL Server 2000, 2005, and 2008

  Some Microsoft SQL Server 2000, 2005, and 2008 Audit privileges require you to 
  have remote registry access in order to perform Audits on Microsoft SQL Server 
  instances. These required Audit privileges are listed in:
       • Microsoft SQL Server 2000 and MSDE Audit Privileges (for all applicable 
       Microsoft SQL Server 2000 Audit privileges)
       • Microsoft SQL Server 2005 and Microsoft SQL Server 2008 Audit Privileges 
       (for all applicable Microsoft SQL Server 2005 and 2008 Audit privileges).

  Depending on your version of Microsoft SQL Server 2000, 2005, and 2008 (and 
  whether you are using Microsoft SQL Server Authentication or Windows Authen‐
  tication), you can get the remote registry value in either of the following two 
  ways:




263                  Application Security, Inc.
                         Appendix L: Required Audit Privileges




5. using the xp_regread extended stored procedure (explained in the following 
   table). 

           If your version of
                                   And you are
             Microsoft SQL                                        Detail
                                     using:
                Server is:

           Microsoft            Microsoft            Grant execute on xp_regread 
           SQL Server           SQL Server           to the DbProtect Vulnerability 
           2000 (service        Authenticati         Assessment user or the Public 
           pack prior to        on                   role.
           SP4)
                                Windows              Grant execute on xp_regread 
                                Authenticati         to the Windows user or to the 
                                on                   Public role, and permissions 
                                                     on the key being accessed.




                         Application Security, Inc.                                    264
      If your version of
                             And you are
        Microsoft SQL                                      Detail
                               using:
           Server is:

      Microsoft            Microsoft       Grant execute on xp_regread 
      SQL Server           SQL Server      to the DbProtect Vulnerability 
      2000 SP4 and         Authenticati    Assessment user or the Public 
      Microsoft            on              role.
      SQL Server 
                           Windows         Grant execute on xp_regread 
      2005 or 2008
                           Authenticati    to Windows user or the 
                           on              Public role, and permissions 
                                           on the key being accessed.
                           Microsoft       Although authentication 
                           SQL Server      mode (i.e., Microsoft SQL 
                           Authenticati    Server Authentication or 
                           on or           Windows Authentication) is 
                           Windows         used, DbProtect Vulnerability 
                           Authenticati    Assessment requires an entry 
                           on              on the target 
                                           (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
                                           \Microsoft SQL
                                           Server\<INSTANCE>\MSSQLServer
                                           \ExtendedProcedures\Xp_regr
                                           ead Allowed Paths) of the 
                                           requested registry subkey. 
                                           (Reference: http://
                                           support.microsoft.com/kb/
                                           887165)
                                           Since the Microsoft SQL 
                                           Server installation program 
                                           pre‐populates the Xp_regread
                                           Allowed Paths registry entry 
                                           with the extended stored 
                                           procedures that Microsoft 
                                           SQL Server can access, you 
                                           only need to add the 
                                           following registry entries: 
265               Application Security, Inc. HKEY_LOCAL_MACHINE\SOFTWARE\
                                           •
                                             Microsoft\Microsoft SQL
                                             Server\Instance Names\SQL
                     Appendix L: Required Audit Privileges




6. Get the remote registry value using the Windows Remote Registry API, and pro‐
   vide a valid Windows account with remote registry access.




                     Application Security, Inc.                               266
  MySQL Audit Privileges
  For more information on MySQL Server OS check requirements, see Operating 
  System Considerations (for Audits).

  To conduct a full MySQL Audit, you need the following privileges. Make sure 
  the account you are using has rights to use the following tables and views:
      • Anonymous user exists: SELECT on user table
      • Blank account passwords: SELECT on user table
      • Blank root password: SELECT on user table
      • Default passwords for test accounts: SELECT on user table
      • Easily-guessed account passwords: SELECT on user table
      • Easily-guessed root password: SELECT on user table
      • FILE privileges granted: SELECT on user table
      • General log file not enabled: execute SHOW VARIABLES
      • Password for user same as username: SELECT on user table
      • Permissions grantable: SELECT on the user table, SELECT on the db
      table, SELECT on the host table, SELECT on the tables_priv table, and
      SELECT on the procs_priv table
      • Permissions on GRANT tables: SELECT on the user table, SELECT on the
      db table, SELECT on the host table, SELECT on the tables_priv table,
      SELECT on the procs_priv table, and SELECT on the columns_priv' table
      • Permissions on user table: SELECT on the user table, SELECT on the
      db table, SELECT on the host table, SELECT on the tables_priv table,
      and SELECT on the columns_priv table.
      • PROCESS privileges granted: SELECT on user table
      • Sample database not removed: execute SHOW DATABASES
      • SSL encryption not enabled: execute SHOW VARIABLES
      • Grant SELECT on procs_priv
  The Grant SELECT on procs_priv privilege is only required on the Permissions
  on GRANT tables and Permissions grantable MySQL Audit checks on MySQL 
  5.0 and greater.




267                Application Security, Inc.
                     Appendix L: Required Audit Privileges




MySQL Checks

MySQL Audit
  • Easily-guessed root password
  • Easily-guessed passwords
  • Blank password
  • Blank root password
  • Universal access
  • SSL is enabled
  • Grant tables privileges
  • Ensure sample databases have been removed
  • Permissions on [User] table
  • Permissions granted directly to user
  • Logging not enabled
  • MySQL mysqld Privilege Escalation Vulnerability
  • MySQL libmysqlclient Library Read_One_Row Buffer Overflow Vulnerability
  • MySQL COM_CHANGE_USER Password Memory Corruption Vulnerability
  • MySQL Double Free Heap Corruption Vulnerability
  • MySQL COM_CHANGE_USER Password Length Account Compromise Vulnerability
  • MySQL libmysqlclient Library Read_Rows Buffer Overflow Vulnerability
  • MySQL COM_TABLE_DUMP Memory Corruption Vulnerability
  • MySQL COM_TABLE_DUMP Memory Corruption Vulnerability
  • MySQL Bind Address Not Enabled Weak Default Configuration Vulnerability
  • MySQL Null Root Password Weak Default Configuration Vulnerability
  • WinMySQLadmin Plain Text Password Storage Vulnerability
  • MySQL Root Operation Symbolic Link File Overwriting Vulnerability
  • MySQL SHOW GRANTS Password Hash Disclosure Vulnerability
  • MySQL Local Buffer Overflow Vulnerability
  • MySQL Authentication Algorithm Vulnerability




                     Application Security, Inc.                         268
      • MySQL GRANT Global Password Changing Vulnerability
      • MySQL Unauthenticated Remote Access Vulnerability
      • Permissions on GRANT tables
      • Permissions grantable
  The Grant SELECT on procs_priv privilege is only required on the Permissions
  on GRANT tables and Permissions grantable MySQL Audit checks on MySQL 
  5.0 and greater.

  MySQL Pen Test
      • Easily-guessed root password
      • Easily-guessed password
      • Blank password
      • Blank root password
      • MySQL mysqld Privilege Escalation Vulnerability
      • MySQL libmysqlclient Library Read_One_Row Buffer Overflow
      Vulnerability
      • MySQL COM_CHANGE_USER Password Memory Corruption Vulnerability
      • MySQL Double Free Heap Corruption Vulnerability
      • MySQL COM_CHANGE_USER Password Length Account Compromise
      Vulnerability
      • MySQL libmysqlclient Library Read_Rows Buffer Overflow Vulnerability
      • MySQL COM_TABLE_DUMP Memory Corruption Vulnerability
      • MySQL COM_TABLE_DUMP Memory Corruption Vulnerability
      • MySQL Bind Address Not Enabled Weak Default Configuration
      Vulnerability
      • MySQL Null Root Password Weak Default Configuration Vulnerability
      • WinMySQLadmin Plain Text Password Storage Vulnerability
      • MySQL Root Operation Symbolic Link File Overwriting Vulnerability
      • MySQL SHOW GRANTS Password Hash Disclosure Vulnerability
      • MySQL Local Buffer Overflow Vulnerability
      • MySQL Authentication Algorithm Vulnerability



269                  Application Security, Inc.
                       Appendix L: Required Audit Privileges




   • MySQL GRANT Global Password Changing VulnerabilityMySQL
   • MySQL Unauthenticated Remote Access Vulnerability


Oracle Audit Privileges and User Creation Script
For more information on Oracle OS check requirements, see Operating System 
Considerations (for Audits).

This topic consists of the following sub‐topics:
   •   Oracle Audit Privileges
   •   Running the Oracle User Creation Script.
Oracle Audit Privileges

To conduct a full Oracle Audit, you need the following privileges. Make sure the 
account you are using has rights to use the following tables, views, and functions:
   • $PWFILE_USERS
   • ALTER USER username TEMPORARY TABLESPACE TEMP
   • DBA_OBJ_AUDIT_OPTS
   • DBA_OBJECTS
   • DBA_PROFILES
   • DBA_ROLES
   • DBA_ROLE_PRIVS
   • DBA_STMT_AUDIT_OPTS
   • DBA_SYS_PRIVS
   • DBA_TABLES
   • DBA_TAB_PRIVS
   • DBA_USERS
   • DBA_VIEWS
   • DBMS_UTILITY.PORT_STRING
   • PRODUCT_COMPONENT_VERSION
   • SYS.LINK$



                       Application Security, Inc.                                 270
      • SYS.USER$
      • SYS.REGISTRY$HISTORY
      • SYS.DBA_DB_LINKS
      • SYS.DBA_LIBRARIES
      • SYS.DBA_OBJECTS
      • SYS.DBA_ROLE_PRIVS
      • SYS.DBA_SOURCE
      •   SYS.DBA_USERS
      •   SYS.DBA_DB_LINKS
      •   SYS.V_$INSTANCE
      •   SYS.DBA_TS_QUOTAS
      • V$LOG
      •   V$PWFILE_USERS
      •   V$VERSION
      •   V_$DATABASE
      •   V_$DATAFILE
      •   V_$LOGFILE
      •   V_$SESSION
      • V_$PARAMETER (DbProtect Vulnerability Assessment selects from 
      V$PARAMETER but you must grant SELECT on V_$PARAMETER)


 Note:     The user account must have the CREATE SESSION privilege. In addition, the 
           user account used for Audits needs a temporary table space assigned, which 
           you can create with the following command: ALTER USER username
           TEMPORARY TABLESPACE TEMP

  The following script creates an account with the minimum privileges necessary 
  to perform a Security Audit on an Oracle SID. Be sure that whatever account is 
  used to conduct your Audit has at least the SELECT privileges listed below:
  DROP USER aduser cascade;
  CREATE USER aduser IDENTIFIED BY AD123;
  GRANT SELECT ON SYS.DBA_DB_LINKS TO aduser;




271                   Application Security, Inc.
                   Appendix L: Required Audit Privileges




GRANT SELECT ON SYS.DBA_DATA_FILES TO aduser;
GRANT SELECT ON SYS.DBA_OBJECTS TO aduser;
GRANT SELECT ON SYS.DBA_OBJ_AUDIT_OPTS TO aduser;
GRANT SELECT ON SYS.DBA_PROCEDURES TO aduser;
GRANT SELECT ON SYS.DBA_PROFILES TO aduser;
GRANT SELECT ON SYS.DBA_ROLES TO aduser;
GRANT SELECT ON SYS.DBA_ROLE_PRIVS TO aduser;
GRANT SELECT ON SYS.DBA_STMT_AUDIT_OPTS TO aduser;
GRANT SELECT ON SYS.DBA_SYS_PRIVS TO aduser;
GRANT SELECT ON SYS.DBA_TABLES TO aduser;
GRANT SELECT ON SYS.DBA_INDEXES TO aduser;
GRANT SELECT ON SYS.DBA_TAB_PRIVS TO aduser;
GRANT SELECT ON SYS.DBA_TS_QUOTAS TO aduser;
GRANT SELECT ON SYS.DBA_USERS TO aduser;
GRANT SELECT ON SYS.DBA_SOURCE TO aduser;
GRANT SELECT ON SYS.DBA_VIEWS TO aduser;
GRANT SELECT ON SYS.PRODUCT_COMPONENT_VERSION TO aduser;
GRANT SELECT ON SYS.LINK$ TO aduser;
GRANT SELECT ON SYS.USER$ TO aduser;
GRANT SELECT ON SYS.V_$PARAMETER TO aduser;
GRANT SELECT ON SYS.V_$LOG TO aduser;
GRANT SELECT ON SYS.V_$PWFILE_USERS TO aduser;
GRANT SELECT ON SYS.V_$INSTANCE TO aduser;
GRANT SELECT ON SYS.V_$DATABASE TO aduser;
GRANT SELECT ON SYS.DBA_PRIV_AUDIT_OPTS TO aduser;
GRANT SELECT ON SYS.DBA_REPCATLOG TO aduser;
GRANT SELECT ON SYS.DEFPROPAGATOR TO aduser;



                   Application Security, Inc.              272
  GRANT SELECT ON SYS.V_$DATAFILE TO aduser;
  GRANT SELECT ON SYS.V_$LOGFILE TO aduser;
  GRANT SELECT ON SYS.V_$SESSION TO aduser;
  GRANT SELECT ON SYS.REGISTRY$HISTORY TO aduser;
  GRANT CREATE SESSION TO aduser;
  grant javasyspriv to aduser;
  grant create procedure to aduser;




273               Application Security, Inc.
                      Appendix L: Required Audit Privileges




The following is a list of checks within the DbProtect Vulnerability Assessment for 
Oracle Security Audit, and the tables and views which they need permission to in 
order to function properly:
   • _TRACE_FILES_PUBLIC undocumented configuration parameter is NOT set to
   FALSE
This check requires SYSDBA privileges, and, because of this, it is not part of any 
built‐in Policies.
   • Account associated with DEFAULT profile: DBA_USERS
   • Account granted the predefined role CONNECT: DBA_ROLE_PRIVS
   • Account granted the predefined role DBA:                  DBA_ROLE_PRIVS
   • Account granted the predefined role RESOURCE:                 DBA_ROLE_PRIVS
   • Accounts with SYSTEM as default tablespace:                 DBA_USERS
   • ANSI join syntax bypasses object privileges: PRODUCT_COMPONENT_VERSION
   • ANY system privilege applies to data dictionary:                 V$PARAMETER
   • Auditing Not Enabled:        V$PARAMETER
   • Auditing of CREATE SESSION not enabled:                  DBA_STMT_AUDIT_OPTS
   • BFILENAME buffer overflow (Verify version):PRODUCT_COMPONENT_VERSION
   • Brute-force database password:            DBA_USERS
   • Brute-force role password:          SYS.USER$
   • Cleartext password stored with database link:                 SYS.LINK$
   • Create library privilege:          DBA_SYS_PRIVS, PRODUCT_COMPONENT_VERSION
   • Database link buffer overflow (Verify
   version):PRODUCT_COMPONENT_VERSION
   • Database user allows remote authentication:                 DBA_USERS, V$PARAMETER
   • DBLINK_ENCRYPT_LOGIN not enabled:              SYS.LINK$, V$PARAMETER
   • DBMS dedicated software directory and partition: V$DATAFILE, V$LOGFILE,
   V$PARAMETER
   • Default database password: DBA_USERS
   • Easily-guessed database password:              DBA_USERS
   • Easily-guessed role password:            SYS.USER$



                      Application Security, Inc.                                          274
      • Expired password:     DBA_USERS, PRODUCT_COMPONENT_VERSION
      • Kick Listener DoS (Verify version):         PRODUCT_COMPONENT_VERSION
      • Label Security row label improperly assigned:
      PRODUCT_COMPONENT_VERSION
      • Label Security SQL predicates bypassed:         PRODUCT_COMPONENT_VERSION
      • Label Security unauthorized higher level read:
      PRODUCT_COMPONENT_VERSION
      • Listener debug DoS (Verify version):         PRODUCT_COMPONENT_VERSION
      • Listener format string buffer overflow (Verify version):
      PRODUCT_COMPONENT_VERSION
      • Locked account:     DBA_USERS, PRODUCT_COMPONENT_VERSION
      • MTDS DoS (Verify version):     PRODUCT_COMPONENT_VERSION
      • NERP DoS (Verify version):     PRODUCT_COMPONENT_VERSION
      • Non-standard account with DBA role:         DBA_ROLE_PRIVS
      • NSPTCN buffer overflow (Verify version):         PRODUCT_COMPONENT_VERSION
      • NSPTCN data offset DoS (Verify version):         PRODUCT_COMPONENT_VERSION
      • Object privilege grantable: DBA_TAB_PRIVS
      • Object privilege granted to account:         DBA_TAB_PRIVS, DBA_USERS
      • Object privilege granted to PUBLIC:         DBA_TAB_PRIVS
      • Oracle Configuration Manager: DBA_USERS
      • Oracle DIAGNOSTIC_DEST parameter: V$PARAMETER
      • Oracle file overwrite:    PRODUCT_COMPONENT_VERSION
      • Oracle LOG_ARCHIVE_DEST parameter: V$DATABASE, V$PARAMETER
      • OS authentication prefix:     V$PARAMETER
      • Overdue password change:     sys.user$
      • Password for database user same as username:            DBA_USERS
      • Privilege granted to SELECT from data dictionary:            DBA_TABLES,
      DBA_TAB_PRIVS
      • Privilege on audit trail table:         DBA_TAB_PRIVS
      • Privilege on database link table:         DBA_TAB_PRIVS, DBA_USERS




275                Application Security, Inc.
                Appendix L: Required Audit Privileges




• Privilege to execute UTL_FILE granted to PUBLIC:                DBA_TAB_PRIVS
• Privilege to execute UTL_HTTP granted to PUBLIC:                DBA_TAB_PRIVS
• Privilege to execute UTL_SMTP granted to PUBLIC:                DBA_TAB_PRIVS
• Privilege to execute UTL_TCP granted to PUBLIC:               DBA_TAB_PRIVS
• Profile settings - Failed Login Attempts:                DBA_PROFILES,
PRODUCT_COMPONENT_VERSION
• Profile settings - Password Grace Time:                DBA_PROFILES,
PRODUCT_COMPONENT_VERSION
• Profile settings - Password Life Time:                DBA_PROFILES,
PRODUCT_COMPONENT_VERSION
• Profile settings - Password Lock Time:                DBA_PROFILES,
PRODUCT_COMPONENT_VERSION
• Profile settings - Password Reuse Maximum:               DBA_PROFILES,
PRODUCT_COMPONENT_VERSION
• Profile settings - Password Reuse Time: DBA_PROFILES,
PRODUCT_COMPONENT_VERSION
• Profile settings - Password Verify Function:               DBA_PROFILES,
PRODUCT_COMPONENT_VERSION
• Remote login password file not disabled:                V$PARAMETER
• Remote OS Authentication enabled:           V$PARAMETER
• Remote OS Roles enabled:      V$PARAMETER
• Requestor version DoS (Verify version):                PRODUCT_COMPONENT_VERSION
• Role without password:     DBA_ROLES
• Roles granted WITH ADMIN OPTION:          DBA_ROLE_PRIVS
• SERVICE_CURLOAD DoS (Verify version):             PRODUCT_COMPONENT_VERSION
• SERVICE_NAME buffer overflow (Verify version):
PRODUCT_COMPONENT_VERSION
• SNMP DoS (Verify version):       PRODUCT_COMPONENT_VERSION
• SQL92_SECURITY parameter not enabled:             V$PARAMETER
• SYSDBA auditing bug:     PRODUCT_COMPONENT_VERSION
• SYSDBA privilege assignments




                Application Security, Inc.                                           276
      • System privilege granted to account:        DBA_SYS_PRIVS, DBA_USERS
      • System privilege granted to PUBLIC:        DBA_SYS_PRIVS
      • System privilege granted WITH ADMIN OPTION:        DBA_SYS_PRIVS
      • System privilege with ANY clause:        DBA_SYS_PRIVS
      • TCL debugger installs with setUID root:        DBA_SYS_PRIVS
      • TCL debugger installs with setUID root:        PRODUCT_COMPONENT_VERSION
      • TO_TIMESTAMP_TZ buffer overflow (Verify
      version):PRODUCT_COMPONENT_VERSION
      • TZ_OFFSET buffer overflow (Verify
      version):PRODUCT_COMPONENT_VERSION
      • Trace reporting buffer overflow:        PRODUCT_COMPONENT_VERSION
      • UTL_FILE_DIR unrestricted:     V$PARAMETER
      • XSQL Servlet stylesheet as URL parameter:       PRODUCT_COMPONENT_VERSION
      • Auditing of Schema Objects: DBA_OBJ_AUDIT_OPTS, DBA_VIEWS




277                Application Security, Inc.
                     Appendix L: Required Audit Privileges




Running the Oracle User Creation Script

Application Security Inc. has written a convenient Oracle user creation script 
(CreateUserSQLServer2k.sql) which creates an account with the minimum privileges 
necessary to perform Audits on a Microsoft SQL 2000 instance.

The contents of the CreateUserSQLServer2k.sql script follow:
DROP USER aduser cascade;
CREATE USER aduser IDENTIFIED BY AD123;
GRANT SELECT ON SYS.DBA_DB_LINKS TO aduser;
GRANT SELECT ON SYS.DBA_DATA_FILES TO aduser;
GRANT SELECT ON SYS.DBA_OBJECTS TO aduser;
GRANT SELECT ON SYS.DBA_OBJ_AUDIT_OPTS TO aduser;
GRANT SELECT ON SYS.DBA_PROCEDURES TO aduser;
GRANT SELECT ON SYS.DBA_PROFILES TO aduser;
GRANT SELECT ON SYS.DBA_ROLES TO aduser;
GRANT SELECT ON SYS.DBA_ROLE_PRIVS TO aduser;
GRANT SELECT ON SYS.DBA_STMT_AUDIT_OPTS TO aduser;
GRANT SELECT ON SYS.DBA_SYS_PRIVS TO aduser;
GRANT SELECT ON SYS.DBA_TABLES TO aduser;
GRANT SELECT ON SYS.DBA_INDEXES TO aduser;
GRANT SELECT ON SYS.DBA_TAB_PRIVS TO aduser;
GRANT SELECT ON SYS.DBA_TS_QUOTAS TO aduser;
GRANT SELECT ON SYS.DBA_USERS TO aduser;
GRANT SELECT ON SYS.DBA_SOURCE TO aduser;
GRANT SELECT ON SYS.DBA_VIEWS TO aduser;
GRANT SELECT ON SYS.PRODUCT_COMPONENT_VERSION TO aduser;
GRANT SELECT ON SYS.LINK$ TO aduser;
GRANT SELECT ON SYS.USER$ TO aduser;



                     Application Security, Inc.                              278
  GRANT SELECT ON SYS.V_$PARAMETER TO aduser;
  GRANT SELECT ON SYS.V_$LOG TO aduser;
  GRANT SELECT ON SYS.V_$PWFILE_USERS TO aduser;
  GRANT SELECT ON SYS.V_$INSTANCE TO aduser;
  GRANT SELECT ON SYS.V_$DATABASE TO aduser;
  GRANT SELECT ON SYS.DBA_PRIV_AUDIT_OPTS TO aduser;
  GRANT SELECT ON SYS.DBA_REPCATLOG TO aduser;
  GRANT SELECT ON SYS.DEFPROPAGATOR TO aduser;
  GRANT SELECT ON SYS.V_$DATAFILE TO aduser;
  GRANT SELECT ON SYS.V_$LOGFILE TO aduser;
  GRANT SELECT ON SYS.V_$SESSION TO aduser;


  GRANT SELECT ON SYS.REGISTRY$HISTORY TO aduser;


  GRANT CREATE SESSION TO aduser;
  grant javasyspriv to aduser;
  grant create procedure to aduser;


  Sybase Audit Privileges

  To conduct a full Sybase Audit, you need the following privileges. Make sure the 
  account you are using has rights to use the following tables and views:
      • SELECT @@VERSION
      • master.dbo.syslogins
      • master.dbo.syssrvroles
      • master.dbo.sysdatabases
      • master.dbo.sysconfigures
      • master.dbo.syscurconfigs
      • master.dbo.sysroles



279                 Application Security, Inc.
                  Appendix L: Required Audit Privileges




• master.dbo.sysloginroles
• master.dbo.sysattributes
• master.dbo.sysservers
• exec sp_loginconfig
• exec sp_displayaudit (if it's >= 11.5)
• sp_auditoption (if it's < 11.5 and >= 11.0)
• master.dbo.syblicenseslog
• master.dbo.syscharsets
• <db name>.dbo.sysusers
• <db name>.dbo.sysobjects
• <db name>.dbo.syscomments
• exec <db name>.dbo.sp_help_resource_limit (if itʹs >= 11.5)




                  Application Security, Inc.                    280
  The following is a list of checks within the DbProtect Vulnerability Assessment 
  for Sybase Security Audit, and the tables and views which they need permission 
  to in order to function properly:
      • Audit database owned by sa_role member: master.dbo.syslogins,
      master.dbo.sysloginroles, master.dbo.syssrvroles,
      <dbname>.dbo.sysusers
      • Guest user exists in sybsecurity: master.dbo.syslogins,
      master.dbo.syssrvroles, <dbname>.dbo.sysusers
      • Login granted sa_role: master.dbo.syslogins,
      master.dbo.sysloginroles, master.dbo.syssrvroles,
      <dbname>.dbo.sysusers
      • Login granted sso_role: master.dbo.syslogins,
      master.dbo.sysloginroles, master.dbo.syssrvroles,
      <dbname>.dbo.sysusers
      • Objects not owned by dbo: master.dbo.syslogins,
      master.dbo.syssrvroles, <dbname>.dbo.sysusers,
      <dbname>.dbo.sysobjects
      • Permission granted in sybsecurity: master.dbo.syslogins,
      master.dbo.syssrvroles, <dbname>.dbo.sysobjects
      • Permission granted on system table: master.dbo.syslogins,
      master.dbo.syssrvroles, <dbname>.dbo.sysobjects
      • Permission granted on xp_cmdshell: master.dbo.syslogins,
      master.dbo.syssrvroles, <dbname>.dbo.sysobjects
      • Permission to select from syslogins: master.dbo.syslogins,
      master.dbo.syssrvroles
      • Permissions granted to public: master.dbo.syslogins,
      master.dbo.syssrvroles, <dbname>.dbo.sysusers
      • Permissions granted to user: master.dbo.syslogins,
      master.dbo.syssrvroles, <dbname>.dbo.sysusers
      • Remote access allowed: master.dbo.syslogins, master.dbo.syssrvroles
      • Roles revoked from the sa login: master.dbo.syslogins,
      master.dbo.sysloginroles, master.dbo.syssrvroles
      • Server configured with remote server: master.dbo.syslogins,
      master.dbo.syssrvroles
      • Statement permission granted: master.dbo.syslogins,
      master.dbo.syssrvroles, <dbname>.dbo.sysusers




281                 Application Security, Inc.
                Appendix L: Required Audit Privileges




• Unrestricted access to syscomments: master.dbo.syslogins,
master.dbo.syssrvroles
• Updates allowed to system tables: master.dbo.syslogins,
master.dbo.syssrvroles
• With grant option: master.dbo.syslogins, master.dbo.syssrvroles,
<dbname>.dbo.sysusers
• xp_cmdshell context: master.dbo.syslogins, master.dbo.syssrvroles,
<dbname>.dbo.sysobjects
• Absolute value of numeric DoS (Verify version): master.dbo.syslogins,
master.dbo.syssrvroles
• Allow resource limit: master.dbo.syslogins, master.dbo.syssrvroles
• Audit logout not set: sybsystemprocs.dbo.sp_loginconfig, sso_role
• Audit queue size: master.dbo.syslogins, master.dbo.syssrvroles
• Audit subsystem not installed: master.dbo.syslogins,
master.dbo.syssrvroles
• Auditing disabled: sybsystemprocs.dbo.sp_loginconfig, sso_role
• Auditing of failed logins not enabled:
sybsystemprocs.dbo.sp_loginconfig, sso_role
• Auditing of successful logins not enabled:
sybsystemprocs.dbo.sp_loginconfig, sso_role
• Current audit table: master.dbo.syslogins, master.dbo.syssrvroles
• DBCC CHECKVERIFY buffer overflow: master.dbo.syslogins,
master.dbo.syssrvroles
• DROP DATABASE buffer overflow: master.dbo.syslogins,
master.dbo.syssrvroles
• Event log computer name: master.dbo.syslogins, master.dbo.syssrvroles
• Event logging: master.dbo.syslogins, master.dbo.syssrvroles
• Exceeded licensing limitations: master.dbo.syblicenseslog
• Latest patch not applied: master.dbo.syslogins, master.dbo.syssrvroles
• List resource limits: master.dbo.syslogins, master.dbo.syssrvroles
• Log audit logon failure: master.dbo.syslogins, master.dbo.syssrvroles
• Log audit logon success: master.dbo.syslogins, master.dbo.syssrvroles
• No patches available for version: master.dbo.syslogins,
master.dbo.syssrvroles
• Password array buffer overflow: master.dbo.syslogins,
master.dbo.syssrvroles




                Application Security, Inc.                           282
      • Require message confidentiality with encryption:
      master.dbo.syslogins, master.dbo.syssrvroles
      • Require message integrity: master.dbo.syslogins,
      master.dbo.syssrvroles
      • Select all DoS (Verify version): master.dbo.syslogins,
      master.dbo.syssrvroles
      • Select/Into DoS (Verify version): master.dbo.syslogins,
      master.dbo.syssrvroles
      • SSL enabled: master.dbo.syslogins, master.dbo.syssrvroles
      • Start mail session: master.dbo.syslogins, master.dbo.syssrvroles
      • Suspend audit when full disabled: master.dbo.syslogins,
      master.dbo.syssrvroles
      • Vulns for v12.5.3 ESD#1 (Verify version): master.dbo.syslogins,
      master.dbo.syssrvroles
      • xp_cmdshell not removed: master.dbo.syslogins,
      master.dbo.syssrvroles, <dbname>.dbo.sysobjects
      • xp_freedll buffer overflow: master.dbo.syslogins,
      master.dbo.syssrvroles, <dbname>.dbo.sysobjects
      • Blank password for sa: master.dbo.syslogins, master.dbo.syssrvroles
      • Check password for digit: master.dbo.syslogins,
      master.dbo.syssrvroles
      • Default login exists: sybsystemprocs.dbo.sp_loginconfig, sso_role
      • Default login granted role: sybsystemprocs.dbo.sp_loginconfig,
      sso_role
      • Default password for dba repository user: master.dbo.syslogins,
      master.dbo.syssrvroles
      • Default password for entldbdbo: master.dbo.syslogins,
      master.dbo.syssrvroles
      • Default password for entldbreader: master.dbo.syslogins,
      master.dbo.syssrvroles
      • Default password for jagadmin: master.dbo.syslogins,
      master.dbo.syssrvroles
      • Default password for PIAdmin: master.dbo.syslogins,
      master.dbo.syssrvroles
      • Default password for pkiuser: master.dbo.syslogins,
      master.dbo.syssrvroles
      • Default password for PortalAdmin: master.dbo.syslogins,
      master.dbo.syssrvroles



283                Application Security, Inc.
                Appendix L: Required Audit Privileges




• Default password for pso: master.dbo.syslogins, master.dbo.syssrvroles
• Default SAP password: master.dbo.syslogins, master.dbo.syssrvroles
• Easily-guessed password: master.dbo.syslogins, master.dbo.syssrvroles
• Easily-guessed sa password: master.dbo.syslogins,
master.dbo.syssrvroles
• Expired logins: master.dbo.syslogins, master.dbo.syssrvroles
• Guest user exists in database: master.dbo.syslogins,
master.dbo.syssrvroles, <dbname>.dbo.sysusers
• Locked logins: master.dbo.syslogins, master.dbo.syssrvroles
• Login attributes less restrictive: master.dbo.syslogins,
master.dbo.syssrvroles
• Login mode: sybsystemprocs.dbo.sp_loginconfig, sso_role
• Maximum failed logins: master.dbo.syslogins, master.dbo.syssrvroles
• Minimum password length: master.dbo.syslogins, master.dbo.syssrvroles
• Orphaned user: master.dbo.syslogins, master.dbo.syssrvroles,
<dbname>.dbo.sysusers
• Password same as login name: master.dbo.syslogins,
master.dbo.syssrvroles
• Per login password expiration: master.dbo.syslogins,
master.dbo.syssrvroles
• Roles without passwords: master.dbo.syslogins, master.dbo.syssrvroles
• Secure default login exists: master.dbo.syslogins,
master.dbo.syssrvroles
• System-wide password expiration: master.dbo.syslogins,
master.dbo.syssrvroles
• Unified login required: master.dbo.syslogins, master.dbo.syssrvroles
• Unlocked sa login: master.dbo.syslogins, master.dbo.syssrvroles
• Use security services: master.dbo.syslogins, master.dbo.syssrvroles
• Not using NTFS partition: master.dbo.syslogins, master.dbo.syssrvroles
• Permissions on files: master.dbo.syslogins, master.dbo.syssrvroles
• Registry permissions: master.dbo.syslogins, master.dbo.syssrvroles
• Service runs as LocalSystem: master.dbo.syslogins,
master.dbo.syssrvroles
• Setgid bit enabled: master.dbo.syslogins, master.dbo.syssrvroles
• Setuid bit enabled: master.dbo.syslogins, master.dbo.syssrvroles




                Application Security, Inc.                           284
  Operating System Considerations (for Audits)

  Some DbProtect Vulnerability Assessment Audit checks require more than just a 
  valid database account to perform correctly. They have different requirements 
  depending upon whether the operating system (OS) is Windows or UNIX. (The 
  checks are listed in the Audit category OS Integrity.) They only run if the target 
  database has the appropriate OS.

  This topic consists of the following sub‐topics:
      •   Windows OS Audit Check Requirements
      •   UNIX OS Audit Check Requirements.
  Windows OS Audit Check Requirements

  DbProtect Vulnerability Assessment performs Windows OS checks using Win‐
  dows authentication. Make sure the account and computer you are running 
  DbProtect Vulnerability Assessment from has the appropriate permissions for the 
  corresponding checks:
      • Not Using NTFS Partition. Permission to read the installation disk type.
      • Registry Permissions. Remote registry access.
      • Service Runs as Local System. Permission to list the system services.
      • Permissions on Files. Permission to read files in the installation directory of 
      the database.




285                   Application Security, Inc.
                         Appendix L: Required Audit Privileges




UNIX OS Audit Check Requirements

DbProtect Vulnerability Assessment performs Unix OS checks using a Telnet or SSH 
account. Your account must have the appropriate read and directory listing permis‐
sions activated on the database installation and running directories.

             If you run the following
                                                  Then you must have permission to:
                      checks:

           Permissions on Files           List files in the installation directories 
                                          of the database.
           Setgid Bit Enabled
           Setuid Bit Enabled

Properly‐Configured Environment Variables

DbProtect Vulnerability Assessment can Audit platforms that use system variables to 
specify the location of the database instances. In UNIX, you must set the environment 
variables correctly in order to use SSH or Telnet to access the accounts. Specific 
requirements follow.  

             If you want to Audit the
                                                  Then you must have permission to:
                following platform:

           Oracle                         Make sure the $ORACLE_HOME variable 
                                          is correct.
           Sybase                         Make sure the $SYBASE variable is 
                                          correct.
           MySQL                          Define a datadir or basedir variable 
                                          to point to the database root.




                         Application Security, Inc.                                     286
  Appendix M: Auditing SQL Server (Using
  Windows Authentication) 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 mes‐
  sage may display:
           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.

  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
  2. Use named pipes to connect to an untrusted domain.

  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.
  3. Make sure of 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



287                    Application Security, Inc.
                       Appendix N: Troubleshooting the Java Run Time Environment (JRE) Security Settings




   •  That login provides remote registry access and read‐only file access to the 
    remote machine. To check this, do the following:
        ‐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.
4. Do the following to create and test a DSN connection to the target host:
    • Choose Control Panel > Administrative Tools > Data Sources (ODBC).
    • Open the System DSN tab and click the Add button.
    • Choose Microsoft SQL Server from the list.
    • Click the Finish button.
    • Enter a Name and Description for this data source entry.
    • In the Server field, enter the IP address and listening port of the target server, 
    e.g., 172.27.190.58,1756.
    • Click the Next button.
    • Select SQL Server Authentication and enter your database credentials in the 
    Login ID and Password fields. 
    • Click the Next button.
    • Follow the steps in the wizard.
5. You should now be able to test the connection to the data source. If this test is suc‐
   cessful, 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 Authentica‐
   tion rather than the SQL credentials (after connecting with Net Use).

Appendix N: Troubleshooting the Java Run Time
Environment (JRE) Security Settings on Internet
Explorer 6 and 7


                       Application Security, Inc.                                                   288
  If you are having difficulty logging into the DbProtect Console, you may need to 
  troubleshoot the Java Runtime Environment (JRE) security settings on your Inter‐
  net Explorer (IE) 6 or greater web browser. This appendix explains how.

  If your web browser is IE 6. Proper Active X controls and “enable third‐party 
  browser extensions” security settings may not be enabled on your IE 6 browser. If 
  this is the case, you will encounter an error message you attempt to authenticate, 
  and you can’t log in to the DbProtect Console. To troubleshoot this problem, see 
  Enabling proper Active X controls and “enable third‐party browser extensions” 
  security settings (using IE 6).

  If your web browser is IE 7. JRE 1.6 may be disabled and/or multiple JREs may be 
  enabled on your client (i.e., the location from which your IE 7 browser is running). 
  JRE 1.6 must be enabled in order for you to connect to the DbProtect Console. If 
  JRE 1.6 is disabled, or if multiple JREs of different versions are enabled on your 
  client, then you will encounter an error message when you attempt to authenti‐
  cate, and you can’t log in to the DbProtect Console. To troubleshoot this problem, 
  see Ensuring JRE 1.6 is enabled and temporarily disabling other JREs on your cli‐
  ent machine (using IE 7).




289                  Application Security, Inc.
                        Appendix N: Troubleshooting the Java Run Time Environment (JRE) Security Settings




Enabling proper Active X controls and “enable third-party browser
extensions” security settings (using IE 6)
The following security settings should be the default values in your IE 6 web 
browser. You should only change the settings if you are having difficulty logging into 
the DbProtect Console.

To enable proper Active X controls and “enable third‐party browser extensions” 
security settings on IE 6:
1.   Launch IE 6.
2.   Do the following to display the Security Settings dialog box:
      • Choose: Tools > Internet Options. 
      • Click the Security tab.
      • Click the Custom Level button.
3.   Set the following security settings to Enable or Prompt:
      • Download signed ActiveX controls
      • Run ActiveX controls and plug‐ins.
4.   Click the OK button.
5.   Click the Advanced tab.

The Security Settings dialog box appears.




                        Application Security, Inc.                                                   290
  6. Check Enable Third‐party browser extensions (requires restart).
  7. Click the OK button.
  8. Close and re‐launch IE 6.

  Try to log back into the DbProtect Console. If you continue to experience trouble, 
  contact Application Security, Inc. Customer Support at support@appsecinc.com.

  Ensuring JRE 1.6 is enabled and temporarily disabling other
  JREs on your client machine (using IE 7)

  To ensure JRE 1.6 is enabled, and to temporarily disable multiple JREs on your cli‐
  ent machine (using IE 7): 
  1. Launch IE 7.
  2. Do the following:
      • Choose: Tools > Internet Options. 
      • Click the Advanced tab to display the Settings dialog box.
  3. Scroll down to the Java (Sun) portion of the dialog box and verify the follow‐
     ing:
      • JRE 1.6 is enabled (i.e., the box must be checked)




291                  Application Security, Inc.
                           Appendix P: Monitoring Multiple Instances on a DB2 Server




     •   multiple JRE installations are listed.

JRE 1.6 must be enabled in order for you to connect to the Console. If it is not, check 
the JRE 1.6 box.

If JRE 1.6 is enabled, and other JRE versions are also enabled, then you must tempo‐
rarily disable them by un‐checking the boxes.
4. Do the following:
    • Click the Apply button.
    • Click the OK button.
    • Close and re‐launch IE 7.
5. Try to log back into the Console. If you continue to experience trouble, contact 
   Application Security, Inc. Customer Support at support@appsecinc.com.

Appendix P: Monitoring Multiple Instances on a
DB2 Server
To monitor multiple instances on an DB2 server:
1. Install one host‐based Sensor for DB2 (on any *nix platform) for each instance you 
   want to monitor; for more information, see:
    • Host‐based Sensor for DB2 (on Red Hat Enterprise Linux) ‐ installation steps
    • Host‐based Sensor for DB2 (on Solaris) ‐ installation steps
    • Host‐based Sensor for DB2 (on AIX) ‐ installation steps.
2. Modify the XML files for each host‐based Sensor for DB2 installation and assign a 
   unique port number to each host‐based Sensor for DB2. To do so, you must change 
   the port number so each host‐based Sensor for DB2 has a unique port number; for 
   more information, see Appendix C: Modifying the Sensor Listener Port Number.
3. In these environments, when launching the sensor, go to <Sensor installation
   directory>/util, and run the following command to launch it: appradar_start -




                           Application Security, Inc.                                  292
      m. This allows the host‐based Sensor for DB2 to co‐exist with other Sensors on 
      the same host and within the same account.

  Appendix Q: Monitoring Oracle Databases in an
  Oracle Fail Safe Environment: Sensor and
  Cluster Configuration Steps
  This appendix explains how to configure a host‐based Sensor for Oracle (on Win‐
  dows) in an Oracle Fail Safe environment. It also explains how to configure your 
  Oracle Fail Safe cluster, once you have properly configured your Sensor.

  In this appendix:
      •   About Oracle Fail Safe
      •   Oracle Fail Safe vs. Oracle RAC
      •   Sensor configuration steps (Oracle Fail Safe)
      •   Cluster configuration steps (Oracle Fail Safe).

  About Oracle Fail Safe

  Oracle Fail Safe, a type of Oracle cluster, is a core feature included with every 
  Oracle 11gR1, Oracle 10g and Oracle9i license for Microsoft Windows 2000 and 
  Microsoft Windows 2003. Oracle Fail Safe is integrated with Microsoft Cluster 
  Server to allow you to configure and verify Microsoft Windows clusters and to 
  automatically fail over Oracle databases and applications.

  Oracle Fail Safe is essentially a Microsoft Clustering Services (MSCS) plug‐in. In 
  an MSCS architecture, two systems share the same disk, which only one system 
  controls at a time. In the event of a failure (determined by the heartbeat mecha‐
  nism), the standby system replaces the instance currently running the Oracle 
  instance (and controlling the storage).




293                     Application Security, Inc.
                      Appendix Q: Monitoring Oracle Databases in an Oracle Fail Safe Environment: Sensor




Oracle Fail Safe vs. Oracle RAC

Oracle Fail Safe differs in several ways from Oracle Real Application Cluster (RAC); 
for more information on installing and configuring a host‐based Sensor for Oracle 
(on Windows) to monitor Oracle databases on a RAC, see Appendix B: Installing and 
Configuring a Host‐Based Sensor for Oracle to Monitor Oracle Databases on an Ora‐
cle RAC.




                      Application Security, Inc.                                                    294
  Oracle Fail Safe is generally considered easier to implement and administer than 
  RAC. Most organizations that run applications on Microsoft Windows have 
  already implemented MSCS and are familiar with it. In addition, Oracle Fail Safe 
  is a core feature of Oracle9i and Oracle10g for Windows, so you won’t need addi‐
  tional licenses.

  Another key difference: unlike Oracle RAC (which can run in a Microsoft Win‐
  dows or on a *nix‐based platform), Oracle Fail Safe runs on Microsoft Windows 
  only. Thus, this appendix is only relevant if you are configuring a host‐based Sen‐
  sor for Oracle (on Windows); for more information, see Configuring a host‐based 
  Sensor to monitor Oracle SIDs and services and deploying the configuration information 
  (when Sensor is installed on Windows) in the DbProtect User Guide.

  Sensor configuration steps (Oracle Fail Safe)

  To monitor Oracle databases in an Oracle Fail Safe environment, first complete 
  the following host‐based Sensor for Oracle (on Windows) configuration steps:
  1. Install your host‐based Sensor for Oracle (on Windows); for more information, see Host‐
     based Sensor for Oracle (on Windows) ‐ installation steps.
  2. Register your host‐based Sensor for Oracle (on Windows); for more information, see Registering a 
     Sensor in the DbProtect User Guide.
  3. Configure and deploy your host‐based Sensor for Oracle (on Windows). Pay special 
     attention to:
      • Step 5 of Configuring a host‐based Sensor to monitor Oracle SIDs and services and 
      deploying the configuration information (when Sensor is installed on Windows) in 
      the DbProtect User Guide, where you must select a network adapter that is 
      associated with a real IP address (where the network traffic can sniff packets). 
      Make sure this is not the cluster heartbeat card, because cluster heartbeat 
      cards do not detect network traffic.
      • Step 10 of Configuring a host‐based Sensor to monitor Oracle SIDs and services 
      and deploying the configuration information (when Sensor is installed on Windows in 
      the DbProtect User Guide, where you must configure your network adapter for 
      the clusterʹs virtual IP address. If this is not already populated in the IP 
      Address: field, then you must enter it manually.



295                     Application Security, Inc.
                                Appendix Q: Monitoring Oracle Databases in an Oracle Fail Safe Environment: Sensor




4. Complete the remaining configuration steps described in Configuring a host‐based Sensor to 
     monitor Oracle SIDs and services and deploying the configuration information (when Sensor is installed on Windows in 
     the DbProtect User Guide, and deploy the configured instance to your host‐based Sensor 
     for Oracle (on Windows).
5. Next, configure your Oracle Fail Safe cluster; for more information, see Cluster config‐
     uration steps (Oracle Fail Safe).


Cluster configuration steps (Oracle Fail Safe)

Once you have configured your host‐based Sensor for Oracle (on Windows) to moni‐
tor Oracle databases in an Oracle Fail Safe environment (as explained in Sensor con‐
figuration steps (Oracle Fail Safe)), you must next complete the following cluster 
configuration steps:
1.   In your cluster, make the other node the active node either by initiating a failover 
     or by moving the cluster resources over to that node.




                                Application Security, Inc.                                                          296
  2. From the new active node, access your shared drive using Windows Explorer.
  3. On the shared drive, go to the directory where your host‐based Sensor for Oracle (on Win‐
     dows) is installed and navigate to the <installation directory>\sen-
     sor\conf\overrides directory.
  4. Open the file networkAdapter_sensor_override.xsl in any text editor such as 
     Notepad.
  5. In a separate text editor window, open the file sensor.xml, which is located in 
     the <installation directory>\sensor\conf\ directory.
  6. In the sensor.xml file, locate the line that begins: <networkAdapter name=. Copy 
     everything on that line between the double quotes (but not the double quotes 
     themselves).
  7. Go to the text editor window where the networkAdapter_sensor_override.xsl 
     file is open and locate the following section:
         <!-- This is node 1 -->
                    <xsl:element name="networkAdapter">
                        <!-- Insert network adapter in between xsl attribute
         tags -->
         <xsl:attribute name="name">INSERT_NETWORK_ADAPTER_HERE</
         xsl:attribute>
  8. Paste the information you copied in Step 6 from the sensor.xml file to the loca‐
     tion in Step 7. Specifically, you must paste the information you copied in Step 6 
     between the tags <xsl:attribute name="name"> and </xsl:attribute> so it 
     replaces the string reading: INSERT_NETWORK_ADAPTER_HERE. The string 
     INSERT_NETWORK_ADAPTER_HERE should no longer be visible once you paste the 




297                    Application Security, Inc.
                      Appendix Q: Monitoring Oracle Databases in an Oracle Fail Safe Environment: Sensor




   actual network adapter information for node 1 from the sensor.xml file into this 
   location.
9. Open a command prompt window in the Sensorʹs <installation direc-
   tory>\sensor\bin\ directory on the shared drive.
10.From the command prompt window, run the utility: list_net_adapter.exe
11.The list_net_adapter.exe utility outputs the list of network adapters it detects on 
   cluster node. Note which network adapter corresponds to the real IP address for 
   that node (i.e., not the cluster heartbeat network adapter).
12.Copy the network adapter information.
13.Paste the network adapter information into the area of the 
   networkAdapter_sensor_override.xsl file reserved for the other node of your 
   Oracle Fail Safe cluster. It should be just below the location from Step 8. It looks 
   something like this:
       <!-- This is node 2 -->
                <xsl:element name="networkAdapter">
                    <!-- Insert network adapter in between xsl attribute tags
       -->
                   <xsl:attribute name="name">INSERT_NETWORK_ADAPTER_HERE</
       xsl:attribute>

Again, paste the network adapter information between the tags <xsl:attribute
name="name"> and </xsl:attribute>, replacing the string that reads: 
INSERT_NETWORK_ADAPTER_HERE. The string INSERT_NETWORK_ADAPTER_HERE should no 
longer be visible once the actual network adapter information for node 2 from the 
list_net_adapter.exe utility is pasted in this location.




                      Application Security, Inc.                                                    298
  14.Save the changes made to networkAdapter_sensor_override.xsl, then close 
     the file.
  15.Rename the networkAdapter_sensor_override.xsl file so the words 
     networkAdapter_ are removed. The new file name should be named: 
      sensor_override.xsl
  16.Copy the sensor_override.xsl file from the <installation directory>\sen-
     sor\conf\overrides directory to the <installation directory>\sensor\conf\ 
     directory (one level up).
  17.Restart the DbProtect Sensor service. You can do this in either of two ways:
      • Stop then start the DbProtect Sensor service from the Windows Service 
      Control Manager on the clusterʹs active node.
      • Bring the DbProtect Sensor Cluster resource offline, then bring it online 
      again in the Cluster Administrator on either cluster node.
  18.Once the host‐based Sensor for Oracle (on Windows) restarts, a new file appears in your 
     Sensor installationʹs <installation directory>\sensor\conf\ directory. The 
     new file is named: sensor_transformed.xml. This new file contains two occur‐
     rences of the <networkAdapter> XML element, which the Sensor uses to moni‐
     tor your Oracle Fail Safe cluster.

  Appendix R: Configuring Your Host-Based Sensor
  (Installed on a *nix Platform) to Start
  Automatically Upon System Reboot
  In most cases when you configure an Oracle or DB2 database on a *nix server, the 
  server is set up to automatically start the database and bring up Oracle or DB2 
  upon system restart/reboot. In such cases, you can also have your host‐based Sen‐
  sor for Oracle or DB2 automatically come up when the server (where the Sensors 
  are installed) gets rebooted.

  This appendix explains how to configure your host‐based Sensor for Oracle on a 
  *nix platform (i.e., Solaris, AIX, or Red Hat Enterprise Linux) or DB2 on a *nix 
  platform (i.e., (i.e., Solaris, AIX, HP‐UX, or Red Hat Enterprise Linux) to automat‐
  ically start up whenever you restart your system. In order to accomplish this goal, 


299                   Application Security, Inc.
                      Appendix R: Configuring Your Host-Based Sensor (Installed on a *nix Platform) to Start




you must customize the startup file (located in your <Sensor installation direc-
tory>/util directory) to fit your *nix environment.

To configure your host‐based Oracle or DB2 Sensors (installed on a *nix platform) to 
start automatically upon system reboot:
1. Copy the appradar_startup.sh (for example to arstart).
2. Make the following modifications to the new arstart file.
user=sensor_user
SENSOR_DIR=sensor_dir
prog=”DbProtect Sensor”

Replace the account sensor_user with whatever account name you use to run your 
host‐based Sensor (installed on a *nix platform). Replace the path sensor_path with 
the path to the <Sensor installation directory>, e.g., /home/aroracle/ASIappra-
dar/sensor




                      Application Security, Inc.                                                       300
  3. Copy the modified file (arstart in this example) from the util subdirectory to 
     the appropriate platform‐specific subdirectory (listed in the following table). 

                 *nix Platform                     Symbolic Links Commands

            AIX (Oracle and          /etc/arstart
            DB2)
            HP‐UX (Oracle and        /sbin/init.d/arstart
            DB2)
            Red Hat Enterprise       /etc/init.d/arstart
            Linux (Oracle and 
            DB2)
            Solaris (Oracle and      /etc/init.d/arstart
            DB2)

  4. If you are running a host‐based Sensor for:
      • Oracle, then change the group of the arstart file to the Oracle DBA group 
      (typically dba), and set the permissions to 750. To do so, run the following 
      respective commands:
          -# chgrp dba arstart
          -# chmod 750 arstart
      • DB2, change the group to the DB2 admin group (usually db2grp1) by 
      running the following command: # chgrp db2grp1 arstart




301                   Application Security, Inc.
                        Appendix S: DbProtect Requirements for Sybase ASE




5. Create symbolic links to the arstart script in the appropriate run‐level script 
   directories (as per the following examples). 

                 *nix Platform                     Symbolic Links Commands

           AIX                         # ln -s /etc/arstart /etc/rc.d/
                                       rc2.d/S99arstart
                                       # ln -s /etc/arstart /etc/rc.d/
                                       rc2.d/K01arstart

           HP‐UX                       # ln -s /sbin/init.d/arstart /sbin/
                                       rc3.d/S990arstart
                                       # ln -s /sbin/init.d/arstart /sbin/
                                       rc3.d/K001arstart

           Red Hat Enterprise          # ln -s /etc/init.d/arstart           /etc/
           Linux                       rc.d/rc3.d/S99arstart
                                       # ln -s /etc/init.d/arstart           /etc/
                                       rc.d/rc5.d/K01arstart
                                       # ln -s /etc/init.d/arstart           /etc/
                                       rc.d/rc5.d/S99arstart
                                       # ln -s /etc/init.d/arstart           /etc/
                                       rc3.d/K01arstart

           Solaris                     # ln -s /etc/init.d/arstart /etc/
                                       rc3.d/S99arstart

The specific link names (e.g., S99arstart) are dependent on the specific configuration 
of your database server. You must execute the arstart script right after the startup 
script for Oracle (typically dbora) or DB2 (typically db2start).

Appendix S: DbProtect Requirements for Sybase
ASE
The DbProtect Sensor does not install any kernel driver code on your system; it relies 
on the monitoring and auditing facilities supplied by each database vendor.



                        Application Security, Inc.                                    302
  In order to perform its task, the host sensor monitoring Sybase ASE requires cer‐
  tain privileges and database features.

  Sybase Sybsecurity

  The Sybase security (sybsecurity) feature must be installed. The DbProtect Sensor 
  uses the audit tables provided by this feature to capture database events, which 
  are then matched against the Sensor policies implemented by the user. Installation 
  is a one‐time task, which must be done by a Sybase administrator before the sen‐
  sor is run.

  Audit Tables

  Sybase guidelines dictate that at least two audit tables should be used, and that 
  each table should be on its own device. The maximum number of audit tables is 
  eight. For Sensor 3.14 and below, using two audit tables is recommended.

  Threshold Procedure

  A threshold procedure controls the switching between audit tables when the 
  active audit table becomes nearly full.

  Current versions of the sensor manage rollover between audit tables and the trun‐
  cation of tables using a threshold of 5000 records. An override option can be used 
  to change this threshold.

  Sybase SSO_Role

  The DbProtect Sensor must execute sp_configure to manipulate audit settings; the 
  Sybase sso_role is necessary for execution of sp_configure.




303                  Application Security, Inc.
                      Appendix S: DbProtect Requirements for Sybase ASE




Ownership of the Sybsecurity Database

The DbProtect Sensor must control the rollover and truncation of audit tables; owner‐
ship of the sybsecurity database is necessary to accomplish this.

Audit cmdtext Option

The DbProtect Sensor activates the audit cmdtext option for all users. The sensor 
requires this option so that its Rule Engine can match customer‐specified policies to 
executed SQL.

Audit Table Size

The DbProtect Sensor requires at least 20 mb of storage for each audit table, although 
larger amounts are recommended for a busy production database. For sites with 
existing audit configurations that do not use the audit cmdtext option, you should 
consider expanding the size of audit tables by at least 50 percent.




                      Application Security, Inc.                                   304
305   Application Security, Inc.
Chapter 1             Introduction
About DbProtect: The Enterprise Solution for
Database Security
DbProtect is a database security, risk and compliance application designed to meet 
the needs of companies with large heterogeneous database environments. DbPro‐
tects’s IT risk management framework, security controls, continuous controls moni‐
toring, and governance for databases make it the leading solution on the market 
today.

DbProtect is a centrally‐managed enterprise solution that uses a proven methodology 
for information assurance.  It is built on the industry’s leading and most comprehen‐
sive database security knowledgebase—called SHATTER—which accurately identi‐
fies vulnerabilities, risks, and actual threats.

DbProtect accomplishes the following to secure enterprise data:

                                   DISCOVERY – Identifies and locatates all data‐
                                   bases on a given system

                                   CLASSIFICATION – Identifies risks to business 
                                   and development policies

                                   ASSESSMENT – Analyzes database structures 
                                   for security risks, and determines what privi‐
                                   leges have been assigned to users

                                   PRIORITIZATION – Creates a plan to mitigate 
                                   risks

                                   FIX – Executes the plan and fixes the violations
                       Introduction




    MONITORING – Applies compensating controls where a fix cannot be applied

    The DbProtect platform protects enterprise organizations around the world from 
    internal and external threats, while also ensuring that those organizations meet or 
    exceed regulatory compliance requirements. At its core, DbProtect is built on 
    tools devleoped from the SHATTER Knowledgebase, including: Asset Manage‐
    ment; Policy Management; Vulnerability Management; Rights Management; Con‐
    figuration & Patch Management; Audit & Threat Management; and Analytics & 
    Reporting.

    Subjects Discussed in This Guide
    This guide consists of the following high‐level topics:
       •Asset Management
       •Vulnerability Management
       •Rights Management
       •Audit and Threat Management
       •DbProtect Analytics
       •Compliance Packs
       •Data Sources


    Intended Audience
    This guide is intended for persons responsible for day‐to‐day usage of DbProtect. 
    Typically, those responsible for installing DbProtect have the following (some‐
    times overlapping) job roles:
       •System Administrators
       •Network Administrators
       •Database Administrators
    System Administrators
    System Administrators maintain and operate a computer system and/or network. 
    Their duties vary from one organization to another. System administrators are 



2                      Application Security, Inc.
usually charged with installing, supporting, and maintaining servers or other com‐
puter systems, and planning for and responding to service outages and other prob‐
lems. Other duties may include scripting or light programming, project management 
for systems‐related projects, supervising or training computer operators, and han‐
dling computer problems beyond the knowledge of technical support staff.
Network Administrators
Network Administrators are responsible for the maintenance of the computer hard‐
ware and software that comprises a network. This normally includes the deployment, 
configuration, maintenance and monitoring of active network equipment. Network 
administration commonly includes activities and tasks such as network address 
assignment, assignment of routing protocols and routing table configuration, as well 
as configuration of authentication and authorization‐directory services. A network 
administrator’s duties often also include maintenance of network facilities in individ‐
ual machines, such as drivers and settings of personal computers, as well as printers 
and so on. Network administrators are also responsible for the security of the net‐
work and for assigning IP addresses to the devices connected to the networks. 
Database Administrators
Database Administrators (DBAs) are responsible for the environmental aspects of a 
database. In general, these include:
   • Recoverability ‐ creating and testing backups
   • Integrity ‐ verifying or helping to verify data integrity
   • Security ‐ defining and/or implementing access controls to the data
   • Availability ‐ ensuring maximum uptime
   • Performance ‐ ensuring maximum performance
   • Development and testing support ‐ helping programmers and engineers to 
   efficiently utilize the database

The role of a DBA has changed according to the technology of database management 
systems (DBMSs), as well as the needs of the database owners.




                      Application Security, Inc.                                     3
                     Introduction




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




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

    For information on minimum system requirements and installation instructions 
    for the Console, see the DbProtect Installation Guide.



4                    Application Security, Inc.
Scan Engines
DbProtect’s network‐based, vulnerability management scan engines discover data‐
base applications within your infrastructure and assesses their security strength. 
Backed by a proven security methodology and extensive knowledge of application‐
level vulnerabilities, DbProtect locates, examines, reports, and fixes security holes 
and misconfigurations. Scan engines scan your databases for vulnerabilities, and 
allow you to perform penetration (pen) tests and audits against them.

Target databases (on Windows) include:
   •   Oracle
   •   Oracle Application Server
   •   SQL Server
   •   Lotus Notes/Domino
   •   Sybase
   •   DB2
   •   DB2 on the Mainframe
   •   MySQL

Sensors

Sensors deliver database‐specific protection and alerting for best‐in‐class protection 
of enterprise organizations. You can fine‐tune your event detection parameters and 
customize which audit and security events are monitored by DbProtect. This helps 
you focus security efforts on relevant information, while bypassing false positives 
and irrelevant events. DbProtect’s ASAP Updates ensure that protection remains up‐
to‐date as new vulnerabilities are identified and patches are released. Comprehen‐
sive policies and rules definitions, informed by industry best practices, enable secu‐
rity auditing and documentation specific for enterprise environments.

For information on minimum system requirements and installation instructions for 
Sensors, see the DbProtect Installation Guide.




                       Application Security, Inc.                                        5
                      Introduction




    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.

    Host-Based Sensors

    The table below lists all supported host‐based database/OS combinations. 


                                     DB                 OS

                      SQL SERVER                   WINDOWS
                      DB2                          LINUX
                                                   SOLARIS
                                                   AIX
                                                   WINDOWS
                      ORACLE                       LINUX
                                                   SOLARIS
                                                   AIX
                                                   HP‐UX
                                                   WINDOWS
                      SYBASE                       SOLARIS
                                                   AIX




6                     Application Security, Inc.
Network-Based Sensors

Network‐based Sensors allow you to monitor Windows‐based Sybase, Oracle, and 
DB2 on the network. The table below lists supported database/OS combinations, and 
links you to the installation steps. 


                               DB                       OS

                     DB2                       WINDOWS
                     SYBASE
                     ORACLE


Logging In to the DbProtect Console
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 version (5.2 or higher).

     Note:   You must have the Java Runtime Environment (JRE) SE 6 Update 11 
             installed in order to connect to the DbProtect Console via a web 
             browser.


Logging In to the Console

To use a browser to connect to the DbProtect Console:
1.   Enter https://ConsoleServer:Port in the Address line, where:
     ConsoleServer is the hostname or IP Address of the Console server




                       Application Security, Inc.                                  7
                        Introduction




       Port is the port number that the Console Management Server has been 
       configured to provide service on. Typical DbProtect Console installations do 
       not run on the default web server ports for security reasons.
             ‐example: https://dbprotect_server:20080
             ‐example: https://192.168.1.5:20080

    A Security Alert message appears, prompting you to accept a security certificate 
    from Application Security, Inc. DbProtect uses this certificate to communicate 
    with users over a secure channel.

     Note:     If you experience difficulty logging into the DbProtect Console and 
               connecting to DbProtect, you may need to troubleshoot the Java Run‐
               time Environment (JRE) security settings on your Internet Explorer 6 or 
               greater web browser. For more information on a workaround, see Trou‐
               bleshooting the Java Run Time Environment (JRE) Security Settings on 
               Internet Explorer 6 or Troubleshooting the Java Run Time Environment 
               (JRE) Security Settings on Internet Explorer 7.




8                       Application Security, Inc.
2. Click OK to display the DbProtect Console login page.




3. In the Username field, enter your DbProtect user name. You can use any of the fol‐
   lowing formats:
      username: local user
      <computername>\username
      <netbios domain name>\username
      <dns domain name>\username
      username@<dns domain name>




                      Application Security, Inc.                                   9
                       Introduction




     4. In the Password field, enter your DbProtect password.
     5. Use the Domain drop‐down menu menu to select your domain, or manually 
        enter a domain in the Domain field.

      Note:    DbProtect is designed to use only Secure Sockets Layer (SSL) commu‐
               nication, which encrypts your user name and credentials prior to 
               transmission to DbProtect. DbProtect then uses the Windows Authen‐
               tication subsystem to verify the credentials.

     6. Click Login to display the DbProtect Console. 




     Logging In to the Console Using Single Sign-On
     Starting with version 6.1, 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 via Internet Explorer 6.0 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.




10                     Application Security, Inc.
There are numerous benefits to implementing SSO. For example, SSO reduces the 
proliferation of user accounts and passwords and enables a more secure environ‐
ment. 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 config‐
uration files. For more information, see the DbProtect Administrator’s Guide.
1.   To log into the DbProtect Console using SSO:
      • Open Internet Explorer 6.0 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 message appears, prompting you to accept a security certificate from 
Application Security, Inc. DbProtect uses this certificate to communicate with users 
over a secure channel.

Caution!       If an “access denied” message appears, prompting you to enter your 
               credentials, this means you don’t have access to the DbProtect system, 
               even though you’re a valid Windows user. If this happens, contact your 
               DbProtect administrator to obtain access to the DbProtect system.




                         Application Security, Inc.                                    11
                         Introduction




Hint:          If you have difficulty logging into the DbProtect Console and connecting to 
               DbProtect, you may need to troubleshoot the Java Runtime Environment 
               (JRE) security settings on your Internet Explorer 6 or greater web browser. 
               For more information on a workaround, see Troubleshooting the Java Run 
               Time Environment (JRE) Security Settings on Internet Explorer 6 or Trouble‐
               shooting the Java Run Time Environment (JRE) Security Settings on Internet 
               Explorer 7.

               Another possible solution is to clear your Java cache. For more information, 
               see Clearing Your Java Cache.

     2.   The DbProtect Console appears; more information on navigating the 
          Console, see Global Navigation in DbProtect.




     Troubleshooting Your DbProtect Console Login
     If you have trouble logging on to the DbProtect console, you may need to trouble‐
     shoot your security settings or change your browser configuration.

     This topic consists of the following sub‐topics:
          •Troubleshooting the Java Run Time Environment (JRE) Security Settings on 
          Internet Explorer 6



12                       Application Security, Inc.
      •Troubleshooting the Java Run Time Environment (JRE) Security Settings on 
      Internet Explorer 7
      •Clearing Your Java Cache
      •Adding the DbProtect URL to Your List of Trusted Intranet Sites In Internet 
      Explorer

Troubleshooting the Java Run Time Environment (JRE) Security
Settings on Internet Explorer 6
If you are experiencing difficulty logging into the DbProtect Console, you may need 
to troubleshoot the Java Runtime Environment (JRE) security settings on your 
Internet Explorer (IE) 6 or greater web browser.
If your web browser is IE 6, you may not have Active X controls and “enable third‐
party browser extensions” enabled. If this is the case, you will encounter an error 
message when you attempt to authenticate, and you will be unable to log in to the 
DbProtect Console.

Note:      The security settings described in this section should be the default values in 
           your IE 6 web browser. You should only change the settings if you’re 
           experiencing difficulty logging into the DbProtect Console.

To enable proper Active X controls and “enable third‐party browser extensions” 
security settings on IE 6:
1.   Launch IE 6.
3.   Do the following to display the Security Settings dialog box:
      •
      Select Tools > Internet Options. 
      •
      Click the Security tab.
      •
      Click Custom Level.
2. Set the following security settings to Enable or Prompt:
    • Download signed ActiveX controls
    • Run ActiveX controls and plug‐ins.




                        Application Security, Inc.                                      13
                        Introduction




     3. Click OK.
     4. Click the Advanced tab.

     The Security Settings dialog box appears.




     5. Check Enable Third‐party browser extensions (requires restart).
     6. Click OK.
     7. Close and re‐launch IE 6.

     Try to log back into the DbProtect Console. If you continue to experience trouble, 
     contact Application Security, Inc. Customer Support at support@appsecinc.com.

     Troubleshooting the Java Run Time Environment (JRE) Security
     Settings on Internet Explorer 7

     If your web browser is IE 7, JRE 1.6 may be disabled and/or multiple JREs may be 
     enabled on your client (i.e., the location from which your IE 7 browser is running). 
     JRE 1.6 must be enabled in order for you to connect to the DbProtect Console. If 
     JRE 1.6 is disabled, or if multiple JREs of different versions are enabled on your 
     client, then you will encounter an error message when you attempt to authenti‐
     cate, and you can’t log in to the DbProtect Console.



14                      Application Security, Inc.
To ensure JRE 1.6 is enabled, and to temporarily disable multiple JREs on your client 
machine (using IE 7), do the following:
1. Launch IE 7.
2. Do the following to display the Settings dialog box:
    • Select Tools > Internet Options
    • Click the Advanced tab
3. Scroll down to the Java (Sun) portion of the dialog box and verify the following:
    • JRE 1.6 is enabled (i.e., the box must be checked)
    • multiple JRE installations are listed

JRE 1.6 must be enabled in order for you to connect to the DbProtect Console. If it is 
not, check the JRE 1.6 box.

If JRE 1.6 is enabled, and other JRE versions are also enabled, then you must tempo‐
rarily disable them by un‐checking the boxes.
4. Click Apply.
5. Click OK.
6. Close and re‐launch IE 7.

Try to log back into the DbProtect Console. If you continue to experience trouble, 
contact Application Security, Inc. Customer Support at support@appsecinc.com.

Clearing Your Java Cache

If you are experiencing difficulty logging into the DbProtect Console, you may need 
to clear your Java cache. Application Security, Inc. also recommends you clear your 
Java cache after an upgrade. The Java cache does not get automatically cleared fol‐
lowing a reboot.

To clear your Java cache:
1.   Choose Start > Control Panel to display the Control Panel.




                        Application Security, Inc.                                     15
                         Introduction




     2. Double click the Java icon to display the Java Control Panel dialog box.
     3. With the default General tab selected, click Settings... (in the Temporary Inter‐
        net Files section of the dialog box) to display the Temporary Files Settings dia‐
        log box.
     4. Click Delete Files... to clear your Java cache.

     Close your web browser and attempt to log into the DbProtect Console again.

     Adding the DbProtect URL to Your List of Trusted Intranet Sites
     In Internet Explorer

     In order for single sign‐on (SSO) to function properly, you may need to configure 
     Internet Explorer by adding the DbProtect URL to your list of trusted intranet 
     sites.

Note:          The following steps explain how to configure Internet Explorer 7. Steps may 
               vary slightly for other browser versions.

     In Internet Explorer, do the following:
     1.   Choose Tools > Internet Options to display the Internet Options dialog box.




16                       Application Security, Inc.
2. Select the Security tab.
3. Select Local Intranet from the list of zone sites (at the top of the Internet Options 
   dialog box).
4. Click Sites to display a Local intranet pop‐up.
5. Click Advanced to display a second Local intranet pop‐up.
6. Add https://<dbprotecturl> to the Add this website to the zone field, where 
   <dbprotecturl> is the DbProtect Console URL.
7. Click Add to add DbProtect to your list of trusted local intranet sites.
8. Click Close to close the second Local intranet pop‐up.
9. Click Close to close the first Local intranet pop‐up.
10.Click Apply on the Internet Options dialog box to apply your changes.
11.Click OK to close the Internet Options dialog box.

Logging In to DbProtect After Session Timeout
When there is no activity on your machine for a specified period of time, your session 
times out and an Inactivity message appears. To return to the login screen and log 
back in to DbProtect, click Login now. 




Global Navigation in DbProtect
Application tabs appear in the upper portion of every DbProtect Console page. These 
tabs allow you to toggle between the different components of DbProtect.




                       Application Security, Inc.                                      17
                        Introduction




     Click:
        • Asset Management to view and manage all of your database assets.
        • Vulnerability Management to display and use DbProtect Vulnerability 
        Management.
        • Rights Management to display the security best practice dashboards for 
        managing user rights.
        • Audit & Threat Management to display and use DbProtect Audit and 
        Threat Management.
        • Analytics & Reporting to use DbProtect Analytics and run DbProtect 
        reports; for more information, see the DbProtect Analytics User’s Guide.
        • Administration to import content packs and enable compliance pack 
        functionality in DbProtect, and to view your DbProtect system information.

     The upper right portion of every Console page displays your User/Organization 
     information: your logged‐in user ID and your associated “effective” Organiza‐
     tion. 

     Every User ID is associated with at least one Organization. an organization is a 
     logical grouping of applications that allows you to manage User rights and capa‐
     bilities within DbProtect. If you are a DbProtect Super Admin, DbProtect Admin, 
     Vulnerability Management Admin, or an Audit and Threat Management Admin, 
     then DbProtect allows you to create Organizations and define a set of IP ranges 
     and Policies for each Organization (which you can override at the User or Group 
     level). For more information, see DbProtect Organizations, Users, and User Roles.

     If you are a DbProtect Super Admin, DbProtect Admin, Vulnerability Manage‐
     ment Admin, or an Audit and Threat Management Admin ‐‐ and your User ID is 
     associated with multiple Organizations ‐‐ you can click the “Effective” Organiza‐
     tion Selector icon (labeled below) to display the “Effective” Organization Selector 
     dialog box and change your “effective” Organization. 




18                      Application Security, Inc.
               Logged-in as                                 “Effective”
               user ID           “Effective” Organization   Organization Selector
                                                            icon




DbProtect Administration: Content/Compliance
Packs, Data Sources, and System Information
Using the DbProtect Administration Page

When you click the Administration application tab from any DbProtect console 
page, the DbProtect administration page appears. This page allows you to import 
content packs and enable compliance pack and data source functionality in DbPro‐
tect, and to view your DbProtect system information.




The Administration page consists of two panes: the navigation pane and the viewing 
pane.




                       Application Security, Inc.                                   19
                        Introduction




     The navigation pane allows you to select whether you want to work with Content 
     Packs, Data Sources, or view your DbProtect System information.

 Hint:      In the navigation pane, you can click the Expand All link to expand all view‐
            able content pack and system information, or click the Collapse All link to 
            collapse viewable content pack and system information.

     The viewing pane displays information about:
        • Your imported content packs (if you click the Content Packs > View Content 
        link in the navigation pane); for more information, see Viewing Your Available 
        Imported Compliance Content Packs.
        The viewing pane also allows you to import content packs (if you click the 
        Content Packs > Import Content link in the navigation pane); for more 
        information, see Importing a Compliance Content Pack.
        • Data Sources, such as Oracle Audit Vault; for information, see Data Sources. 
        The viewing pane also allows you to register data sources (for example, you 
        can register Oracle Audit Vault by clicking the Data Sources > Audit Vault link 
        in the navigation pane); for more information, see Registering Oracle Audit 
        Vault as a DbProtect Data Source.
        • The specific versions of your installed DbProtect suite components (if you 
        click the System > About DbProtect link in the navigation pane); for more 
        information, see Viewing Your DbProtect System Information.

     Working with Content and Compliance Packs

     Compliance packs are optional DbProtect add‐ons that contain regulatory com‐
     pliance‐level views of your database environment designed to help you track, 
     manage, and meet compliance requirements. Compliance packs work in conjunc‐
     tion with DbProtect Analytics (version 1.3 or higher of which must be installed), 
     allowing you to review and analyze compliance progress with additional high‐
     level Dashboards and report the results of testing of database security controls in 
     the correct compliance language context (e.g., information assurance controls and 
     identifiers).




20                      Application Security, Inc.
Compliance packs simplify the mapping between established test controls and the 
automated methods and procedures within DbProtect, which helps to save a tremen‐
dous amount of analysis time. Moreover, content packs offer additional Policies, 
Dashboards, reports, export formats, and independent resource information where 
applicable.

In order to enable compliance packs within DbProtect, you must first obtain and 
import content packs—Application Security, Inc.‐provided .zip files that, when suc‐
cessfully imported into DbProtect, add reports geared toward helping you achieve 
regulation‐specific compliance (for example, DISA‐STIG). 

The Compliance Packs chapter provides detailed information about importing con‐
tent packs, working with compliance packs, running compliance pack reports, and 
more.

Viewing Your DbProtect System Information

Click the System > About DbProtect link (in the navigation pane of the Administra‐
tion page) to display your current DbProtect system information (including compo‐
nent name, version, and last update).

Note:     Not all of the following components may be installed. For more information 
          on DbProtect and DbProtect Analytics components, including minimum 
          system requirements, see the DbProtect Installation Guide and the DbProtect 
          Analytics Installation and User’s Guide.


DbProtect Organizations, Users, and User Roles
This section consists of the following topics:
   •Organizations and Users
   •User Roles and Associated Privileges
   •Adding an Organization
   •Editing an Organization
   •Removing an organization


                       Application Security, Inc.                                 21
                         Introduction




        •Setting Your “Effective” Organization
        •Configuring SMTP Mail Server Information for your organization
        •Adding a Group
        •Editing a Group
        •Removing a User
        •Adding a User
        •Editing a User
        •Removing a User
        •Creating a DbProtect Audit and Threat Management Policy


     Organizations and Users
     Organizations are logical groupings of applications that allow you to manage 
     user rights and capabilities within DbProtect and define a set of IP ranges and 
     policies for each Organization (which you can override at the User or Group 
     level).
     The upper right portion of every console page displays your user/organization 
     information, i.e., your logged‐in user ID and your associated “effective” 
     organization.
                   Logged-in as                                    “Effective”
                   user ID              “Effective” Organization   Organization Selector
                                                                   icon



     Every User ID is associated with at least one organization, and all users can 
     change their “effective” organization.

     DbProtect Users are individuals that have certain rights within the DbProtect sys‐
     tem. You can also add Groups to DbProtect. Users and Groups are Windows enti‐
     ties taken from either the Active Directory1 or your local system. You must 
     explicitly add Users and Groups to DbProtect in order for these individuals to use 
     the product.

     The following diagram illustrates three differently‐configured Organizations, and 
     the subordinate Groups/Users that belong to each Organization.



22                       Application Security, Inc.
If you are a DbProtect Super Admin, DbProtect Admin, Vulnerability Management 
Admin, or an Audit and Threat Management Admin, you can create Organizations 
and add Users and Groups to them.

Note:   If the DbProtect Scan Engine service does not run as a domain user, then all 
        users must be non‐domain users.

User Roles are comprised of specific privileges assigned to each DbProtect User (or 
Group) in an organization.




1.Active Directory is an implementation of LDAP directory services for Windows 
environments. Active Directory allows administrators to assign enterprise‐wide 
Policies, deploy programs to many computers, and apply critical updates to an entire 
Organization. Active Directory stores information and settings relating to an 
organization in a central, organized, accessible database. Active Directory networks 
can vary from a small installation with a few hundred objects, to a large installation 
with millions of objects.


                      Application Security, Inc.                                    23
                           Introduction




     User Roles and Associated Privileges

     DbProtect is comprised of Organizations, and within those Organizations, 
     assigned Users.

     Each User has an assigned User Role. The available User Roles are:
        •   DbProtect (DBP) Super Admin
        •   DBP Admin
        •   DBP View
        •   Vulnerability Management (VM) Admin
        •   VM Basic
        •   VM View
        •   Audit and Threat Management (ATM) Admin
        •   ATM View.

     The following table lists privileges associated with each User role.



 Caution!       If the Console is running as a local administrator, there are User 
                management/authentication limitations. When adding a Group/User, you 
                can only populate the list of Groups from your “local system”, not from 
                other domains. In addition, you cannot log on to the Console as a domain 
                User. For more information, see Working with Scan Engines.

     DbP = DbProtect, VM = Vulnerability Management, ATM = Audit and Threat Management 



                                       DbP
                                               DbP       VM      ATM     VM     DbP     VM    ATM
              Privileges              Super
                                              Admin     Admin   Admin   Basic   View   View   View
                                      Admin

 Register a Scan Engine.                  

 Unregister a Scan Engine.                

 Edit a Scan Engine.                      




24                         Application Security, Inc.
Export Vulnerability                                                   
Management credentials 
to file via a Job template 
or Credential Profile.
Import Vulnerability                                                   
Management credentials 
from file via a Job 
template or Credential 
Profile.
Create or modify a                                                     
Vulnerability 
Management Credential 
Profile.
Set an effective                                                                         
Organization.
                                          DBP
                                                  DBP     VM      ATM     VM     DBP     VM    ATM
             Privileges                  Super
                                                 Admin   Admin   Admin   Basic   View   View   View
                                         Admin

Add, edit, and remove an                                       
organization.
Add, edit, and remove a                                   
User or Group.
Note:Login user must have a higher/
     equal privilege to edit or remove
     the selected user.

Edit or remove an                                         
application from the 
Vulnerability 
Management Dashboard.
Add an application to the                                              
Vulnerability 
Management Dashboard.


                               Application Security, Inc.                                      25
                     Introduction




 Create, edit, delete,                                 
 schedule, manage, or 
 cancel a Vulnerability 
 Management Job.
 Delete a Report.                                     

 Create, view, edit, or                                        
 schedule a Report.
 View Vulnerability                                          
 Management Job results 
 and Job history.
 View Sensors.                                      

 Register a Sensor.                                 

 Configure a Sensor and                             
 deploy the configuration 
 information.
 Delete configured                                  
 Sensors.
 View and monitor the                                             
 “health” of Sensors (via 
 the Sensor Manager).
 Unregister a Sensor.                               




26                   Application Security, Inc.
                              DBP
                                      DBP      VM       ATM     VM     DBP     VM    ATM
         Privileges          Super
                                     Admin    Admin    Admin   Basic   View   View   View
                             Admin

Manually remove a                                     
Sensor.
Monitor Alerts.                                                                   

Acknowledge and archive                               
Alerts.
View Policies.                                                                    

Create a Policy.                                      

Edit a Policy.                                        

Import a Policy.                                      

Export a Policy.                                      

Deploy a Policy.                                      

Delete a Policy.                                      

View .                                                                            

Edit a Filter.                                        

Delete a Filter.                                      

Import a Filter.                                      

Export a Filter.                                      

Install and use                                      
Compliance Packs.

DbProtect User Role Inheritance

In DbProtect, Users may belong to multiple Organizations. Their membership may 
be defined as the role appropriate for a given Organization (i.e., DbProtect Super 
Admin, DbProtect Admin, DbProtect View, Vulnerability Management Admin, Vul‐
nerability Management Basic, Vulnerability Management View, and Audit and 



                      Application Security, Inc.                                     27
                             Introduction




     Threat Management Admin). A User’s membership to an organization may be 
     defined directly by explicit enumeration, or inherited by group membership; for 
     more information, see Organizations and Users.

     There are cases where more than one role or membership may be valid for a user ‐
     ‐ depending on the User’s Organizational membership and roles. When Users 
     have more than one possible Organizational membership, they are initially placed 
     in a default “effective” Organization. All Users, regardless of User Role, can 
     change their “effective” Organization. You can also set a newly‐selected Organi‐
     zation as your default “effective” Organization.

     Once Users sets their “effective” Organization, DbProtect determines whether the 
     Users’ membership to the “effective” Organization can be obtained via multiple 
     paths. If so, DbProtect grants the highest possible User Role defined for the User ‐‐ 
     within the selected “effective” Organization ‐‐ to the User.

     The following tables illustrate the effective User Role and Organizational mem‐
     bership under a variety of conditions. 


                             Parent
     Organization                                   User/group                     User Role
                           Organization

 US                    Global               Auditors (Joe, Jane,      Vulnerability Management 
 Operations            Operations           Mary)                     Basic User
 US                    Global               Administrators (Joe,      DbProtect Admin
 Operations            Operations           Jim, Mike)
 Operations            Corporate            Administrators (Joe,      DbProtect Super Admin
                                            John, Sue)


         User logging in         “Effective” Organization               User Role granted

     Jane                       US Operations               Vulnerability Management Basic User
     Jim                        US Operations               DbProtect Super Admin




28                           Application Security, Inc.
       User logging in    “Effective” Organization              User Role granted

 Joe                      Global Operations          Super Admin
                          US Operations              DbProtect Admin

Understanding the Manage Organizations and Users page

The Organizations and Users page allows you to create logical and hierarchical orga‐
nizations. You can define a set of IP ranges and policies for each organization (which 
you can override at the user or group level). your organizations can be exclusive and 
isolated from other organizations.

After you create organizations, you can create subordinate users and groups. Users 
and groups are Windows entities taken from either the Active Directory or your local 
system.




The Organizations and Users page allows you to add, edit, remove, and toggle 
between organizations; add, edit, and remove groups; and add, edit, and remove 
users.

The pane of the Organizations and Users page is divided into two portions:
   • Parent Organization. This portion of the pane displays your parent 
   organization. You can right‐click the parent organization to add child 
   organizations, add users and groups, edit organizations, and remove 
   organizations.
   • Organization Users and Groups. The columns in this portion of the pane 
   display the following information about users and groups in the organization you 
   have highlighted:


                         Application Security, Inc.                                 29
                         Introduction




             ‐Username. The usernames of all users in your organization.
             ‐Role. The role of the associated group (i.e., DbProtect Super Admin, 
             DbProtect Admin, DbProtect View, Vulnerability Management Admin, 
             Vulnerability Management Basic, Vulnerability Management View, and 
             Audit and Threat Management Admin)
             ‐Domain. The associated user’s network domain.
             ‐Type. The role of the associated user (i.e., DbProtect Super Admin, 
             DbProtect Admin, DbProtect View, Vulnerability Management Admin, 
             Vulnerability Management Basic, Vulnerability Management View, and 
             Audit and Threat Management Admin)..
 Hint:        Highlight an organization in the Parent Organization portion of the Man‐
              age Organizations and Users page to display its subordinate users and 
              groups, and to activate control buttons and menu items.


     Adding an Organization

     To add an organization: 
     1.   Do one of the following to display the Manage Organizations and Users page:
          • Choose Admin > Organizations and Users from the menu
          • Click the Organizations and Users tab




30                       Application Security, Inc.
4.   Do one of the following to display the Organization Setup dialog box:
      • Click Add Organization in the Controls toolbar on the Manage Organizations 
      and Users page
      • Right‐click an organization (in the Parent Organization portion of the Manage 
      Organizations and Users page) and choose Add Organization




2. Select the General tab (selected by default).
3. In the Organization Name portion of the Organization Setup dialog box, enter the 
   name of your new organization in the Name field.
4. In the IP Range portion of the Organization Setup dialog box:
    • Enter an IP address range in the From: and To fields. This is the IP range that 
    members of your organization are permitted to work within when they schedule 
    a Discovery, Audit, Penetration Test, or Report Job. For example: If you specify the 
    range 127.0.0.1 through 127.0.0.255, then members of your organization are 
    only permitted to schedule Jobs within this range of IP addresses.
    • Click Add to add the IP addresses to the list of IP addresses that members of 
    your organization are permitted to work within.


                        Application Security, Inc.                                    31
                        Introduction




        • Click Load IPs From File to display an Open dialog box and upload a 
        standard, line‐delimited text file. Unlike the format described in Discovery 
        Jobs, IP addresses for organizations do not require ports. You can use any of 
        the following formats:
           ‐ip (for example, 192.168.1.1)
           ‐ip-ip (for example, 192.168.1.1-192.168.1.255)
           ‐Classless Inter Domain Routing (CIDR) notation, i.e., ip/network prefix 
           (for example, 192.9.205.22/18); for more information on CIDR notation, 
           see http://infocenter.guardiandigital.com/manuals/IDDS/node9.html

     To remove an IP address range from the list, highlight the range and click 
     Remove.
     5. In the Policies portion of the Create Organization dialog box, highlight which 
        Penetration Test and Audit Policies the Users in your organization can use (or 
        un‐highlight restricted Policies).

     Click the:
        • Pen Test tab, and highlight which Penetration Test Policies the organization 
        users can use (or un‐highlight restricted Penetration Test Policies)
        • Audit tab, and highlight which Audit Policies the Organization Users can 
        use (or un‐highlight restricted Audit Policies)
        • <CTRL> keyboard button to highlight non‐sequential Policies..
 Hint:      You can further restrict or enable penetration test and audit policy access at 
            the individual user level. For more information, see Adding a User and Edit‐
            ing a User.

     6. Click Create to create your new organization.

     The new organization appears in the Parent Organization section of the Manage 
     Organizations and Users page.




32                      Application Security, Inc.
Editing an Organization

To edit an organization: 
1. Do one of the following to display the Manage Organizations and Users page:
    • Choose Admin > Organizations and Users from the menu
    • Click the Organizations and Users tab.
2. Right‐click an organization (in the Parent Organization portion of the Manage 
   Organizations and Users page) and choose Edit Organization to display the 
   Organization Setup dialog box.




Select the General tab (selected by default).

Note:    Click the E‐Mail tab to configure your organization’s SMTP email server 
         information; for more information, see Configuring SMTP Mail Server 
         Information for your organization.




                      Application Security, Inc.                                    33
                        Introduction




     3. In the Organization Name portion of the Organization Setup dialog box, you 
        can edit the name of your organization in the Name field.
     4. In the IP Range portion of the Organization Setup dialog box:
         • You can edit the IP address range in the From: and To fields. This is the IP 
         range that members of your organization are permitted to work with when 
         they schedule a Discovery, Audit, Penetration Test, or Report Job. 

        Example: If you specify the range 127.0.0.1 through 127.0.0.255, then 
        members of this Organization are only permitted to schedule Jobs within this 
        range of IP addresses.
        • Click Add to add the IP addresses to the list of IP addresses that members of 
        the Organization are permitted to work within.
        • Click Load IPs From File to display an Open dialog box and upload a 
        standard, line‐delimited text file. Unlike the format described in Discovery 
        Jobs, IP addresses for Organizations do not require ports. You can use any of 
        the following formats:
           ‐ip (for example, 192.168.1.1)
           ‐ip-ip (for example, 192.168.1.1-192.168.1.255)
           ‐Classless Inter Domain Routing (CIDR) notation, i.e., ip/network prefix 
           (for example, 192.9.205.22/18); for more information on CIDR notation, 
           see http://infocenter.guardiandigital.com/manuals/IDDS/node9.html

     To remove an IP address range from the list, highlight the range and click 
     Remove.
     5. In the Policies portion of the Organization Setup dialog box, highlight which 
        Penetration Test and Audit Policies the Users in your organization can use (or 
        un‐highlight restricted Policies). 

     Click the:
        • Pen Test tab, and highlight which Penetration Test Policies the Organization 
        Users can use (or un‐highlight restricted Penetration Test Policies)
        • Audit tab, and highlight which Audit Policies the Organization Users can 
        use (or un‐highlight restricted Audit Policies).



34                      Application Security, Inc.
6. Click Save to save your edited Organization.

The edited Organization appears in the Parent Organization portion of the Manage 
Organizations and Users page.

Removing an organization

To remove an organization: 
1. Do one of the following to display the Manage Organizations and Users page:
    • Choose Admin > Organizations and Users from the menu
    • Click the Organizations and Users tab.
2. Right‐click an organization (in the Parent Organization portion of the Manage 
   Organizations and Users page) and choose Edit to display the Remove Organiza‐
   tion? pop‐up.




Click Yes to remove the Organization (and all its members).

The Organization is removed from the Parent Organization portion of the Manage 
Organizations and Users page.

Setting Your “Effective” Organization

The upper right portion of every Console page displays your User and ”effec‐
tive”Organization information, i.e., your logged‐in user ID and your associated 
“effective” Organization.

Every User ID is associated with at least one Organization. If you are a Super User or 
an Admin User, and your User ID is associated with multiple Organizations, you can 
toggle between Organizations.




                      Application Security, Inc.                                    35
                          Introduction




     To set your “effective” Organization:
     1.   To display the Effective Organization Selector dialog box:
           • Click the Effective Organization Selector icon located in the upper right 
           corner of every Console page, or
           • Select File > Organization Selector from the menu.

          The Effective Organization Selector dialog box appears:




     2. Your current “effective” Organization is highlighted. To change your “effec‐
        tive” Organization:
              a.Highlight a different “effective” Organization.

              b.Click the Set Effective Organization button.

     As a result, your User ID and your new, associated “effective” Organization dis‐
     play at the top of every DbProtect portal page.



36                        Application Security, Inc.
Configuring SMTP Mail Server Information for your organization

DbProtect Vulnerability Management allows you to notify others via email when 
DbProtect Vulnerability Management completes a Job. This feature works for all 
types of Jobs, i.e., Discovery, Penetration Test, Audit, and Report Jobs. For more infor‐
mation, see Scheduling email notification upon Job completion.

However, in order to notify others via email when DbProtect Vulnerability Manage‐
ment completes a Job, an Admin or Super Admin must first properly configure your 
organization’s SMTP mail server information. Otherwise, the email notification of Job 
completion feature will not work.

To configure your organization’s SMTP mail server information: 
1.   Do one of the following to display the Manage Organizations and Users page:
     • Choose Admin > Organizations and Users from the menu
     • Click the Organizations and Users tab.




                       Application Security, Inc.                                     37
                       Introduction




     2. Right‐click an organization (in the Parent Organization portion of the Manage 
        Organizations and Users page) and choose Edit Organization to display the 
        Organization Setup dialog box.




38                     Application Security, Inc.
3.   Click the E‐Mail tab to display the The E‐Mail portion of the Organization Setup 
     dialog box.




3. Configure your outgoing SMTP server information.

In the Outgoing Server portion of the dialog box:
      • Enter the name of your outgoing SMTP server in the Outgoing Mail Server 
      (SMTP) field
      • Enter the port number you want to use on your outgoing SMTP server in the 
      Outgoing Server Port (1‐65535) field.




                        Application Security, Inc.                                   39
                       Introduction




        • Check the Use Authentication checkbox if your SMTP server requires 
        authentication in order to send email.

 Note:      Some SMTP servers require authentication in order to send email. 
            Depending on what kind of SMTP server you are using, and how it is 
            configured, this may or may not be the case. If your SMTP server requires 
            authentication in order to send email, then you must enter a valid login/
            password pair, and check the Use Authentication checkbox. However, if you 
            are not sure whether your SMTP server requires authentication, check with 
            your mail administrator.

        If you check the Use Authentication checkbox, you must also enter a valid:
            ‐Username:
            ‐Password:
         • Check the Use SSL checkbox if want to use Secure Sockets Layer (SSL) to 
         encrypt your User name and credentials prior to transmission.
     4. Specify your “from” and “reply to” email addresses.

     In the Other User Information portion of the dialog box, enter your:
        • “from” email address in the From Addess field (i.e., when DbProtect 
        Vulnerability Management completes a Job and notifies your email recipienets 
        via email, this is the “from” email address)
        • “reply to” email address in the Reply To Address field (i.e., when DbProtect 
        Vulnerability Management completes a Job and notifies your email recipienets 
        via email, this is the “reply to” email address).




40                     Application Security, Inc.
5. Specify a maximum attachment size in megabytes (1‐30).

In the Other Options portion of the dialog box, enter the maximum allowable size of 
email attachments (0‐30 megabytes) in the Max Attachment Size in Megabytes (1‐30) 
field. The default value is three megabytes.

Note:     When DbProtect Vulnerability Management completes a Report, the 
          generated email always includes link to the Report ‐‐ even if there is no 
          attachment. In other words, even if the generated Report exceeds the 
          maximum attachment size, your email recipients can still view the Report 
          online.

6. Review your SMTP server settings.
Hint:     Click the Delete E‐Mail Settings button any time to delete all configured 
          email settings.

7. Click Save to save your SMTP server settings.

The Organization Setup dialog box closes and your SMTP server settings are saved.

Adding a Group

If DbProtect Vulnerability Management does not run as a domain user, you must also 
add local (i.e., non‐domain) users.

To add a Group: 
1.   Do one of the following to display the Manage Organizations and Users page:
     • Choose Admin > Organizations and Users from the menu
     • Click the Organizations and Users tab.

The Manage Organizations and Users page displays your existing:
     •Organizations (in the Parent Organization portion of the Manage 
     Organizations and Users page)



                       Application Security, Inc.                                      41
                       Introduction




        •  Users and Groups (in the Organization Users portion of the Manage 
         Organizations and Users page).
     Hint:    Highlight an organization in the Parent Organization portion of the 
              Manage Organizations and Users page to display its subordinate Users 
              and Groups, and to activate the Control buttons and menu items.




     2. Do one of the following to display the Add AppDetective User or Group dia‐
        log box:
         • Click the Add User or Group button in the Toolbars portion of the Manage 
         Organizations and Users page (Controls portion)
         • Right‐click an organization (in the Parent Organization portion of the 
         Manage Organizations and Users page) and choose Add User.




     3. In the User or Group Identity portion of the Add AppDetective User or 
        Group dialog box, do the following:
         • Use the Type drop‐down menu to select Group.



42                     Application Security, Inc.
     •Use the Group Domain drop‐down menu to select the Group’s network domain. 
    Click Populate to display a list of availble groups.
    • Enter or select a Group name. You can:
        ‐manually enter a Group name in the Group Name field (for example, AUDIT
        - U.S.)
        ‐click the Populate button to display a list of available Groups, then select an 
        available Group using the Group Name drop‐down menu.
    • Use the Group Role drop‐down menu to associate the Group with a role (i.e., 
    Super Admin, Admin, Basic User, View User); for more information, see the 
    DbProtect Administrator’s Guide.
4. In the User or Group Accessible Policies portion of the Add AppDetective User 
   or Group dialog box, highlight which Penetration Test and Audit Policies the 
   Group can use (or un‐highlight restricted Policies). 

Click the:
     •Pen Test tab, and highlight which Penetration Test Policies the Group can use 
    (or un‐highlight restricted Penetration Test Policies)
    • Audit tab, and highlight which Audit Policies the Group can use (or un‐
    highlight restricted Audit Policies).
5. Click the Add User or Group button to save your new Group.

The new Group appears in the Organization Users portion of the Manage Organiza‐
tions and Users page.

Editing a Group

If DbProtect Vulnerability Management does not run as a domain User, you must 
also add local (i.e., non‐domain) Users.

To edit a Group: 
1.   Do one of the following to display the Manage Organizations and Users page:
     • Choose Admin > Organizations and Users from the menu
     • Click the Organizations and Users tab.



                       Application Security, Inc.                                     43
                      Introduction




     The Manage Organizations and Users page displays your existing:
        •  Organizations (in the Parent Organization portion of the Manage 
         Organizations and Users page)
         • Users and Groups (in the Organization Users portion of the Manage 
         Organizations and Users page).
     Hint:    Highlight an organization in the Parent Organization portion of the 
              Manage Organizations and Users page to display its subordinate Users 
              and Groups, and to activate the Control buttons and menu items.




     2. Do one of the following to display the Edit DbProtect AppDetective portal 
        Group dialog box:
        • Highlight a Group in the Organization Users and Groups portion of the 
        Manage Organizations and Users page, and choose Organizations and Users 
        > Edit User or Group from the menu
        • Right‐click a Group (in the Organization Users portion of the Manage 
        Organizations and Users page) and choose Edit.
        • Double click a Group (in the Organization Users portion of the Manage 
        Organizations and Users page).




44                    Application Security, Inc.
3. Do the following:
   • Use the User Role drop‐down menu to associate the Group with a different role 
   (i.e., Super Admin, Admin, Basic User, View User); for more information, see the 
   DbProtect Administrator’s Guide.
   • In the lower portion of the Edit AppDetective Console Group dialog box, 
   highlight which Penetration Test and Audit Policies the Group can use (or un‐
   highlight restricted Policies). 

    Click the:
       ‐Pen Test tab, and highlight which Penetration Test Policies the Group can use 
       (or un‐highlight restricted Penetration Test Policies)
       ‐Audit tab, and highlight which Audit Policies the Group can use (or un‐
       highlight restricted Audit Policies).
4. Click Save to save your edited Group.

The edited Group appears in the Organization Users portion of the Manage Organi‐
zations and Users page.

Removing a Group

To remove a Group: 
1.   Do one of the following to display the Manage Organizations and Users page:
     • Choose Admin > Organizations and Users from the menu
     • Click the Organizations and Users tab.

The Manage Organizations and Users page displays your existing:
     •Organizations (in the Parent Organization portion of the Manage 
    Organizations and Users page)
    • Users and Groups (in the Organization Users portion of the Manage 
    Organizations and Users page).
Hint:    Highlight an organization in the Parent Organization portion of the 
         Manage Organizations and Users page to display its subordinate Users and 
         Groups, and to activate the Control buttons and menu items.


                       Application Security, Inc.                                  45
                         Introduction




     2. Do one of the following:
        • Highlight a group in the Organization Users portion of the Manage 
        Organizations and Users page, and choose Organizations and Users > 
        Remove User or Group from the menu
        • Right‐click the group (in the Organization Users portion of the Manage 
        Organizations and Users page) and choose Remove

     The Remove User or Remove Group message appears, prompting you to confirm 
     removal.




     Click Yes to remove the group.

     The group is removed from the Organization Users portion of the Manage Orga‐
     nizations and Users page.

     Adding a User

     To add a user: 
     1.   Do one of the following to display the Manage Organizations and Users page:
          • Choose Admin > Organizations and Users from the menu
          • Click the Organizations and Users tab.

     The Manage Organizations and Users page displays your existing:




46                       Application Security, Inc.
   •  Organizations (in the Parent Organization portion of the Manage 
    Organizations and Users page)
    • Users and Groups (in the Organization Users portion of the Manage 
    Organizations and Users page).
Hint:    Highlight an organization in the Parent Organization portion of the 
         Manage Organizations and Users page to display its subordinate Users and 
         Groups, and to activate the Control buttons and menu items.




2. Do one of the following to display the Add AppDetective User or Group dialog 
   box:
    • Choose Organizations and Users > Add User or Group from the menu
    • Click the Add User or Group button in the Controls portion of the Manage 
    Organizations and Users page
    • Right‐click an organization (in the Parent Organization portion of the Manage 
    Organizations and Users page) and choose Add User.




                      Application Security, Inc.                                  47
                       Introduction




     3. Do the following:
        • Use the Type drop‐down menu to select User.
        • Enter a User name in the User Name field (for example, jsmith).
        • Use the User Domain drop‐down menu to select the User’s network domain.
        • Use the User Role drop‐down menu to associate the User with a role (i.e., 
        Super Admin, Admin, Basic User, View User); for more information, see the 
        DbProtect Administrator’s Guide.
        • In the User or Group Accessible Policies portion of the Add AppDetective 
        User or Group dialog box, highlight which Penetration Test and Audit Policies 
        the User or Group can use (or un‐highlight restricted Policies). 

        Click the:
           ‐Pen Test tab, and highlight which Penetration Test Policies the User can 
           use (or un‐highlight restricted Penetration Test Policies)




48                     Application Security, Inc.
       ‐Audit tab, and highlight which Audit Policies the User can use (or un‐
       highlight restricted Audit Policies).
4. Click the Add User or Group button to save your new User.

The new User appears in the Organization Users portion of the Manage Organiza‐
tions and Users page.

Editing a User

To edit a User: 
1.   Do one of the following to display the Manage Organizations and Users page:
     • Choose Admin > Organizations and Users from the menu
     • Click the Organizations and Users tab.

The Manage Organizations and Users page displays your existing:
     • Organizations (in the Parent Organization portion of the Manage 
     Organizations and Users page)
     • Users and Groups (in the Organization Users portion of the Manage 
     Organizations and Users page).
Hint:     Highlight an organization in the Parent Organization portion of the Man‐
          age Organizations and Users page to display its subordinate Users and 
          Groups, and to activate the Control buttons and menu items.




2. Do one of the following:
   • Highlight a User in the Organization Users portion of the Manage 
   Organizations and Users page, and choose Organizations and Users > Edit User 
   or Group from the menu



                       Application Security, Inc.                                  49
                       Introduction




        • Right‐click a User (in the Organization Users portion of the Manage 
        Organizations and Users page) and choose Edit.
        • Double click a User (in the Organization Users portion of the Manage 
        Organizations and Users page).

     The Edit DbProtect Console User dialog box appears.




     3. Use the User Role drop‐down menu to associate the User with a different User 
        or Group type (i.e., Super Admin, Admin, Basic User, View User); for more 
        information, see the DbProtect Administrator’s Guide.
     4. In the User or Group Accessible Policies portion of the Edit AppDetective 
        Console User dialog box, highlight which Penetration Test and Audit Policies 
        the User can use (or un‐highlight restricted Policies). 

     Click the:
        • Pen Test tab, and highlight which Penetration Test Policies the User can use 
        (or un‐highlight restricted Penetration Test Policies)
        • Audit tab, and highlight which Audit Policies the User can use (or un‐
        highlight restricted Audit Policies).




50                     Application Security, Inc.
5. Click Save to save your edited User.

The edited User appears in the Organization Users portion of the Manage Organiza‐
tions and Users page.

Note:     If DbProtect Vulnerability Management does not run as a domain User, you 
          must also add local (i.e., non‐domain) Users.


Removing a User

To remove a User: 
1.   Do one of the following to display the Manage Organizations and Users page:
     • Choose Admin > Organizations and Users from the menu
     • Click the Organizations and Users tab.

The Manage Organizations and Users page displays your existing:
     • users and groups (in the Organization Users portion of the Manage 
     Organizations and Users page).




2. Do one of the following:
   • Highlight a User in the Organization Users portion of the Manage 
   Organizations and Users page, and choose Organizations and Users > Remove 
   User from the menu
   • Right‐click User (in the Organization Users portion of the Manage 
   Organizations and Users page) and choose Remove.

The Remove User? or Remove Group? message appears, prompting you to confirm 
the removal.




                       Application Security, Inc.                                  51
                         Introduction




     3. Click the Yes button to remove the User.

     The User is removed from the Organization Users portion of the Manage Organi‐
     zations and Users page.

     Creating a DbProtect Audit and Threat Management Policy

     You can create a DbProtect Audit and Threat Management Policy based on vul‐
     nerabilities detected in applications using DbProtect Vulnerability Management.

     To create a DbProtect Audit and Threat Management Policy: 
     1.   Do one of the following to display the Manage Organizations and Users page:
          • Choose Admin > Organizations and Users from the menu
          • Click the Organizations and Users tab.

     The Manage Organizations and Users page displays your existing:
          • Organizations (in the Parent Organization portion of the Manage 
          Organizations and Users page)
          • Users and Groups (in the Organization Users portion of the Manage 
          Organizations and Users page).

 Hint:        Highlight an organization in the Parent Organization portion of the Man‐
              age Organizations and Users page to display its subordinate users and 
              groups, and to activate the control buttons and menu items.




52                       Application Security, Inc.
2. Locate the AppRadar Policy toolbar on the Manage Jobs page.
3. Click the AppRadar Policy button to display the AppRadar Policy Generator dia‐
   log box.




4. Enter a policy name in the Policy Name field.
5. Click the Generate Policy button.

DbProtect vulnerability management creates a DbProtect audit and threat manage‐
ment policy based on vulnerabilities detected in applications in your selected organi‐
zation. This new policy is dynamically created on the policies page in DbProtect 
audit and threat management. You do not have to import the policy.

Customer Support
Customer Support is available from 9 A.M. to 9 P.M. (GMT ‐5) Monday through

Friday, except for company holidays. You may contact technical support for the list of 
company holidays.

Extended support of 24x7 is available as an added cost. You may contact 
sales@appsecinc.com if you require this service.

Telephone (in the U.S.): 1‐866‐927‐7732

Telephone (outside the U.S.): 1‐212‐912‐4100

Email: support@appsecinc.com




                      Application Security, Inc.                                    53
     Introduction




54   Application Security, Inc.

								
To top