revision a mcafee database security · pdf fileactivity monitoring and as an example for the...

Best Practices Guide Revision A

McAfee Database Security

2 McAfee Database Security Best Practices Guide

COPYRIGHT

Copyright © 2016 McAfee, Inc., 2821 Mission College Boulevard, Santa Clara, CA 95054, 1.888.847.8766, www.intelsecurity.com

TRADEMARK ATTRIBUTIONS

Intel and the Intel logo are registered trademarks of the Intel Corporation in the US and/or other countries. McAfee and the McAfee logo, McAfee Active Protection, McAfee DeepSAFE, ePolicy Orchestrator, McAfee ePO, McAfee EMM, McAfee Evader, Foundscore, Foundstone, Global Threat Intelligence, McAfee LiveSafe, Policy Lab, McAfee QuickClean, Safe Eyes, McAfee SECURE, McAfee Shredder, SiteAdvisor, McAfee Stinger, McAfee TechMaster, McAfee Total Protection, TrustedSource, VirusScan are registered trademarks or trademarks of McAfee, Inc. or its subsidiaries in the US and other countries. Other marks and brands may be claimed as the property of others.

LICENSE INFORMATION License Agreement

NOTICE TO ALL USERS: CAREFULLY READ THE APPROPRIATE LEGAL AGREEMENT CORRESPONDING TO THE LICENSE YOU PURCHASED, WHICH SETS FORTH THE GENERAL TERMS

AND CONDITIONS FOR THE USE OF THE LICENSED SOFTWARE. IF YOU DO NOT KNOW WHICH TYPE OF LICENSE YOU HAVE ACQUIRED, PLEASE CONSULT THE SALES AND OTHER

RELATED LICENSE GRANT OR PURCHASE ORDER DOCUMENTS THAT ACCOMPANY YOUR SOFTWARE PACKAGING OR THAT YOU HAVE RECEIVED SEPARATELY AS PART OF THE

PURCHASE (AS A BOOKLET, A FILE ON THE PRODUCT CD, OR A FILE AVAILABLE ON THE WEBSITE FROM WHICH YOU DOWNLOADED THE SOFTWARE PACKAGE). IF YOU DO NOT AGREE TO ALL OF THE TERMS SET FORTH IN THE AGREEMENT, DO NOT INSTALL THE SOFTWARE. IF APPLICABLE, YOU MAY RETURN THE PRODUCT TO MCAFEE OR THE PLACE OF

PURCHASE FOR A FULL REFUND.

http://www.intelsecurity.com/

McAfee Database Security Best Practices Guide 3

Revision History

Version Date Change Author

1.0 First release

1.1 March 2015 Additions of performance considerations Gilad Shriki

1.2 November

2016

Additional section added to describe the rule evaluation flow Gilad Shriki


Contents

Introduction 7 About this guide ................................................................................................................ 7 Find product documentation ................................................................................................ 7

1 Recommended rule objects 9 Generic rule objects ........................................................................................................... 9

admin_ips .................................................................................................................. 9 suspect_programs ....................................................................................................... 9 suspect_modules ......................................................................................................... 9 work_days ................................................................................................................ 10 work_hours .............................................................................................................. 10 admin_db_usernames ................................................................................................ 10 admin_os_usernames ................................................................................................ 10

Application-specific rule objects ......................................................................................... 11 <app>_allowed_programs – object type = application ................................................... 11 <app>_allowed_modules – object type = module ......................................................... 11 <app>_allowed_ips – object type = IP ......................................................................... 11 <app>_db_users – object type = user ......................................................................... 11 <app>_os_users – object type = osuser ...................................................................... 11 <app>_db_admins .................................................................................................... 11 <app>_os_admins – object type = osuser .................................................................... 11 <app>_sensitive_objects – object type = object ........................................................... 12 <app>_end_user_administrators – object type = clientid ............................................... 12 <app>_admin_modules – object type = module ........................................................... 12

Dynamic rule objects ........................................................................................................ 13 LDAP/Active Directory integration ................................................................................ 13 DVM Result-Set checks and data discovery checks ......................................................... 13

2 Recommended rules 15 Generic rules ................................................................................................................... 15

Restrict admin access ................................................................................................ 15 Alert on suspect programs .......................................................................................... 15 Alert on suspect activity ............................................................................................. 16 DDL activity .............................................................................................................. 16 DCL activity .............................................................................................................. 16

Application-specific rules .................................................................................................. 16 Restrict access to <app> ............................................................................................ 16 Protect <app> sensitive objects .................................................................................. 16 Restrict <app> administrators .................................................................................... 16 Restrict <app> admin modules ................................................................................... 17 Restrict DDL to sensitive objects ................................................................................. 17

3 Recommended rules and event settings 18 Security vs. audit policy considerations .............................................................................. 18

Security-oriented rules ............................................................................................... 18 Audit-oriented rules ................................................................................................... 18 Best practices ........................................................................................................... 18

Archive settings ............................................................................................................... 19 Rule-based archiving ................................................................................................. 19 Manual archiving ....................................................................................................... 19 Automatic archiving ................................................................................................... 19

Contents


Performance considerations .............................................................................................. 20 DDL/DCL triggers ...................................................................................................... 20 Statement rule keyword ............................................................................................. 20 Catch All rule ............................................................................................................ 20

4 Rule evaluation 22 Evaluation flow.......................................................................................................... 22 Allow rules ................................................................................................................ 22 Rule evaluation examples ........................................................................................... 23


Introduction

McAfee Database Security is an easy-to-deploy software solution that monitors the DBMS

Management System (DBMS) and protects it from both internal and external threats. McAfee Database

Security provides full visibility into DBMS user activity and can issue alerts or terminate suspicious

activities based on predefined vPatch rules and custom rules.

McAfee Database Activity Monitoring provides monitoring and management of database activity for

multiple databases and vPatch service. It also includes prevention, cluster support, third-party

integration, compliance modules, and advanced reporting functionality.

About this guide This document contains recommendations for creating custom rules and rule objects, and configuring

the policy properly. It should serve both as a starting point for the implementation of McAfee Database

Activity Monitoring and as an example for the ease of rule creation and management.

Note The examples provided in this document for rule objects and rules probably require refinement for each implementation.

Find product documentation Information about the product appears in the McAfee online Knowledge Center.

Task

1 Go to the Knowledge Center tab of the McAfee ServicePortal at http://support.mcafee.com.

2 In the Knowledge Base pane, click a content source:

Product Documentation to find user documentation

Technical Articles to find KnowledgeBase articles

3 Select Do not clear my filters.

4 Enter a product, select a version, and then click Search to display a list of documents.

http://support.mcafee.com/


1 Recommended rule objects

Rule objects are groups of values that can be used as replacement variables inside rules with the

$group_name notation. It allows you to decouple the rules from the actual parameters that the rules

apply to so that changing those parameters will affect all rules using the group without the need to

change the rules themselves.

Generic rule objects The generic groups are rule objects relevant to all applications and databases. These groups are used

later in generic rules as well as in application-related rules.

admin_ips Object type - IP

This group contains either a list of IP addresses for administrator machines or an administrative

subnet (if exists).

Example: 192.168.1.1, 192.168.1.2, 192.168.0.0/255.255.0.0

suspect_programs Object type - application

This pre-populated group contains a list of programs that allow you to directly manipulate database

content without the restrictions of an application. You can edit this group to add various applications

used in your organization that should be restricted.

Example – 'sqlplus', 'toad','DbVisualizer', 'SQL Developer', 'SQL Server Management Studio', 'osql', 'Microsoft Office', 'sqlcmd', 'plsqldeveloper', 'sqlplusw','sqlnavigator', 'dbartisan', 'tora' , 'rapidsql'

suspect_modules Object type - module

This group is essentially the same as the above suspect_programs group but contains a list of suspect

modules, such as ‘SQL*Plus’. Modules are harder to fake than applications.

Example – ‘SQL*Plus’, ‘T.O.A.D’

Recommended rule objects

Generic rule objects


work_days Object type = weekday

This pre-populated group contains the list of working days for your organization.

Example - MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY

work_hours Object type - hour

This group should contain a list of regular working hours.

Example – 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19

admin_db_usernames Object type - user

This group should contain the list of database administrator usernames.

Example – ‘sys’, ‘system’, ‘dbsnmp’, ‘sysman’, ‘sa’

admin_os_usernames Object type - osuser

This group should contain the list of administrator usernames.

Example – ‘joe’, ‘john’, ‘jane’


Application-specific rule objects


Application-specific rule objects These rule objects should be specified per application. The <app> notation in the rule object name

should be replaced with an acronym or abbreviation representing the actual application, such as CRM

or ERP.

<app>_allowed_programs – object type = application This group should contain the application names that comprise the application.

Example – ‘apps.exe’, ‘console’

<app>_allowed_modules – object type = module This group should contain a list of modules that the application uses. If the application passes the

module to the database, you can use this group.

Example – ‘admin’, ‘customer’, ‘account’

<app>_allowed_ips – object type = IP This group should contain the list of IP addresses allowed to access the application databases. You can

also use subnets.

Example – 192.168.0.0/255.255.0.0

<app>_db_users – object type = user This group should contain the database users that own or access the application data. Usually, a single

central database user owns all application tables in an application.

Example – ‘apps’

<app>_os_users – object type = osuser This group should contain the list of OS users for the application server (in case of three-tier

applications), or a list of allowed OS users in client server architecture.

Example – ‘local_system’, ‘oracle_ias’

<app>_db_admins This group should contain application-specific administrative accounts in the database.

Example – ‘apps_admin’

<app>_os_admins – object type = osuser This group should contain application-specific OS users that have administrative privileges in the

database.

Example - ‘joe’, ‘john’, ‘jane’


Application-specific rule objects


<app>_sensitive_objects – object type = object This group should contain the list of sensitive objects that require extra protection. Such objects are

usually tables containing sensitive data (PII, CC) or stored program units used for encryption or

decryption of sensitive data.

Example – ‘’customers’, ‘cc_table’, ‘encryption_pkg’

<app>_end_user_administrators – object type = clientid This group should contain a list of end-user, application administrative accounts. It can be used if the

application is setting the client_identifier database field.

Example – ‘joe’, ‘john’, ‘jane’

<app>_admin_modules – object type = module This group should contain a list of administrative modules in the application. If the application passes

the module to the database, you can use this group.

Example – ‘admin’, ‘account’


Dynamic rule objects


Dynamic rule objects Rule objects can also be populated by dynamic mechanisms to allow a better and simpler update of

the policy. With dynamic rule objects, the values can be acquired from different sources and then

referred to by the rules like other rule objects. This ensures that the policy is maintained with up-to-

date values, and there is little rule management overhead for ongoing maintenance.

The system enables a range of dynamic rule object sources to support different use cases as follows.

LDAP/Active Directory integration By integrating with LDAP/Active Directory systems, Database Activity Monitoring can gather the list of

users in specific LDAP groups into a user or osuser rule object. This is very useful when creating a

policy to monitor and audit specific users, for example, administrators or DBAs.

The system periodically queries the LDAP server for the specific group and updates the dynamic rule

object with the list of uses from that LDAP group. When the groups change (for example, when new

employees are hired or an employee leaves), the rule object is automatically updated, requiring no

changes to the policy itself.

Example – Pulling the administrators or DBA users list from the LDAP directory groups into a Dynamic

Rule Object, and enforcing an audit policy to monitor activity from those users (osuser keyword).

DVM Result-Set checks and data discovery checks The system enables rule object content to be acquired from DVM checks that return result sets or lists.

When integrating a DVM result with a dynamic rule object, the system updates the rule object values

each time the DVM check runs and returns values.

Example – Pull all users with DBA role in an Oracle database into a user-type, dynamic rule object,

and enforce an audit policy to monitor activity from those users (user keyword).

The DVM Result Set check syntax:

select user from TABLE where Role=DBA

Example – Pull all tables that contains email addresses into an object-type, dynamic rule object, and

enforce an audit policy to monitor activity on those tables (object keyword)

The DVM Data Discovery check syntax for Oracle:

select '"'||owner||'"."'||table_name||'"' as FQN, owner, table_name from all_tables;

The DVM Data Discovery check syntax for Microsoft SQL Server:

select '['+table_catalog+'].['+table_schema+'].['+table_name+']' as [FQN] ,

table_catalog,table_schema,table_name from information_schema.tables

The regular expression for finding email data:

\b[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}\b

XML API (for Standalone Management Server)

The Database Security Server also exposes XML API to manage the rule objects, allowing values from

external products to be changed. This enables creation of a proactive database security policy that can

be dynamically adapted to incidents identified by other security or non-security products.


Dynamic rule objects


Example – Add a list of IP addresses that other security products identified as compromised, and

create a policy to monitor and terminate database sessions created from those IP addresses on

sensitive databases (TBD keyword).

XML API documentation is available in KB72411.

ePO queries (for ePO-Integrated Management Server)

For ePO-Integrated Database Security Management, a rule object can also be populated by an ePO

query result. This allows cross-product integration within the ePO eco-system and is aligned with the

Intel Security’s overall Security Connected approach.

Example – Use a Systems query to detect all unmanaged systems in the environment, and create a

policy to audit all activities performed from those systems on the databases (TBD keyword).

ePO automatic response (for ePO-Integrated Management Server)

Another option for ePO-Integrated Database Security Management is to addvalues to an existing rule

object, based on an ePO automatic response triggered by a system event (in the Threat Event Log).

This also allows cross-product functionality.

Example – Create an automatic response for the anti-malware product (Endpoint Security), insert the

IP address of a compromised system that was detected with a virus, and create a policy to prevent

those systems from accessing sensitive databases across the organization (TBD keyword).

https://kc.mcafee.com/corporate/index?page=content&id=KB72411

Recommended rules

Generic rules


2 Recommended rules

We recommend that an organization create custom rules to protect its databases. To this end, you

should create database groups for test, staging and production. Rules should first be applied to the

test databases, then to staging, then to production.

If specific applications have multiple databases, we recommend creating a group for them as well.

Note that these rules should be viewed as recommendations and may require refinement for each

organization. We also recommend to create the rules with alert levels lower than the specified for the

first three months (while learning about the applications that connect to the database), then raise the

alert levels after the initial refinement.

For each rule, specify the rule name in the title, the actual rule text in quotation marks, and the

recommended level of alert.

Generic rules The following rules should be applied across all the databases (starting from the test group and

gradually moving to prod). They contain recommended generic protections to restrict access to

administrative accounts and to alert on unusual activities in the database.

Restrict admin access Alert = High

Rule = “user in $admin_db_usernames and (ip not in $administrator_ips or osuser not in $admin_os_usernames)”

Another option is to use generic rules per database, and monitor access to non-admin schemas by

admin built-in users.

Microsoft SQL Server:

USER in ('sa', 'domain\Administrator') and object matches '^(?!(master|model|msdb|tempdb|mssqlsystemresource)$).+\..*\..+'

Oracle:

USER in ('SYSTEM', 'SYS') and object matches

'^(?!(sys|system|public|oracle_ocm|flows_files|owf|olapsys|sysman|apex_.*|www_flow_.*)$).+\..+'

Alert on suspect programs Alert = Medium

Rule = “application contains $suspect_programs or module contains $suspect_modules”

Recommended rules

Application-specific rules


Alert on suspect activity Alert = Low

Rule = “weekday not in $work_days or hour not in $work_hours”

DDL activity Alert = Low

Rule = “cmdtype contains $ddl_cmdtypes”

DCL activity Alert = Medium

Rule = “cmdtype contains $dcl_cmdtypes”

Application-specific rules The following rules should be applied per application. We recommended you apply them to the test

databases first, then move gradually to the production database.

Restrict access to <app> Alert = Medium

Rule = “user in $app_db_users and (application not in $<app>_allowed_programs or module not in $<app>_allowed_modules or ip not in $<app>_allowed_ips or osuser not in $<app>_os_users)”

Protect <app> sensitive objects Alert = High

Rule = “object in $<app>_sensitive_objects and (user not in $<app>_db_users or application not in $<app>_allowed_programs or module not in $<app>_allowed_modules or ip not in $<app>_allowed_ips or osuser not in $<app>_os_users)”

Instead of using a list of sensitive objects, you can protect data based on the data owner. For

example, you might consider all tables owned by user APP as sensitive. In that case, the following rule

may be used in Oracle:

Rule = “object like ‘APP.%’ and (user not in $<app>_db_users or application not in $<app>_allowed_programs or

module not in $<app>_allowed_modules or ip not in $<app>_allowed_ips or osuser not in $<app>_os_users)”

Restrict <app> administrators Alert = High

Rule = “user in $app_db_admins and osuser not in $app_os_admins”

Recommended rules

Application-specific rules


Restrict <app> admin modules Alert = High

Rule = “module in $<app>_admin_modules and clientid not in $<app>_end_user_administrators”

Restrict DDL to sensitive objects Alert = High

This rule can be used as a more specific rule instead of the general DDL activity rule.

Rule = “object in $<app>_sensitive_objects and cmdtype contains $ddl_cmdtypes”

Recommended rules and event settings

Security vs. audit policy considerations


3 Recommended rules and event settings

Each rule can be configured to perform specific activities when triggered. These activities mainly

control how the system behaves when the rule is triggered, based on the activity information and the

rule syntax.

Security vs. audit policy considerations When planning the policy in general and rules in particular, it is best to first define the objective of a

specific rule – security or auditing.

This differentiation is important for identifying the target of the generated events, and helps ensure

system health and performance.

Security-oriented rules A security-oriented rule is a rule that requires an immediate action to be taken – either by the system

(for example, terminating a user, sending an email) or by the security team (for example, analyzing

the incident, performing investigation and forensics).

Security-related rules usually have a low event rate (tens or hundreds per day for all databases)

Audit-oriented rules An audit-oriented rule is a rule that stores the generated events for later analysis or for regulatory

purposes. An audit-related rule can trigger massive numbers of events (thousands or more per

database per day).

Best practices As a general best-practices rule-of-thumb, we recommend storing the security-related events in the

internal database security console (backend database) and pushing them to a third-party SOC/NOC

component, if available, for SOC/NOC team visibility. On the other hand, we recommend storing audit-

related events in the Archive system, or pushing them to a SIEM component.

We strongly recommended audit-related events not be stored to the database security

internal repository (console), to avoid overloading the system and clogging the backend

database to a point where the system performance is degraded.


Archive settings


Archive settings Regardless of the policy type, we recommend setting some automatic archiving procedures to perform

backend database cleanup, to maintain the system’s health and performance. The system’s internal

archiving mechanism provides a flexible and customizable functionality to maintain the database and

archive files, both manually and automatically.

When needed, archived events can be loaded to the system for audit, analysis, and forensic activities.

Reports can be run on loaded archived events.

Rule-based archiving For audit-related rules, it is best to configure the Archive option in the Rule Actions section, and have

the system automatically store the triggered events in archive files, without storing them in the

backend database. We recommended this because the events triggered by audit-related rules are

typically required for regulatory or forensic purposes only. They are not needed for day-to-day

operations.To enable this functionality, select Enable Archive Rule Action on the System | Archive | Settings page.

Then select Archive as the rule action on the rule definition page.

Manual archiving Events that are stored in the backend database can be archived manually when needed, in order to

clean the console and the backend repository.

Automatic archiving The system allows automatic archiving of events based on different criteria. When automatic archiving

is initiated, all events that match the criteria are moved from the backend database to a new archive

file.

Automatic archiving based on number of events

The system allows archiving events when a configured threshold for the number of events in the

database is reached. When the threashold is reached, the system archives a configured number of

events (the older).

The default value for the threshold is 100,000 and the default value for the number of events to

archive is 30,000.

To enable this functionality, select Auto archive by number of alerts, then set the threshold and number of

events to archive.

Automatic archiving based on time

The system also allows archiving events based on time. When activated (interval is configurable), the

system will archive all events older than the configured time threshold.

The default value for the interval can be hourly, daily or monthly, and the default value for the time

threshold is 7 days.

To enable this functionality, select Auto archive by time, then set the interval for auto-archive and the time

threshold.


Performance considerations


Performance considerations The database security sensor is a complex and robust component designed to work with large-scale

environments. The sensor has built-in default and dynamic configurations, allowing it to adapt its

performance based on the monitored traffic.

Nonethless, some specific scenarios should be considered, and sometimes avoided.

Although these scenarios are uncommon, it is important to be aware of their potential implications.

DDL/DCL triggers The DDL/DCL triggers can be used to introduce an artificial delay to DDL and DCL activity, which is

non-transactional (cannot be rolled-back). DDL/DCL triggers are optional. They are typically used in

scenarios where the project requirements mandate session termination and the blocking of DDL/DCL

activity.

If enabled, we recommend that the trigger be disabled for maintenance work such as database

upgrade, application server upgrades, or any other maintenance process that results in high rate of

DDL/DCL activity.

Statement rule keyword The statement rule keyword enables examination of the actual statement executed and creation of

specific rules for monitoring and auditing activity. Statements can sometimes be very large (up to 8KB

each), therefore special consideration is needed when using it in the rule syntax:

Creating a rule that looks only at the statement is discouraged.

STATEMENT LIKE ‘select%employee_id%from%hr.emplioyees%’

All statements in the system are evaluated. This is not efficient.

Due to the Database Security unique memory monitoring, each activity is monitored with its

execution plan, so evaluating objects is much more powerful using the object keyword instead

of looking at the statement.

For example, the following rule audits all select activity on the HR schema. Even if a user uses

database views in other schemas to access the data, the activity will be audited.

OBJECT = ‘he.employees’

We recommend you include prior filtering criteria before looking at the statement keyword.

CMDTYPE = ‘select’ and OBJECT = ‘hr.employees’ and STATEMENT LIKE ‘%employee_id%’

Catch All rule When implementing the system for the first time, it is common to create a Catch All rule to validate

the sensor is monitoring the database correctly. However, such a rule should be used while properly

monitoring the system, and for short duration. Loading the backend database with a high volume of

events, at a high rate, can severely affect the performance of the management server; in extreme

cases, it might render it completely inaccessible.




Although a Catch All rule can be implemented in various ways, we recommend using the user

keyword:f

user contains ‘’

In production or real-life environments, turning on such a rule can create a high event load nts. We

highly recommend to:

Store events to archive files and not the backend database (console)

Utilize rule safeguards (limit alerts per second or limit alerts per session)

Monitor the backend database load, and make sure not to overload it with events

Rule evaluation



4 Rule evaluation

vPatch rules are evaluated before custom rules. Rules are evaluated according to their positions on the

respective rule lists.

Evaluation flow The custom Database Activity Monitoring rules are evaluated according to their position on the Rules

list, meaning the topmost rule is evaluated first, then the second topmost, and so on. (You can

modify the order of the rules.)

When a rule is triggered (i.e., an activity matches the rule syntax), the sensor triggers an alert/event

for that activity on that rule. The action to be taken is specified in the rule itself. Possible actions

include sending an alert to the Database Security Console (i.e., send it to the Database Security

backend database), sending it to the syslog (i.e., any SIEM device), sending to an email recipient, and

so on. At least one action must be defined per rule.

When the syntax of a rule exception is matched, the rule does not create the alert or event. The

exception is only evaluated if the activity matches the rule syntax. An exception applies only to the

rule itself.

Regardless of whether the rule triggered an alert, the sensor continues to evaluate the other rules

according to their order in the list. If more than one rule triggers an alert due, the sensor triggers only

one alert, but it specifies all the triggering rules as part of that alert. The alert severity reflects the

highest severity level of the triggering rules.

Stop Verifying Additional Rules is an action option that tells the sensor to stop evaluating the other rules if

the rule is triggered (i.e., if an activity matches the rule syntax). The rule triggers the configured

action, but no further rules are evaluated for that activity.

Allow rules An allow rule enables you to whitelist an activity so it does not trigger any alerts. It is simply a rule

that does not trigger any action when matched except to stop evaluating subsequent rules. (The Stop

Verifying Additional Rules option is selected when an allow rule type is defined). When allow rule is created,

it should be placed at the top of Rules list.

When placed last in the Rules list, an allow rule has no impact.

When placed first in the Rules list, an allow rule casues any activity matched by the rule

syntax to undergo no additional checks, and no alerts are created for that activity.

vPatch policy is not affected by allow rules. vPatch rules are evaluated before the custom

rules.

Rule evaluation



Rule evaluation examples

Example 1:

Rules:

Order Syntax Exception Action

1 USER=’DBA’ Send to syslog

MEDIUM severity

2 USER=’DBA’ and CMDTYPE=’SELECT’

Send to email

HIGH severity

Activity and result:

Activity Result

User DBA logs in using sqlplus.exe Alert sent to syslog

MEDIUM severity

Runs “select * from emails” Alert sent to syslog and email

HIGH severity

Runs “delete from emails” Alert sent to syslog

MEDIUM severity

Example 2:

Rules:



MEDIUM severity


APPLICATION CONTAINS ’SQLPLUS’

Send to email

HIGH severity


Activity Result


MEDIUM severity

Runs “select * from emails” Alert sent to syslog

MEDIUM severity


MEDIUM severity

Rule evaluation



Example 3:

Rules:


1 APPLICATION CONTAINS ’SQLPLUS’

Allow rule


MEDIUM severity


Send to email

HIGH severity


Activity Result

User DBA logs in using sqlplus.exe No alerts

Runs “select * from emails” No alerts

Runs “delete from emails” No alerts

Example 4:

Rules:



MEDIUM severity


Send to email

HIGH severity

3 APPLICATION CONTAINS ’SQLPLUS’

Allow rule


Activity Result


MEDIUM severity


HIGH severity


MEDIUM severity

Rule evaluation



Example 5:

Rules:



MEDIUM severity

Stop verifying rules


Send to email

HIGH severity


Activity Result


MEDIUM severity


MEDIUM severity


MEDIUM severity

revision a mcafee database security · pdf fileactivity monitoring and as an example for the...

Documents