Command-Line Interface (CLI) Guide: Database Security and Compliance

Database Security and Compliance
Command-Line Interface (CLI) Guide

Version 6.2.00
© 2002-2007 IPLocks, Inc. All rights reserved

www.iplocks.com Phone 408.383.1500
IPLocks Command-Line Interface (CLI) Guide
Corporate Headquarters:
IPLocks Inc.
2665 North First Street, Suite 110
San Jose, CA 95134
Tel: +1 408-383-7500
Fax: +1 408-383-5269
http://www.iplocks.com
info@iplocks.com
Customer Satisfaction:
Tel: +1 408-383-1500
Fax: +1 408-383-5269
FTP: ftp://blinder.iplocks.com
Tech Support Portal: https://na4.salesforce.com/sserv/login.jsp?orgId=00D300000005yKU
Email: support@iplocks.com
Company and general product questions as well as white paper requests may be submitted to
info@iplocks.com.
© 2002-2007 IPLocks, Inc. All rights reserved.

This guide and the software described in it, are furnished under license and may be used and
copied in accordance with the terms of the license. The contents in the manual are for
informational purposes only, and should not be construed as a commitment by IPLocks.
IPLocks assumes no responsibility or liability for any errors, omissions, or inaccuracies that may
appear in this document. The contents in this manual are subject to change without notice.
Other parties’ trademarks or service marks are the property of their respective owners and
should be treated as such.
© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 2

All rights reserved. www.iplocks.com Phone 408.383.1500
Contents
IPLocks Feature Summary......................................................................................................... 5
CLI Guide Introduction ............................................................................................................... 7
Supported Tasks ..................................................................................................................... 7
Convention for File Locations and Environment Variables ..................................................... 8
The XML Input File .................................................................................................................... 10
The project Element.......................................................................................................... 11
The target Element............................................................................................................ 11
Using CLI ................................................................................................................................... 13
The Sample Input File ........................................................................................................... 14
Specifying a Command-Line Input File ................................................................................. 14
Specifying a Command-line Target....................................................................................... 14
Specifying Task Values......................................................................................................... 14
Specifying Command-Line Task-Attribute Values ..................................................... 15
Using the property task ............................................................................................. 15
Using the loadPropertyFile Task ........................................................................... 15
Automatically Generated Task Values ........................................................................ 15
Running Multiple Tasks......................................................................................................... 15
Using the List Type..................................................................................................... 16
foreach Task-Utility....................................................................................................... 16
Database Tasks......................................................................................................................... 18
Managing Database Connections ......................................................................................... 18
addDatabase.................................................................................................................. 18
updateDatabase ............................................................................................................ 19
openDatabase................................................................................................................ 21
closeDatabase ............................................................................................................... 21
deleteDatabase.............................................................................................................. 22
Scheduling, Scanning, and Reporting Tasks ......................................................................... 23
Scheduling Tasks.................................................................................................................. 23
addCalendarSchedule .................................................................................................. 23
updateCalendarSchedule ............................................................................................. 24
deleteCalendarSchedule .............................................................................................. 25
setTimerSchedule ......................................................................................................... 26
deleteTimerSchedule .................................................................................................... 27
Scanning Tasks..................................................................................................................... 28
scan ................................................................................................................................ 28
scanServer..................................................................................................................... 28
Reporting Tasks .................................................................................................................... 29
cliReport......................................................................................................................... 29
statusReport .................................................................................................................. 30
generateVAReport......................................................................................................... 31
Guarded Items Tasks................................................................................................................ 35
setStatus ............................................................................................................................... 35
Attribute Descriptions .................................................................................................. 35
Possible Contained Elements ...................................................................................... 35
setSeverity ............................................................................................................................ 36
addUDR ................................................................................................................................ 37

deleteUDR............................................................................................................................. 38
Utility Tasks............................................................................................................................... 40
foreach ........................................................................................................................... 40
autoDiscovery ............................................................................................................... 40
property.......................................................................................................................... 41
loadPropertyFile............................................................................................................ 42
Appendix A: Definitions ........................................................................................................... 44
Definitions ............................................................................................................................. 44
Appendix B: Sample Console Output ..................................................................................... 45
Appendix C: Table of Figures .................................................................................................. 46
Index........................................................................................................................................... 47

IPLocks Feature Summary

The three main components of the IPLocks Database Security and Compliance Solution are:
• Vulnerability Assessment to ensure database best practices are enforced
• Monitoring to examine and alert on changes in permissions, critical content, and
metadata, on policy violation and on unusual behavior
• Auditing and Analysis to provide 100% assured access log recording and analysis
reports that assist in regulatory compliance.
Each component is an important element of information security and integrity, but when
integrated into a complete security framework, IPLocks Database Security and Compliance
Solution, they provide a value greater than the sum of their parts:
• Baseline security is covered with a database vulnerability assessment
• Continuous database monitoring provides:
• Unusual-activity alerts, so you can react in a meaningful way.
• Major-change control
• Policy violations and unusual access
IPLocks offers these components with support for all major RDBMS types, including those from
IBM, Microsoft, Oracle, and Sybase.
Figure 1: IPLocks Database Security and Compliance Solution

Some specific IPLocks features include:

• Alert notifications to assigned security personnel. Presented via the IPLocks GUI, email,
or SNMP traps, these alerts originate from the target database, access information,
system data and the content and get stored in the IPLocks internal database
• Separation from your enterprise-database servers. IPLocks resides on its own Windows,
Solaris, or Linux server.
• Capability of monitoring both local and remote databases within your enterprise via a web-
based management console.
• The IPLocks Command Line Interface (CLI) for managing enterprise-database
environments.
• Auto Discovery. By supplying a range of IP addresses and port numbers, you can have
IPLocks discover all active, distributed databases, registered or not, within your enterprise.
• Penetration Testing. Provides the ability to do an aggressive password attack on
selected databases to determine if user passwords are easy to detect thus allowing
access into your database.

CLI Guide Introduction

The IPLocks Command-Line Interface (CLI) enables users to perform the same tasks possible
with the IPLocks GUI-driven software, but in a more efficient way. It offers you the ability to run:
• Individual tasks automatically
• Multiple tasks in succession
• Tasks after, and only if, another task has completed
In addition, it uses the industry-standard XML file format in order to specify the tasks of interest.
The CLI enables these task types:
• Database-connection management
• Scheduling assessments (Vulnerability Assessment (VA) module)
• Scheduling monitoring (Privilege Monitor (PM) and Metadata Monitor (MM) modules)
• Reporting the results of assessments and monitoring (VA, PM, and MM)
• Enabling, Disabling, and setting the Severity level for, guarded items (PM and MM)
• Adding and Deleting User-Defined Rules (VA, PM, and MM)
Supported Tasks
Supported tasks include:
Task Name Task Description Category

addDatabase Creates a database connection Managing Database
Connections
updateDatabase Updates a database connection Managing Database
Connections
openDatabase Opens and runs a particular Managing Database
database connection Connections
closeDatabase Closes a particular database Managing Database
connection Connections
deleteDatabase Deletes a database connection Managing Database
Connections
addCalendarSchedule Sets the day and time for Scheduling
monitoring and/or assessment
updateCalendarSchedule Updates the day and time of an Scheduling
already scheduled monitoring
and/or assessment
deleteCalendarSchedule Deletes an already scheduled Scheduling
calendar-based monitoring and/or
assessment
setTimerSchedule Sets the start time and interval for Scheduling

Task Name Task Description Category

monitoring and/or assessment
deleteTimerSchedule Deletes an already established Scheduling
timer-based monitoring and/or
schedule
scan Initiates an immediate monitoring Scheduling
and/or assessment scan
scanServer Performs a scan on databases for Scanning
which server-level connections are
supported, currently MS-SQL and
Sybase databases
cliReport Generates a report from the CLI log Status Reporting
file
statusReport Generates a report from the last n Status Reporting
number of scans
setStatus Sets status for one or more guarded Guarded Items
items in Privilege Monitor and/or
Metadata Monitor module
setSeverity Sets severity level for one or more Guarded Items
guarded items in Privilege Monitor
and/or Metadata Monitor module
addUDR Adds a new User-Defined Rule for Guarded Items
the specified module
deleteUDR Deletes a User-Defined Rule from Guarded Items
the specified module
foreach Enables processing of multiple Utility
tasks that are, in turn, specified in
the same XML file as a List type for
a property
autoDiscovery Allows you to "discover" any Utility
number of databases within a
specified IP range and DB Type
property Sets name, value, and type values Utility
for the context
loadPropertyFile Allows you to load properties from a Utility
file into a running project's context
Convention for File Locations and Environment Variables

IPLocks runs on both Windows-, and UNIX-, based platforms. Where the text in this document
applies to both UNIX and Windows, only the UNIX convention for file locations and environment
variables might be used. However, the Windows convention is implied. For example, this UNIX
location:
$IPLOCKS_HOME/conf
implies this Windows location as well:
%IPLOCKS_HOME%\conf

The XML Input File

The CLI input file needs to be an XML file with a project element as its root. The file needs to
contain one or more lists of actions to be performed. Each list is called a target and each
action is called a task.
The diagram below shows a high-level view of the structure of the XML input file.
targetA
task1
depends
task2
project
task3
default
targetB
task4
task5
Figure 2: Block diagram of XML file
This diagram represents a file with:
• A project whose name is project and which has a default task, targetB
• Two targets within project where one, targetB, depends upon the other, targetA
• Multiple tasks to be performed in each target
The CLI expects the XML element 1 format to describe targets and tasks. Here is the XML file
represented by the diagram.
<project name = "project" default = "targetB">
..<target name = "targetA" depends = "targetB">
....<task name = "task1">
....</task>
....</task>
....</task>
1
In XML, an element is comprised of an opening tag, some attribute data in name-value-pair format, and a closing
tag; for example, <iceCream flavor = "chocolate">this tastes great</iceCream>

..</target>
..<target name = "targetB">
....</task>
....</task>
..</target>
</project>
The project Element

The project element is the root element of your XML input file. The project element
contains target elements. Use the project element's default attribute to specify the target
you want to be the first to be performed 2 . You must specify a default target to represent the
starting point for your application.
The target Element

The target element contains task elements and has this syntax:
<target name = "targetName" [depends = "targetName"]>

..<task name = "taskName1">
..</task>
..[<task name = "taskName2">
..</task>..
... . .
..<task name = "taskNameN">
..</task>]
</target>
where [ ] enclose optional items. Each target must have a unique name as defined by its name
attribute. This attribute is mandatory.
Targets may depend upon other targets. Use the target attribute depends in order to indicate
target interdependency. This attribute is optional.
Independent targets are executed by either:
• Specifying the target by the -t command line option
• Specifying the default in the input XML file
• The task Element
2
You can override the default contained in the input file with a command-line specified one.

project
target
task
<task attributeName1 =
"attributeValue1"
...
attributeNameN ="attributeValueN"
/>
Figure 3: Block diagram of Task Element

Use task elements and their attributes to specify the operations and operation details that you
want performed. Task elements must have a unique name and must use this syntax:
<taskName
.. taskAttributeName1 = "taskAttributeValue1"
..[taskAttributeName2 = "taskAttributeValue2"
... . .
.. taskAttributeNameN = "taskAttributeValueN"]
/>
where [ ] enclose optional items.

Using CLI
There are several ways to use the CLI, all involving the cli.bat for Windows or, for Linux, cli.
These files are shipped in $IPLOCKS_HOME/bin. The syntax is:
cli[.bat] [–f <my_XML_input_file>] [-t <my_default_target>] \ 3
[-p <my_task_values.properties>]
where:
• my_XML_input_file is the name of an XML input file that contains your project and
task definitions. (IPLocks ships with an example input file called sample_cli.xml located in
$IPLOCKS_HOME/etc/cli that contains examples of some of the tasks and their attributes.)
• my_default_target is the target you want to be considered the default--instead of the
one in the input file 4 .
• my_task_values.properties is the name of a file containing task-attribute names and
values that you want to substitute for variables in the input file. Values in your .properties
file 5 can be used in your input file by using the $property 6 format. (IPLocks ships with an
example task-attribute-values file called sample_cli.properties located in
$IPLOCKS_HOME/etc/cli.
• [ ] are brackets which enclose optional command-line arguments
Here are some examples:
# Example Description
1 cli.bat Uses cli_input.xml as its default XML

input filename. Rename your XML
input file to this name in order to run
the command without specifying an
input filename.
2 cli.bat –f addConnections.xml addConnections.xml is a user-

created XML input file that might
contain database-connection
information. You may use any
filename as long as the file format
conforms to the specifications
described in this manual.
3 cli.bat –t target1 Uses cli_input.xml as the default

XML input file and target1 as the
default, first-to-execute target. This
overrides any default setting in
your XML input file.
3
• \ is a line-continuation symbol. You don't actually key it.
4
A default target is required in the input file.
5
See Example Input - Project File for sample properties file
6
A $-prefixed reference to the name of the variable.

# Example Description
4 cli.bat –p my_task_values.properties Uses cli_input.xml as the default

XML input file and uses the task
attribute values specified in
my_task_values.properties.
The values in this file override
corresponding task attribute values
that may be in your XML input file.
5 cli.bat –t target1 \ 7 Uses cli_input.xml as the default

–p my_task_values.properties
XML input file, target1 as the
default, first-to-execute target, and
the task-attribute values specified in
my_values.properties.
6 cli.bat >> output 2>&1 Sends the command output to a file

called output. (Uses cli_input.xml as
the default XML input file.)
The Sample Input File

IPLocks ships a sample input file, cli_input.xml, in $IPLOCKS_HOME/etc/cli.
Specifying a Command-Line Input File

You may choose to specify your own file for task instructions by using the:
-f <my_XML_input_file>
command-line option.
Specifying a Command-line Target

You can override the default target specified within the input file by using the:
-t <my_default_target>
command-line option
Specifying Task Values

There are several ways to specify task values. You can specify them via:
• task-attribute values in your input file
• the loadProperty task in your input file
• task-attribute names and values in a properties file that you specify on the command line
following the -p flag.
7
\ is a line-continuation symbol. It is not actually keyed.

Specifying Command-Line Task-Attribute Values

To avoid hard coding them in your input XML file, you can specify task-attribute values in a task-
attribute-values file that is acknowledged on the command line like this:
-p <my_task_values.properties>
Here is an example of such a file:
Example Task-Attribute-Values File:

database = iplocks
host = 192.168.5.2
login = sa
For a more complete task attributes-values file, see Sample Task-Attribute-Values File
Note: Property names are case sensitive. You should only put one attribute name-value pair per
line in the task-attribute-values file.
In order to have variable substitution occur at runtime, prepend an '$' to the names, exactly as
they appear in your task-attribute-values file. Then place the resultant, concatenated string
inside of double quotes in your XML input file as shown here:
Example XML Input File Snippet with Variables

<addDatabase
alias = "ipdb"
host = "$host"
database = "$database"
type = "ora"
username = "$login"
password = "iplocks"
/>
Using the property task

You may specify additional task attributes by using the property task. See property Task.
Using the loadPropertyFile Task

You may also use the loadPropertyFile task within your input file in order to specify the
name and location of a file that contains task values. See loadPropertyFile Task
Automatically Generated Task Values

The CLI engine automatically generates some IPLocks system properties. For example,
IPLocks automatically generates run.id, which uniquely identifies each CLI run. You should
not specify run IDs on your own. (They appear in the cli.log file.)
Running Multiple Tasks

You may run multiple tasks in succession by using the List property type with the foreach
task.

Using the List Type

List is a type of property. For the List type, use the name attribute to specify the name of
your list of similar task attributes. The item element is used to specify the individual items in
List.
<property name = "propertyListName" type = "List">
<item
subpropertyName1 = "subpropertyValue1"
. . .
subpropertyNameN = "subpropertyValueN"
/>
<item
. . .
subpropertyNameN = "subpropertyValueN"
/>
</property>
Example
<property name = "connections" type = "List">
<item
alias = "iplocks1"
host = "192.168.5.1"
type = "ora"
login = "SYSTEM"
/>
<item
alias = "iplocks2"
host = "192.168.5.2"
type = "msql"
login = "sa"
/>
</property>
foreach Task-Utility
The foreach task-utility element is used in conjunction with the List property to iterate
through the list items that must be performed.
<foreach List = "$propertyListName">
<task
attribute1 = "$propertyListName.subpropertyName1"
attribute2 = "$propertyListName.subpropertyName2"
. . .
attributeN = "$propertyListName.subpropertyNameN"
/>
</foreach>

In first iteration of foreach, the first item from List is executed; in the second iteration, the
next item is executed, etc.
Example
<foreach List ="$connections">
<addDatabase
alias = "$connections.alias"
host = "$connections.host"
database = "iplocks"
type = "$connections.type"
username = "$connections.login"
password = "iplocks"
/>
</foreach>

Database Tasks
Managing Database Connections
addDatabase
This task sets database-connection parameters. The following table describes the possible
addDatabase attributes. You must specify the first six attributes.
Attribute Descriptions
Name Description
alias Connection name in the IPLocks system
host [IP address | fully qualified server name][:target-database port number].

(Depending upon the RDBMS, you may need to enter the default Port Number
or, perhaps, a non-default one of your own, when specifying a host value.)
database Database name
type Database server type. The allowable types, and their corresponding RDBMS,
are:
ora Oracle
msql Microsoft SQL Server
sybase Sybase
db2 IBM DB2 V7
db28 IBM DB2 V8
username Username
password Password
application Module in IPLocks. The possible values are:

cva Vulnerability Assessment
mas Metadata Monitor
asas Privilege Monitor
location Location
region Region
division Division
unit Business unit
dba1tel Primary DBA phone number
dba1email Primary DBA e-mail
dba1name Primary DBA name

Name Description
dba2tel Secondary DBA phone number
dba2email Secondary DBA e-mail
dba2name Secondary DBA name
audit Is database auditing enabled? Possible values: Y or N
useAgent Use an agent
agentIp Agent IP
agentPort Agent port
SqlClientPort SQL client port
verifyConnection Enable verify-connection functionality. Possible values are true and false.
The default is false.
Example
<project ...>
<target ...>
...
<addDatabase
alias = "pubs"
host = "127.0.0.1"
database = "pubs"
type = "msql"
username = "sa"
password = "123"
verifyConnection = "true"
/>
...
</target>
</project>
updateDatabase
This task changes database-connection information. The following table describes the possible
updateDatabase attributes. Only the alias attribute is mandatory.
Name Description
host [IP address | fully qualified server name][:target-database port number]. (Depending
upon the RDBMS, you may need to enter the default Port Number or, perhaps, a non-
default one of your own, when specifying a host value.)

Name Description
username Username
password Password

location Location
region Region
division Division
unit Business unit
usage Usage
dba1tel Primary DBA phone number
dba1email Primary DBA e-mail
dba1name Primary DBA name
dba2tel Secondary DBA phone number
dba2email Secondary DBA e-mail
dba2name Secondary DBA name
audit Is database auditing enabled? Possible values: Y or N
useAgent Use an agent
agentIp Agent IP
agentPort Agent port
SqlClientPort SQL client port
verifyConnec Enable verify-connection functionality. Possible values are true and false. The default
tion is false.

Example
<project ...>
<target ...>
...
<updateDatabase
alias = "pubs"
username = "admin"
password = "456"
verifyConnection = "true"
/>
...
</target>
</project>
openDatabase
This task opens and runs a particular database connection. Both attributes are required.
Name Description

Example
<project ...>
<target ...>
...
<openDatabase
database = "pubs"
application = "cva"
/>
...
</target>
</project>
closeDatabase
This task closes a particular database connection. Both attributes are required.

Name Description

Example
<project ...>
<target ...>
...
<closeDatabase
database = "pubs"
application = "cva"
/>
...
</target>
</project>
deleteDatabase
This task deletes database-connection information from the IPLocks system. The alias
attribute is the only possible attribute and is required.
Name Description
Example
<project ...>
<target ...>
...
<deleteDatabase
alias = "pubs"
/>
...
</target>
</project>

Scheduling, Scanning, and Reporting Tasks

Scheduling Tasks
addCalendarSchedule
The addCalendarSchedule task enables you to schedule tasks within the IPLocks module.
The following table describes the possible addCalendarSchedule attributes. All attributes are
required except database. If you do not specify database, the schedule will apply to all
databases within the module.
Name Description
database Connection name in the IPLocks system
day Scheduled execution day. Possible values are:

Everyday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
Sunday
time Scheduled execution time. The format is: "hh:mm a"
Example
<project ...>
<target ...>
...
<addCalendarSchedule
application = "cva"
database = "pubs"
day = "Everyday"
time = "10:00 AM"
/>
...
</target>

project>
updateCalendarSchedule
The updateCalendarSchedule task modifies previously established schedule information.
The following table describes the possible updateCalendarSchedule attributes. All attributes
are required except database. If you do not specify database, the schedule will apply to all
databases within the module.
Name Description
oldDay Scheduled execution day of the original schedule. Possible values are:
Everyday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
Sunday
oldTime Scheduled execution time of the original schedule. The format is: "hh:mm a"
newDay New scheduled execution day. Possible values are:

Everyday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
Sunday
newTime New scheduled execution time. The format is: "hh:mm a"

Example
<project ...>
<target ...>
...
<updateCalendarSchedule
application = "cva"
database = "pubs"
oldDay = "Everyday"
oldTime = "10:00 AM"
newDay = "Monday"
newTime = "12:00 AM"
/>
...
</target>
</project>
deleteCalendarSchedule
The deleteCalendarSchedule task deletes the calendar schedule from the IPLocks system
for the specified day and time.
The following table describes the possible deleteCalendarSchedule attributes. All attributes
are required except database. If you do not specify database, IPLocks will delete the
schedule for all databases within the module.
Name Description
day Scheduled execution day. Possible values are:

Everyday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
Sunday
time Scheduled execution time. The format is: "hh:mm a"

Example
<project ...>
<target ...>
...
<deleteCalendarSchedule
application = "cva"
database = "pubs"
day = "Everyday"
time = "10:00 AM"
/>
...
</target>
</project>
setTimerSchedule
The setTimerSchedule task sets the schedule in the IPLocks scans with a defined
interval from startTime.
The following table describes the possible setTimerSchedule attributes. All attributes are
required except database. If you do not specify database, IPLocks will create the schedule
for all databases within the module.
Name Description
interval Scanning interval. The format is: "h:mm:s"
startTime Starting time. The format is: "h:mm a";
random Enable random interval scanning. Possible values are "true" and "false".
"false" is the default.

Example
<project ...>
<target ...>
...
<setTimerSchedule
application = "cva"
interval = "10:10:10"
startTime = "12:00 PM"
/>
...
</target>
</project>
deleteTimerSchedule
The deleteTimerSchedule task deletes the schedule for the specified application and
database connection.
The following table describes the possible deleteTimerSchedule attributes. All attributes are
required except database. If you do not specify database, IPLocks will delete the schedule
for all databases within the module.
Name Description
random Enable random interval scanning. Possible values are "true" and "false".
"false" is the default
Example
<project ...>
<target ...>
...
<deleteTimerSchedule
application = "cva"
database = "pubs"
/>
...
</target>
</project>

Scanning Tasks
scan
Use the scan task to specify a module- or database-level scan-and-report process that you
want to begin immediately upon execution of cli.bat (or cli).
The following table describes the scan attributes. All are required, except report.
Name Description
mas Metadata Monitor (a snapshot scan is performed on the target database
asas Privilege Monitor (a snapshot scan is performed on the target database
report Enable log reporting for current scan. Possible values are "true" and "false". The
default value is "false". If you specify report= "true", you will get a report of the
results of running the scan task.
Example
<project ...>
<target ...>
...
<scan
application = "cva"
database = "pubs"
report = "true"
/>
...
</target>
</project>
scanServer
The scanServer task scans an RDBMS server in order to collect a list of its databases. It then
uploads to IPLocks the connection information about those databases and generates a report
for each.
Note: This task applies only to RDBMS types for which server-level assessment is supported
such as MS-SQL and Sybase.
The following table describes the possible scanServer attributes. All are required, except
report.

Name Description
host [IP address | fully qualified server name][:target-database port number]. (Depending upon
the RDBMS, you may need to enter the default Port Number or, perhaps, a non-default
one of your own, when specifying a host value.)
serverType Database server type. The allowable types, and their corresponding RDBMS, are:
sybase Sybase
username Name of the user
password Password
Report Enables log reporting for each database scan. Possible values are "true" and "false". The
default is "false". If you specify report= "true", you will get a report of the results of
running the scan task.
Example
<project ...>
<target ...>
...
<scanServer
host = "127.0.0.1"
serverType = "sybase"
username = "DBA"
password = "SQL"
report = "true"
/>
...
</target>
</project>
Reporting Tasks
cliReport
The cliReport task allows you to parse the CLI log file and it generates an XML report file.
The following table describes the required cliReport attributes.
Name Description
runId Run ID for which to generate a report
outputFolder Output folder for reports
Example

<project ...>
<target ...>
...
<cliReport
runId = "1898713123"
outputFolder =
"usr/local/reports"
/>
...
</target>
</project>
Example Output
<?xml version="1.0" encoding="UTF-8"?>
<report runId="1115385323046">
<task connection="oracle" name="Add Database Task"
result="success" time="05/06/2005 17:15:34"/>
<task connection="oracle" name="Add Calendar Schedule Task"
result="success" time="05/06/2005 17:15:35"/>
<task connection="oracle"
name="Add Calendar Schedule Task (oracle) - failure - Schedule already
exist
1115385323046 05/06/2005 17:15:35 WARNING: Add Calendar Schedule
Task (oracle) - failure - Schedule already exist
1115385323046
05/06/2005 17:15:35 WARNING: Add Calendar Schedule Task"
reason="Schedule already exist" result="failure"
time="05/06/2005 17:15:35"/>
</report>
statusReport
Use the statusReport task to generate an XML-file report for the last n scans.
The following table describes the possible statusReport attributes. All are required, except
database. If you do not specify database, IPLocks will create the schedule, dictated by the
addCalendarSchedule task) for all databases within the module.

Name Description
nRuns Number of last scans in the report. If set to 0(zero) or 1, only the last scan is reported.
reportFile Path to report file including filename
Example
<project ...>
<target ...>
...
<statusReport
application = "cva"
database = "publs"
nRuns = "10"
reportFile = "/reports/report.xml"
/>
...
</target>
</project>
generateVAReport
Use the generateVAReport task to generate VA reports.
Note: You should run either the scan or scanServer task before using generateVAReport.
The following table describes the possible generateVAReport attributes. All are required,
except database which is not required if the reportType is global.
You can generate more than one type of report at the same type by delimiting the various
reportTypes with spaces. For example:
reportType="score summary"
You can generate reports in more than one format at the same time by delimiting the various
reportFormats with spaces. For example:
reportFormat="tab csv"
The names of the generated report files use the following format:
yyyyMMdd_hhmmss_<database connection name>_<reporttype>.<file type extension>
where:
• yyyyMMdd_hhmmss represents the current system time

Note: The current system time is accurate up to seconds.

• <database connection name> represents the database-connection name
• <reporttype> represents the reportType used (in format).
• <file type extension> represents the file extension specific to a particular
reportType
Here is an example report filename:
20070720_122315_cli-ora_trend.pdf
Note: If the database-connection name contains any special characters other than underscore
(_), hyphen (-) or period (.), those special characters will be replaced by an underscore (_) in the
resulting filename.
In case of Global Reports, since there is no database-connection name, the following format is
used:
yyyyMMdd_hhmmss_global_global.<file type extension>.
Here is an example report filename for a Global Report:

20070720_122315_global_global.csv

Name Description
reportType The possible values are:

score VA Score Report
summary VA Summary Report
failedsummary Failed VA Summary Report
detailed VA Detailed Report
faileddetailed Failed VA Detailed Report
trend VA Trend Report
all All reports other than Global Report (global report is common
across all database connections)
global VA Global Report
reportFormat The possible values are:

pdf PDF
tab Tab delimited
csv Comma delimited
all All formats
Note: You will need the appropriate software for reading the reports produced by
this task. For example, you will need a PDF reader.
reportLocation Directory in which reports will be written. This directory must pre-exist and have read and
write permissions for the CLI user.
Example (Single Database Connection)

A sample XML input file for generateVAReport task will look like the following, which shows
how to generate a multiple report types in a multiple formats for a single database connection.
<project ...>
<target ...>
...
<generateVAReport
database = "cli-ora"
reportType = "trend failedsummary"
reportFormat = "pdf tab"
reportLocation = "c:\reports"
/>
...
</target>
</project>
Example (Multiple Database Connections)

This example shows how the foreach task may be used for generating reports for multiple
database connections. (See foreach)
< property name = "connections" type = "List">
<item databasename = "cli-ora"/>
<item databasename = "cli-sql"/>
</property>
The connections list would be used as follows:
<foreach List ="$connections">
<generateVAReport
database = "$connections.databasename"
reportType = "trend score"
reportFormat = "pdf"
reportLocation = "c:\vareports"/>
</foreach>

Guarded Items Tasks

setStatus
The setStatus task sets the enabled status for one or more guarded items in the Privilege
Monitor and Metadata Monitor modules.
The following table describes the possible setStatus attributes. The application and
database attributes are required.
Name Description
name Name of guarded item
itemType Type of guarded item. Possible values:

SystemViews System views items. (only for PM);
SchemaObjects Schema-related items (only for MM);
PDR Pre–defined rule
UDR Use –defined rule
status Status of guarded item. Possible values:

enable guarded item is enabled
disable guarded item is disabled
Possible Contained Elements

The setStatus element can contain item child elements.
Note: For setStatus, the attributes name and status are not used.
Example
<project ...>
<target ...>
...
<setStatus
application = "asas"
database = "test"
<item
name = "Check Password"
itemType = "PDR"
status = "enable"
/>
</setStatus>
...
</target>
</project>
setSeverity
The setSeverity task sets the severity level for one or more guarded items in the Privilege
Monitor and Metadata Monitor modules.
The following table describes the possible setSeverity attributes. The application and
Name Description
name Name of guarded item
itemType Type of guarded item. Possible values:

SystemViews System views items. (only for PM);
SchemaObjects Schema-related items (only for MM);
PDR Pre–defined rule
UDR User–defined rule
severity Severity of guarded item. Possible values are:

Critical
Major
Minor
Cautionary
Informational

The setSeverity element can contain item child elements.

Example
<project ...>
<target ...>
...
<setSeverity
application = "asas"
database = "test"
<item
name = "Check Password"
itemType = "PDR"
severity = "Critical"
/>
</setSeverity>
...
</target>
</project>
addUDR
The addUDR task adds a new UDR (User-defined Rule) for the specified module.
The following table describes the possible addUDR attributes. The application, name and
Name Description
database Connection name in the IPLocks application
name Name of the UDR
category Category of the UDR
sqlType SQL type of the UDR query. Possible values:

plsql PL/SQL type
sql SQL query type
showRecords Number of first-violating records in alert messages. You many also use:
All show all violating records in alert message;
No show no violating records in alert message
severity Severity of guarded item. Possible values are:

Critical
Major

Name Description
Minor
Cautionary
Informational

The setSeverity element can enclose and sqlQuery elements.
Example
<project ...>
<target ...>
...
<addUDR
application = "cva"
database = "test"
name = "Check Users"
category = "User"
sqlType = "sql"
showRecords = "60"
<description>
Select all users
</description>
<sqlQuery>
Select * from users
</sqlQuery>
</addUDR>
/>
...
</target>
</project>
deleteUDR
The deleteUDR task deletes a UDR (User-defined Rule) for the specified module.
The following table describes the possible deleteUDR attributes. All attributes are required.
Name Description
name Name of the UDR

Example
<project ...>
<target ...>
...
<deleteUDR
application = "pm"
database = "test"
name = "Check Users"
</deleteUDR>
...
</target>
</project>

Utility Tasks
foreach
See foreach Task-Utility
autoDiscovery
The autoDiscovery task allows you to "discover" any number of databases within a specified
IP range and DB Type. All attributes are required.
Note: The output-file directory must exist prior to running this task.
Name Description
fromip IP address of the start of the IP-address range
toip IP address of the end of the IP-address range
type Database server type. The allowable types, and their corresponding RDBMS, are:
ora Oracle
sybase Sybase
db2 IBM DB2
ouputFileType Output file type. The allowable types, with descriptions, are:
xls Microsoft Excel
comma comma-delimited file
tab tab delimited file
outputFile Database server type. The allowable types, and their corresponding RDBMS, are:
ora Oracle
sybase Sybase
db2 IBM DB2
Example

<project ...>
<target ...>
...
<autoDiscovery outputFile="c:\result.xls" outputFileType="xls"/>
<range fromip="192.168.001.001" toip="192.168.001.256" type="ora"/>
<range fromip="192.168.001.001" toip="192.168.001.256" type="msql,sybase"/>
</autoDiscovery>
...
</target>
</project>
property
The property task sets name, value, and type values for the context. It uses this syntax:
<property
name = "propertyName"
[value = "propertyValue"]
type = "propertyType"
/>
The following table describes the possible property attributes. The name and type attributes
are required.
Name Description
name Property name
value Value for the name (See Notes below)
type Type that the name represents
Notes:
A property task may have properties which will be declared as String (for one task) or as
List (for multiple tasks). If a property task is of type String, then value is a required
parameter. But if a property task is of type List then value is not a required parameter.
For example:
<property name = "application"
value = "cva"
type = "String" /> - value is required.
<property name = "connections"

type = "List">
<item alias = "iplocks1"
host = "192.168.5.1"
type = "ora"
login = "SYSTEM" /> - value is not required
If you don't specify the value parameter then, in the case where type=String, the value
parameter will be set to "", by default.
For example:
<property name = "application" type = "String" />

is treated as:
<property name = "application" value = "" type = "String" />
Example
<property
name = "application"
value = "cva"
type = "String"
/>
loadPropertyFile
The loadPropertyFile task allows you to load properties from a file into a running project's
context, where the property values can be referenced with the $ prefix. This task adds additional
properties (from the file) into the project's context. If a particular property already exists in the
context, it will be re-initialized.
You may also use the loadPropertyFile task within your input file in order to specify the
name and location of a file that contains task values, using this syntax:
<loadPropertyFile
file = "propertyFileName"
/>
The following table describes the only possible loadPropertyFile attribute, which is
mandatory.
Name Description
file Full path 8 and name of a text file that contains the properties you want to load.
Example
<project ...>
<target ...>
...
< loadPropertyFile
file = "c:\work\properties.txt"
/>
...
</target>
</project>

None
8
Specifying a filename without the path is also possible if the text file is located in the same directory as the cli.bat or
cli.sh file

Notes
• The required file format is ASCII text
• The individual properties within the file should adhere to the same 'name=value' format
as in the current dssConfig.properties file
• The file must exist.

Appendix A: Definitions
Definitions
These definitions may clarify the example that follows:
• project: root element of the input file. Each project may have a default target or set of
tasks.
• target: a set of tasks to be executed. Each may depend upon other targets. Each project
may have a default target. In the example, the default target is scheduleAndScan, which
depends upon the updateConnection target.
• task: name of an action. In the example, the updateConnection target element includes
several tasks: addDatabase, updateDatabase, and deleteDatabase.
• property: task parameter expressed as a name-value pair.
• item: List-related entity
• subproperty: item-related property

Appendix B: Sample Console Output

Here is an example of a console output generated by the CLI:
1123761375986 08/11/2005 14:56:15 INFO: Project successful opened.
1123761375986 08/11/2005 14:56:15 INFO: Begin execute target: TC 1.2.2.
1123761375986 08/11/2005 14:56:18 WARNING: Connect verified - success.
1123761375986 08/11/2005 14:56:18 INFO: Add Database Task (test_oracle_db) -
success - .
1123761375986 08/11/2005 14:56:21 INFO: Open Database Task (test_oracle_db) -
success - .
1123761375986 08/11/2005 14:56:21 WARNING: Set status failed for
item:$system_views_pm_mm_ora. Invalid item name.
1123761375986 08/11/2005 14:56:21 WARNING: Set Status Task (test_oracle_db) -
failure - No one status is set.
1123761375986 08/11/2005 14:56:21 WARNING: Set status failed for
item:$system_views_pm_mm_ora_additional. Invalid item name.
1123761375986 08/11/2005 14:56:21 WARNING: Set Status Task (test_oracle_db) -
failure - No one status is set.
1123761375986 08/11/2005 14:56:21 INFO: Close Database Task (test_oracle_db) -
success - .
1123761375986 08/11/2005 14:56:21 INFO: Delete Database Task (test_oracle_db) -
success - .
1123761375986 08/11/2005 14:56:21 INFO: End execute target: TC 1.2.2.
1123761375986 08/11/2005 14:56:21 INFO: Successful end project.

Appendix C: Table of Figures

Figure 1: IPLocks Database Security and Compliance Solution...................................................5
Figure 2: Block diagram of XML file ............................................................................................10
Figure 3: Block diagram of Task Element ...................................................................................12

Index
auditing, 19, 20 monitoring, 5, 6, 7, 8
best practice, 5 policy, 5
CLI, 1, 3, 6, 7, 8, 10, 13, 15, 29, 33, 45 property, 2, 3, 4, 8, 13, 15, 16, 34, 41, 42,
compliance, 5 44
dssConfig.properties, 43 Severity level, 7
license, 2 SNMP traps, 6
login, 2, 15, 16, 17, 41 violation, 5
metadata, 5 vulnerability, 5


Command-Line Interface (CLI) Guide: Database Security and Compliance

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Command-Line Interface (CLI) Guide: Database Security and Compliance

Uploaded by

Copyright:

Available Formats

Database Security and Compliance

Command-Line Interface (CLI) Guide

© 2002-2007 IPLocks, Inc. All rights reserved

© 2002-2007 IPLocks, Inc. All rights reserved.

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 2

Attribute Descriptions .................................................................................................. 37

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 4

IPLocks Feature Summary

Figure 1: IPLocks Database Security and Compliance Solution

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 5

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 6

CLI Guide Introduction

Task Name Task Description Category

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 7

Task Name Task Description Category

Convention for File Locations and Environment Variables

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 9

The XML Input File

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 10

The project Element

The target Element

<target name = "targetName" [depends = "targetName"]>

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 11

Figure 3: Block diagram of Task Element

where [ ] enclose optional items.

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 12

1 cli.bat Uses cli_input.xml as its default XML

2 cli.bat –f addConnections.xml addConnections.xml is a user-

3 cli.bat –t target1 Uses cli_input.xml as the default

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 13

4 cli.bat –p my_task_values.properties Uses cli_input.xml as the default

5 cli.bat –t target1 \ 7 Uses cli_input.xml as the default

6 cli.bat >> output 2>&1 Sends the command output to a file

The Sample Input File

Specifying a Command-Line Input File

Specifying a Command-line Target

Specifying Task Values

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 14

Specifying Command-Line Task-Attribute Values

Example Task-Attribute-Values File:

Example XML Input File Snippet with Variables

Using the property task

Using the loadPropertyFile Task

Automatically Generated Task Values

Running Multiple Tasks

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 15

Using the List Type

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 16

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 17

host [IP address | fully qualified server name][:target-database port number].

database Database name

application Module in IPLocks. The possible values are:

unit Business unit

dba1tel Primary DBA phone number

dba1email Primary DBA e-mail

dba1name Primary DBA name

© 2002-2007 IPLocks, Inc. Version 6.2.00 Page 18

dba2email Secondary DBA e-mail

dba2name Secondary DBA name

audit Is database auditing enabled? Possible values: Y or N

useAgent Use an agent

agentPort Agent port

SqlClientPort SQL client port