Accelerate your Database

Activity Monitoring readiness

to comply with Reserve Bank
of India (RBI) Guidelines

June 2020 | Version 20.01

Copyright © 2020, Oracle and/or its affiliates
PURPOSE
This technical white-paper provides an overview of Database Activity Monitoring requirements for compliance with the RBI
Guidelines on Cyber Security. The white-paper is intended to help you accelerate your readiness to RBI compliance for
Database Activity Monitoring requirements by leveraging Oracle Database’s native auditing feature, and Oracle Audit Vault
and Database Firewall (AVDF) product.

INTENDED AUDIENCE
Intended audience would include key stakeholders like CIOs, CISOs, Executive Directors, business unit heads, heads of
internal audit, operational risk, compliance and fraud management from all of the financial institutions regulated by RBI in
Indian sub-continent. If you are responsible for designing, implementing, maintaining, or operating security controls for
database systems, this paper is intended for you to help accelerate compliance with RBI guidelines on Database Activity
Monitoring requirements.

DISCLAIMER
This document in any form, software or printed matter, contains proprietary information that is the exclusive property of
Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle software
license and service agreement, which has been executed and with which you agree to comply. This document is not part of
your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.
This document is for informational purposes only and is intended solely to assist you in planning for the implementation
and upgrade of the product features described. It is not a commitment to deliver any material, code, or functionality, and
should not be relied upon in making purchasing decisions. The development, release, and timing of any features or
functionality described in this document remains at the sole discretion of Oracle.

The information in this document may not be construed or used as legal advice about the content, interpretation or
application of any law, regulation or regulatory guideline. Customers and prospective customers must seek their own legal
counsel to understand the applicability of any law or regulation on their processing of personal data, including through the
use of any vendor’s products or services.

LEGAL DISCLAIMER
The purpose of this document is to help organizations understand how Oracle Database Security technology can be utilized
to help comply with certain Reserve Bank of India requirements. Some of the Oracle Database Security technologies may or
may not be relevant based upon an organization’s specific environment. Oracle always recommends testing security
solutions within your specific environment to ensure that performance, availability and integrity are maintained.
The information in this document may not be construed or used as legal advice about the content, interpretation or
application of any law, regulation or regulatory guideline. Customers and prospective customers must seek their own legal
counsel to understand the applicability of any law or regulation on their processing of personal data, including through the
use of any vendor’s products or services.

1 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
TABLE OF CONTENTS
Purpose 1
Intended Audience 1
Disclaimer 1

Legal Disclaimer 1
Table of Contents 2
Introduction 3
RBI CIRCULARS 3

EXECUTIVE SUMMARY 4
1. RBI Guidelines for Database Auditing 7
1.1. Sensitive Data Access 7
1.2. Access Control 10
1.3. Privileged User Access 12
1.4. Application Activity 13
1.5. Inactive User Accounts 16
1.6. Specific Components 17

2. RBI Guidelines for Ensuring Audit Integrity 18

Recommendations: 19

3. RBI Guidelines for Continuous Surveillance 21

Recommendations: 24

4. RBI Guidelines for Monitoring Network Traffic 33

4.1. Network Segmentation 33
4.2. Deployment Topology 35
4.3. Firewall Policy 37

Conclusion 45
Appendix 45
Application Activity Auditing Sample 45

2 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
INTRODUCTION
The Reserve Bank of India (RBI) exercises supervision and control over banks and non-banking finance companies in India.
This includes a mandate to encourage data security practices that protect citizen’s privacy, minimize the opportunity for
fraud, and improve the integrity of financial transactions.

The Reserve Bank of India issued guidance in April 2011 for banks to mitigate the risks of use of information technology in
banking operations. RBI Guidelines are the result of the Working Group's recommendations on information security,
electronic banking, technology risk management and cyber fraud. The Working Group was formed under the chairmanship
of G. Gopalakrishna, the executive director of RBI in April 2010.

RBI’s initial guidance on cyber security was issued in 2011, and additional circulars have been issued over the years, as listed
below. Database Activity Monitoring is one of the key requirements for RBI compliance. This paper examines Oracle
Database security capabilities that can be used to help comply with RBI Guidelines for Database Activity Monitoring.

RBI CIRCULARS
RBI Circular dated April 29, 2011 on “RBI Circular: Working Group on Information Security, Electronic Banking, Technology
Risk Management and Cyber Frauds- Implementation of recommendations”
https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=6366&Mode=0

Guideline Reference (Ref 1): http://rbidocs.rbi.org.in/rdocs/content/PDFs/GBS300411F.pdf

In a June 2, 2016 notification, RBI released a circular on the “Cyber Security Framework for Banks”, as an extension of the
circular of April 29, 2011. The circular says that scheduled commercial banks (private, foreign and nationalized banks listed in
the schedule of RBI Act, 1934) must proactively create or modify their policies, procedures and technologies based on new
security developments and concerns.
RBI Circular dated June 2, 2016 on “Cyber Security Framework in Banks”
https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=10435&Mode=0

Guideline Reference (Ref 2):

https://rbidocs.rbi.org.in/rdocs/notification/PDFs/NT41893F697BC1D57443BB76AFC7AB56272EB.PDF

RBI developed new norms to scale up the cyber-security and resilience framework at the urban cooperative banks (UCBs)
with its circular dated October 19, 2018.
RBI Circular dated October 19, 2018 on “Basic Cyber Security Framework for Primary (Urban) Cooperative Banks (UCBs)”

https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11397&Mode=0

RBI recommended a basic cyber security framework to be implemented by all the UCBs (Ref 3):
http://rbidocs.rbi.org.in/rdocs/content/pdfs/63NT19102018_A1.pdf
On December 31, 2019, RBI released the below circular on a comprehensive Cyber Security Framework for UCBs:

RBI Circular dated December 31, 2019 on “Comprehensive Cyber Security Framework for Primary (Urban) Cooperative Banks
(UCBs) – A Graded Approach”
https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11772&Mode=0

Guideline Reference (Ref 4):

https://rbidocs.rbi.org.in/rdocs/notification/PDFs/NOTI129BB26DEA3F5C54198BF24774E1222E61A.PDF

3 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
EXECUTIVE SUMMARY
As the banking and financial sector industry in India prepares for RBI compliance on cyber security regulations, Database
Activity Monitoring (DAM) is one of the key requirements. RBI mandates a Security Operations Centre (SOC) be set up at the
earliest to ensure continuous surveillance. Banks need to ensure the protection of various personal and sensitive
information collected from consumers and preserve its Confidentiality, Integrity and Availability regardless of whether the
data is stored (or in transit) within the bank, with customers, or with third party vendors. RBI recommends that banks
address network and database security comprehensively.

Database Activity Monitoring is crucial for compliance with the RBI Guidelines on Cyber Security. Some of the key references
in RBI Guidelines that highlights the DAM requirements are mentioned.

RBI Guidelines Source DAM Requirements

highlighted

The fundamental attributes supporting data quality should include Ref 1, Page 10 Auditability of data for
accuracy, integrity, consistency, completeness, validity, timeliness, ensuring data quality.
accessibility, usability and auditability.

Accountability and auditability: An organization’s security policy Ref 1, Page 11 Auditability of user
can be properly enforced only if accountability is maintained, i.e., activities to ensure
security can be maintained only if subjects are held accountable accountability.
for their actions. Effective accountability relies upon the capability
to prove a subject’s identity and track their activities. Accountability
is established by linking a human to the activities of an online identity
through the security services and mechanisms of auditing,
authorization, authentication, and identification.

Banks need to define and implement procedures to ensure the Ref 1, Page Ensuring data integrity
integrity and consistency of all data stored in electronic form, such as 29, Item 15.i and consistency.
databases, data warehouses and data archives.

Digital evidence is similar to any other form of legal proof - it needs Ref 1, Page Audit data as a form of
to withstand challenges to its integrity, its handling must be carefully 16, Item 1.5 digital evidence.
tracked and documented, and it must be suitably authenticated by
concerned personnel as per legal requirements

Achieving robust security (security assurance) is not a onetime Ref 1, Page Monitoring of user
activity. .. It is a continuous process that requires regular assessment 136, Item behavior for suspicious
of the security health of the organization and proactive steps to 8.2.(d) activities and forensics.
detect and fix any vulnerability. Every bank should have in place
quick and reliable access to expertise for tracking suspicious
behavior, monitoring users and performing forensics.

Hence, it is mandated that a SOC (Security Operations Centre) be Ref 2, Page 2, Ability to provide
set up at the earliest, if not yet been done. It is also essential that this Item 6 continuous surveillance.
Centre ensures continuous surveillance

Comprehensively address network and database security: Recent Ref 2, Page 3, Comprehensive need for
incidents have highlighted the need to thoroughly review network Item 9 database auditing and
security in every bank. … It is essential that unauthorized access to network monitoring.
networks and databases is not allowed and wherever permitted,
these are through well-defined processes which are invariably
followed.

Cyber Crisis Management Plan: CCMP should address the following Ref 2, Page 4, Prompt detection of
four aspects: (i) Detection (ii) Response (iii) Recovery and (iv) Item 12 intrusions and response is
Containment. Banks need to take effective measures to prevent needed.
cyber-attacks and to promptly detect any cyber-intrusions so as
to respond / recover / contain the fall out. Banks are expected to be

4 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 well prepared to face emerging cyber-threats such as ‘zero-day’ Detect cyber-intrusions
attacks, remote access threats, and targeted attacks. by alerting on anomalies
in database access
patterns.

Constant and Continuous monitoring of the environment using Ref 2, Page Enable constant and
appropriate and cost effective technology tools, clearly defined 18, Item continuous proactive
policies and procedures based on best practices and monitored by 3,Item 4.2, monitoring.
technically competent and capable manpower is the urgent need for
Item 4.4
the Industry.

Take into account proactive approaches rather than reactive

approaches and have to also address possible unknown attacks. For
example, zero day attacks and attacks for which signatures are
not available have to be kept in mind

Cyber SoC has to take into account proactive monitoring and

management capabilities with sophisticated tools for detection,
quick response and backed by data and tools for sound analytics.

Incident investigation, forensics and deep packet analysis need to

be in place
Analytics with good dash board, showing the Geo-location of the IP’s

Audit Logs: Capture the audit logs pertaining to user actions in a Ref 4, Page 6 Comprehensive audit logs
system. Such arrangements should facilitate forensic auditing, if , Item to support forensic
need be. An alert mechanism should be set to monitor any change in 10.1,Item10.2 investigation.
the log settings.
An alert mechanism to
detect changes to audit
settings.

Technology framework designed and implemented to ensure Ref 2, Page To processes audit logs
proactive monitoring capabilities 20, Item 5 from a variety of database
and operating system
Identification of the location for the sensors to collect the logs that
platforms, normalizing
are required to carry out the analysis and investigation
the data elements and
Security analytics engine which can process the logs within making them ready for
reasonable time frame and come out with possible recommendations timely analysis and
reporting.
Deep packet inspection approaches

Technology for improving effectiveness and efficiency (tracking of

metrics, analytics, scorecards, dashboards, etc.)

For accountability purposes, a bank should ensure that users and IT Ref 1, Page To be able to audit
assets are uniquely identified and their actions are auditable. 20, Item database users and their
5.(viii) actions.

Cyber Security Operations Centre should have the capacity to Ref 2, Page 7, Need real time/ near real
monitor various logs / incidents in real time / near real time. Item c time monitoring of logs
for analysis and
detection.

Establish and implement a Security Operations Centre for centralised Ref 2, Page Centralized and
and coordinated monitoring and management of security related 16, Item coordinated monitoring
incidents. 19.6.b required.

Have support/ arrangement for network forensics/forensic Ref 2, Page Network forensics
investigation/DDOS mitigation services on stand-by 17, Item 22.1 capability.

5 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
Core DAM requirements of RBI can be broadly classified into four categories. This paper details the RBI requirements for
each category, followed subsequently by Oracle Database security recommendations for each of this category to help
comply with RBI Guidelines.

1. RBI Guidelines for Database Auditing

2. RBI Guidelines for Ensuring Audit Integrity
3. RBI Guidelines for Continuous Surveillance
4. RBI Guidelines for Monitoring Network Traffic

Oracle Database security recommendations for activity monitoring and auditing include the use of database auditing (a core
feature of the Oracle Database), along with Oracle Audit Vault and Database Firewall (a separately licensed product).
Together, these provide a comprehensive DAM solution that help address the RBI activity monitoring requirements. Oracle
Audit Vault and Database Firewall (AVDF) collects audit data from many different types of systems, monitors and analyzes
network SQL traffic to databases, and takes appropriate action before the SQL reaches the database. AVDF combines native
database audit logs with captured network SQL traffic and stores it in a centralized, secure warehouse for analysis and
reporting. AVDF includes host-based agents for collecting audit data from multiple targets, data retention options, reporting
and analysis tools, alert generation and integration with SIEM tools, an audit dashboard, and a comprehensive set of
customizable reports for security and compliance. Delivered as a soft appliance, a single Audit Vault Server consolidates
database audit logs and network-based database activity events from multiple databases.
AVDF Architecture diagram:

AVDF combines two complementary data streams to deliver a complete DAM solution.

a) Native database auditing that provides a complete view of database activity along with full execution context
irrespective of whether the statement was executed directly, through dynamic SQL, or through stored procedures.
b) Network-based monitoring that is independent of the database type and requires no modification to the databases.
Network-based monitoring uses the Database Firewall component of AVDF, compatible with multiple
heterogeneous database systems simultaneously.

RBI Guidelines on cyber security recommend a Database Activity Monitoring solution that combines native database
auditing with network-based monitoring. The rest of the paper details requirements in each of the RBI Guidelines categories,
followed by recommendations involving Oracle Database auditing feature and AVDF.

6 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 1. RBI GUIDELINES FOR DATABASE AUDITING

Database auditing is an important component of Database Activity Monitoring. Database auditing involves creating and
enabling database policies to track the use of database objects and users. When auditing is enabled, database activities on
specified objects and users produce an audit trail of these operations. Each generates an audit record that includes what
database operation was performed, the database objects involved, who performed the operation, time of execution, and the
SQL statement itself.

RBI guidelines recommend tracking who did what to which piece of data, capturing when and how it was changed, and
preserving the evidence for forensic investigation. Database auditing is important because there are many threats to the
security of your data, including external agents trying to compromise your security and access your company data, and
internal agents within your organization. The most typical security threat comes from a disgruntled or malevolent current or
ex-employee who has access to the database. Auditing is crucial to find an unauthorized access emanating from an
authorized user.

As auditing occurs post-activity, it does not do anything to prohibit access. Auditing helps ensure data integrity by
facilitating the timely detection of security breaches, thereby mitigating risks quickly. An audited system is a deterrent
against users tampering with data because it helps to identify infiltrators.

Oracle Database provides the industry’s most comprehensive auditing capability, enabling the capture of detailed
information. Oracle Database provides predefined audit policies that cover commonly used security-relevant audit
requirements such as logon failures, database configuration parameter changes, user account and privilege management,
etc. Additionally, one can create custom audit policies specific to the user, database object, privilege, role or action that
needs to be audited. Build selective and effective audit policies by adding various conditions including SYS_CONTEXT and
Application Context values, enabling the capture of audit information from applications.

The requirements from RBI for database auditing fall into the following categories. Subsequent sections highlight the
requirements and recommendations:

1.1. Sensitive Data Access

1.2. Access Control
1.3. Privileged User Access
1.4. Application Activity
1.5. Inactive User Accounts
1.6. Specific Components

1.1. Sensitive Data Access

RBI Guidelines recommend implementing Information Security Management System (ISMS) best practices for their critical
functions/processes. Adherence to ISMS Standards like ISO 27001 and ISO 27002 emphasizes the need to classify
information assets (applicable to data in the database) as sensitive /critical, and establish security measures commensurate
with the sensitivity and criticality of the data.

RBI Guidelines Source Audit

Implication

Banks need to establish a classification scheme that applies throughout the Ref 1, Page 8, Sensitive data
enterprise, based on the criticality and sensitivity (e.g. public, confidential, or item 1.j classification.
top secret) of enterprise data. This scheme should include details of data
ownership; definition of appropriate security levels and protection controls;
and a brief description of data retention and destruction requirements
(criticality and sensitivity).

… Banks also need to define and implement procedures to ensure integrity

and consistency of data stored in electronic form.

7 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 Maintain an up-to-date inventory of Assets, including business Ref 2, Page 7,
data/information including customer data/information, ….. indicating their item1.1, item
business criticality. .. 1.2 , item 1.3

Classify data/information based on information classification/sensitivity

criteria of the bank
Appropriately manage and provide protection within and outside organisation
borders/network taking into consideration how the data/information are
stored, transmitted, processed, accessed and put to use within/outside the
bank’s network, and level of risk they are exposed to depending on the
sensitivity of the data/information.

Standards like ISO27001 and ISO 27002 are explicit in requiring a risk Ref 1, Page 16, Auditing and
assessment to be carried out before any controls are selected and item 2.2, item monitoring of
implemented and are equally explicit that the selection of every control must 2.3 data to be
be justified by a risk assessment. commensurate
with its
Data Leak Prevention Strategy: Develop and implement a comprehensive Ref 4, Page 6,
sensitivity /risk.
data loss/leakage prevention strategy to safeguard sensitive (including item 9.1
confidential) business and customer data/information.

Information assets have varying degrees of sensitivity and criticality in Ref 1, Page 17, Auditing of user
meeting business objectives. By assigning classes or levels of sensitivity and item 3 access to
criticality to information resources and establishing specific security sensitive data.
rules/requirements for each class, it is possible to define the level of access
controls that should be applied to each information asset.

There should be controls on updating key ‘static’ business information like Ref 1, Page 25, Track customer
customer master files, parameter changes, etc. item 11.11 data changes in
applications.

More sensitive information such as system documentation, application source Ref 1, Page 30, Tracking
code, and production transaction data should have more extensive controls item 15.v production data
to guard against alteration changes.

Highly sensitive and/or critical IT assets would need to have logging enabled Ref 1, Page 32, Security
to record events and monitored at a level proportional to the level of risk. item 17.v monitoring in
proportion to
the risk.

Banks should be proactive to identify and specify the minimum security Ref 1, Page 83, Monitoring PII
baselines to be adhered to by the service providers to ensure confidentiality item 2.v data/critical
and security of data. This is particularly applicable where third party service customer data
providers have access to personally identifiable information and critical access when
customer data. outsourced.

Discuss and agree on the instances where customer data shall be accessed
and the user groups who will have access to the same. Access to a Bank’s data
should be strictly on a need to know basis

Recommendations:

Databases frequently contain sensitive data – data whose access should be controlled and monitored. Examples of sensitive
data might include financial results, credit card numbers, email addresses, and personal data that describes an employee or
customer.

There are a few ways to identify and categorize sensitive data in the Oracle Database. One of them is with Oracle Database
Security Assessment Tool (DBSAT). DBSAT provides various reports of sensitive data summary from the scan of database
metadata. A sample screenshot from DBSAT report showing sensitive columns is given below.

8 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
Oracle Database Auditing Controls:
Once you identify sensitive data, create object action audit policies on access to the specific sensitive objects. The audit
can include both DDL and DML statements used on the object. To learn more about object action auditing, refer to ‘Auditing
Object Actions’ in the Oracle Database Security Guide.
Enforce the object action audit policies on following users:

Application service accounts: These are database users used by an application to perform a defined set of standardized
business functions

Human actors: These are database users granted access to the database to generate reports, perform ad-hoc queries or
otherwise interact with data.

For application service accounts, focus on trusted path when designing your audit policy. By trusted application path, we
mean the collection of session attributes that help define access to sensitive data that is expected and within policy. For
example, activity that originates from a known set of IP addresses, using a pre-approved program running as a designated
operating system user. Sensitive data access through the trusted path presents a lower level of risk, and therefore needs a
lower level of auditing, or may not need to be audited at all. Sensitive data access by an application service account outside
of the trusted path indicates the account is being used for something other than application access, and therefore presents a
higher level of risk and therefore a higher level of audit is required. Consider auditing all activity on the sensitive data by the
accounts that is not within the trusted path. Consider adding the conditions for excluding the trusted path in the audit policy
configuration to audit only the abnormal access by application service accounts. Using the Oracle Database conditional
auditing features, construct the audit policies to capture object access that is outside of the trusted path of the application.

For human actors authorized to interact directly with sensitive data, a higher level of auditing is almost always appropriate.
RBI Guidelines mandate direct access to the database must be restricted only to the database administrator and emphasizes
that direct back-end updates to database should not be allowed except during exigencies, with a clear business need and
after due authorization. If the version of your Oracle Database supports the ability to audit only the top-level SQL activities,
consider auditing all top-level statements by these users, including accounts with administrative privileges, and accounts
that have been granted the DBA roles.

RBI Guidelines mandate tracking access to personally identifiable information and critical customer data. Consider creating
Fine-Grained Auditing (FGA) policies in the Oracle Database to audit sensitive personally identifiable information (PII) data
stored in specific columns. Using FGA parameters like audit_condition and audit_column, audit behavior can be fine -tuned
to target specific sensitive columns in the table and for specific conditions (for example, auditing SQL statements against the
salary column only in cases where the salary amount is greater than 100,000 INR). Consider enforcing audit policies for
specific users with audit_condition based on factors like session user from SYS_CONTEXT to ensure that only specific users
will be audited. This will be effective for enforcing the policy for third party service providers as emphasized in RBI
Guidelines. Consider configuring alerts that take effect when a user (or an intruder) violates the policy by extending the FGA

9 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
policy to send out emails when such a condition happens. Additionally, consider leveraging alerting feature in Audit Vault
and Database Firewall, which allows alerts to be created and emailed, and can be integrated with a SIEM product. Refer to
‘Auditing Specific Activities with Fine-Grained Auditing’ in the Oracle Database Security Guide for FGA configuration
details.

Implementing Continuous Monitoring Controls:

To monitor continuously and detect suspicious transactions/behaviors in an effective way, leverage the following features
of the Oracle Audit Vault and Database Firewall (AVDF):

1. Monitor activity on sensitive data access using ‘Activity on Sensitive Data’ data privacy report, as detailed in the
section Establish Proactive Security Monitoring Practices, including Sensitive Data Access.
2. Define alerts on DML activity on sensitive data access events. Use alert conditions with appropriate data access
audit events (INSERT, UPDATE, and DELETE) and TARGET_OBJECT to reflect the sensitive tables in the schema.
Refer to Define Alerts that are Actionable and Granular.
3. Monitor activity on sensitive data by privileged users by using the report ‘Activity on Sensitive Data by
Privileged Users’ data privacy report.

1.2. Access Control

RBI Guidelines require banks adhere to the access control principles of “least privilege”, and “need to know” commensurate
with the job responsibilities, and adequate “segregation of duties”. Some of the activities that need to be closely monitored
and tracked are listed below.

RBI Guideline Source Audit and Access

Control Implications

Identification of any unauthorised changes Ref 1, Page 16, Security control for
item 1.4 unauthorized changes.

Internal sabotage, clandestine espionage or furtive attacks by Ref 1, Page 19, Ability to track internal
trusted employees, contractors and vendors are among the most item 5.(i) , item and external user
serious potential risks that a bank faces. Current and past 5.(ii), item 5.(v) activities, including
employees, contractors, vendors and those who have an intimate privileged access to
knowledge of the inner workings of the bank’s systems, sensitive assets.
operations and internal controls have a significant advantage over
external attackers….

Hence, access to information assets needs to be authorised by a

bank only where a valid business need exists and only for the specific
time period that the access is required.

The examples where increased authentication strength may be

required, given the risks involved include : administration or other
privileged access to sensitive or critical IT assets, remote access
through public networks to sensitive assets and activities carrying
higher risk like third-party fund transfers, etc.

Conducting a risk assessment and granting access rights based on Ref 1, Page 20, Ability to track changes
the same. For example, contractors and temporary staff would have item 5. to user accounts and
higher inherent risks. Implementation of role-based access control (vi).b,c,e,f,g,h,k , privilege grants to spot
policies designed to ensure effective segregation of item 5. (viii) changes and identify
duties…..Modification of access rights whenever there is a change candidate accounts for
in role or responsibility and removal of access rights on cessation of removal.
employment .. Processes to notify in a timely manner the
information security function regarding user additions, deletions
and role changes ..Periodic reconciliation of user ids in a system and
actual users required to have access and deletion of unnecessary ids,

10 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 if any … Audit of logging and monitoring of access to IT assets by all
users…Considering de-activating user ids of users of critical
applications who are on prolonged leave

For accountability purposes, a bank should ensure that users and IT

assets are uniquely identified and their actions are auditable.

Personnel with elevated system access entitlements should be Ref 1, Page 20, Capture activity
closely supervised with all their systems activities logged… item 5.(xiii) information of
privileged users.
Granting privileged access on a “need-to-have” or “need-to-do”
basis
Instituting strong controls over remote access by privileged users

Maintaining audit logging of system activities performed by

privileged users

Disallowing vendors and contractors from gaining privileged access

to systems without close supervision and monitoring

Access should be based on the principle of least privilege and Ref 1, Page 25, Application access
“need to know” commensurate with the job responsibilities. item 11.c.10 control.
Adequate segregation of duties needs to be enforced.

Banks use third-party service providers in a variety of different Ref 1, Page 38, Unauthorized access by
capacities. It can be an Internet service provider (ISP), application or item 23.i third-party service
managed service provider (ASP/MSP) or business service provider providers.
(BSP). These providers may often perform important functions for
the bank and usually may require access to confidential
information, applications and systems.

Network access by system engineers should be monitored and Ref 1, Page 46, Unauthorized access
reviewed closely to detect unauthorized access to the network. item 24.viii.r,s over network.

Another important security improvement is the ability to identify

users at every step of their activity.

Disallow administrative rights on end-user Ref 2, Page 11, User access control.
workstations/PCs/laptops and provide access rights on a need to item 8.3 ,item
know basis and for specific duration when it is required following an 8.4
established process.

Implement centralised authentication and authorisation system or

accessing and administering applications, operating systems,
databases, network and security devices/systems, point of
connectivity (local/remote, etc.) …… following the principle of least
privileges and separation of duties.

Recommendations:

Oracle Database Auditing Controls:

When a database user is granted database privileges that exceed the requirements of their job function, those privileges can
be potentially abused. Frequently, administrators grant excessive privileges to avoid the risk of application failure due to lack
of access privileges. Thus, users may be granted generic or default access privileges that far exceed their specific job
requirements, or they may simply accumulate such privileges over time. System privileges can be very powerful, and should
be granted only when necessary to roles and trusted users of the database and should be monitored very closely. RBI
Guidelines emphasize the need to closely supervise users with elevated system entitlements, ensuring all their activities are
logged.

11 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
Identify the system privileges that are granted to database users and which are being currently used /not used from the
output of the Privilege Analysis. Refer to ‘Performing Privilege Analysis to Find Privilege Use’ in the Oracle Database
Security guide for more details on configuration of Privilege Analysis.

Consider creating an audit policy to track all top-level activities by users who are granted roles that contain used /unused
system privileges, which can be obtained from Privilege Analysis. Audit policies are enforced for users who have been
granted the specified role directly or indirectly.

RBI Guidelines recommend monitoring administrator or other privileged access to sensitive or critical IT assets. Consider
auditing object actions, instead of auditing the privilege use, of administrative users such as SYS. Refer to Sensitive Data
Access, where it is detailed.

Ensure the predefined Oracle audit configuration policy – “ORA_ACCOUNT_MGMT” is enabled in the environment to track
database accounts and access modifications attempts. RBI Guidelines recommend monitoring of any modification of
database access rights whenever there is a change in role or responsibility, and removal of access rights upon cessation of
employment, and other account modifications like user additions and deletions.

RBI Guidelines place special emphasis on monitoring unauthorized access and changes to systems, applications or data, by
third-party service providers like an Internet service provider (ISP), application or managed service provider (ASP/MSP) or
business service provider (BSP). Consider using role-based access control for these user accounts to make it easy to create
policies for such users. For example, one can audit all top-level activities for users granted the role “service_provider” using
the ‘by users with granted roles’ clause in audit policy configuration. The role “service_provider” can be used to assign the
appropriate privileges for users who are providing the managed services.

Implementing Continuous Monitoring Controls:

To monitor access controls and detect suspicious transactions/behaviors in an effective way, leverage the following features
of Oracle Audit Vault and Database Firewall:

1. Track changes to user accounts and their roles/privileges using the entitlement reporting functionality contained
within AVDF. Consider using the baseline comparative features within this reporting to highlight only privileges that
have changed since the last report was reviewed. Refer to Establish Proactive Security Monitoring Practices,
including Sensitive Data Access for details.
2. Define alerts on account modification audit events (CREATE/ DROP/ ALTER USER, CREATE/ DROP/ ALTER
PROFILE). Use alert conditions with TARGET_TYPE (USER, PROFILE).
3. Create a custom report to monitor activity on sensitive data access by users who need to be closely tracked like
third-party service providers. Use the ‘Activity on Sensitive Data’ data privacy report as detailed in the section
Establish Proactive Security Monitoring Practices, including Sensitive Data Access.

1.3. Privileged User Access

RBI Guidelines requires closely monitoring users with elevated access privileges, including system administrators, database
administrators, and security officers, as mentioned below.

RBI Guideline Source Audit Implication

System administrators, security officers, programmers and Ref 1, Page 20, Audit usage of system
staff performing critical operations invariably possess the Item 5.(xiii) access entitlements by
capability to inflict severe damage on the banking systems privileged users.
they maintain or operate by virtue of their job functions and
privileged access. Personnel with elevated system access
entitlements should be closely supervised with all their
systems activities logged, as they have inside knowledge and
the resources to circumvent systems controls and security
procedures

Users, like system administrators, with elevated access Ref 1, Page 32, Monitoring of users with
privileges should be subjected to a greater level of monitoring Item 17.(vi) elevated privileges.
in light of the heightened risks involved.

12 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 Direct back-end updates to database should not be allowed Ref 1, Page 25, Restriction on back-end
except during exigencies, with a clear business need and after Item 11.c.16,17 updates to database
due authorization as per the relevant policy. administrator and
monitoring/auditing of
Access to the database prompt must be restricted only to the
such activities.
database administrator.

Implement appropriate (e.g. centralised) systems and controls Ref 2, Page 11, Monitor and log
to allow, manage, log and monitor Item 8.5 administrative access.
privileged/superuser/administrative access to critical systems
(Servers/OS/DB, applications, network devices etc.).

Recommendations:

Oracle Database Auditing Controls:

Users with elevated access privileges in the database like database administrators must be closely monitored and all their
actions audited. Top-level statements (direct SQL statements executed) by users with administrative privileges (e.g.
SYSDBA, SYSKM) are already audited mandatorily when the database is in the closed or mount state. When the database is
open, capture all top-level actions of administrative user accounts with an audit policy configured for this activity. Turn off
the audit policy during maintenance operations like upgrade /patching to reduce the audit record volume and re-enable
them post the maintenance operations window. Enable the audit policy for user accounts with administrative privileges, and
for accounts that have been granted the DBA roles.

All the database administrator activities happening through direct back-end updates to database (which are typically
provided only to privileged users) are audited using the audit policy configuration described in the section Sensitive Data
Access.

Implementing Continuous Monitoring Controls:

Consider configuring the alerts for the following events in Oracle Audit Vault and Database Firewall for users with
administrative privileges, and user accounts that have been granted the DBA roles: CREATE/DROP DATABASE LINK, Object
Management Events like CREATE/DROP/ALTER on TABLE, VIEW, INDEX and other important administrative functions as
applicable in the environment. Fine-tune the alert conditions with session attributes like Client ID so that authorized direct-
access connections are filtered out and the alert is fired only on suspicious activities of users with elevated privileges.

Consider monitoring the activities of privileged users with the ‘Activity on Sensitive Data by Privileged Users’ data privacy
report to track any suspicious activity.

1.4. Application Activity

RBI Guidelines recommend application access to data be monitored closely and be flexible enough to accommodate any
client session attributes for forensics, as mentioned in the following references.

RBI Guideline Source Audit Implication

Application owner: Establishing user access criteria, Ref 1, Page 18, Item 4 Audit trail
availability requirements and audit trails for their configuration
applications needed for
applications.

Application owners grant legitimate users access to Ref 1, Page 21, Item 7.(i) Internal user threat
systems that are necessary to perform their duties and needs to be
security personnel enforce the access rights in accordance considered and
with institution standards. Because of their internal access actions of internal
levels and intimate knowledge of financial institution

13 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 processes, authorized users pose a potential threat to users must be
systems and data. Employees, contractors, or third-party monitored/audited.
employees can also exploit their legitimate computer access
for malicious or fraudulent reasons. Further, the degree of
internal access granted to some users can increase the
risk of accidental damage or loss of information and
systems.

Ensuring that logs or audit trails, as required, are enabled Ref 1, Page 24,25, Item Flexible auditing
and monitored for the applications 11.c.2,3,5,6,15 framework that
allows for detailed
Before the system is live, there should be clarity on the audit
audit logging of
trails and the specific fields that are required to be
database activity,
captured as part of audit trails and an audit trail or log
including failed
monitoring process including personnel responsible for the
login attempts,
same.
grants of access
All application systems need to have audit trails along with rights, and changes
policy/procedure of log monitoring for such systems in system
including the clear allocation of responsibility in this regard. configuration.
Every application affecting critical/sensitive
information, for example, impacting financial, customer,
control, regulatory and legal aspects, must provide for Detailed
detailed audit trails/ logging capability with details like information in the
transaction id, date, time, originator id, authorizer id, audit trail including
actions undertaken by a given user id, etc. Other details IP address, host
like logging the IP address of the client machine, terminal name, and
identity or location may also be considered. application specific
auditable attributes
Applications must also provide for, inter-alia, logging
to be captured.
unsuccessful logon attempts, access to sensitive options
in the application, e.g., master record changes, granting
of access rights, use of system utilities, changes in
system configuration, etc.
Applications must not allow unauthorized entries to be
updated in the database.

With the advances in information technology, most banks in Ref 1, Page 113, Ability to monitor
India have migrated to core banking platforms and have and audit database
Page 115, Item 2.e
moved transactions to payment cards (debit and credit object changes.
cards) and to electronic channels like ATMs, Internet
Banking and Mobile Banking.

Internet banking systems have security features such as ...

upper limit on transaction value and SMS alerts to
customers...

Information security and appropriate access control

procedures ensure that only employees who are required to
know particular information have access to the same and
can put through transactions. Further, a bank’s systems
need to be adequately secured to ensure that no un-
authorised person carries out any system
modifications/changes.

System triggers that throw up exceptional transactions, Ref 1, Page 116, Item Cyber fraud
….. to report suspicious transactions/behaviours are 2.(iii).a.b detection and alerts
some of the techniques that are used for detection of frauds. on suspicious
The exceptional/suspicious transactions/activities reported transactions.
through these mechanisms should be investigated in detail. Integration of alerts
with SIEM products

14 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 The transaction monitoring team should be responsible for for enabling
monitoring various types of transactions, especially analysis and
monitoring of potential fraud areas, by means of which, notification.
early alarms can be triggered.

Banks should put in place automated systems for

detection of frauds based on advanced statistical
algorithms and fraud detection techniques.

Banks can have dedicated email IDs and phone numbers

for customers to report any fraudulent activity that they
may notice.

Recommendations:

Oracle Database Auditing Controls:

Follow the section Sensitive Data Access to create object action audit policies for sensitive data access and enforce the policy
for application service accounts.

The Unified Audit trail captures many of the required attributes from the client sessions like CLIENT_PROGRAM_NAME and
CLIENT_IDENTIFIER. For a complete list of attributes captured in Unified Audit trail, refer to the UNIFIED_AUDIT_TRAIL
view definition in the Oracle Database Reference.

For additional application attributes like transaction id, originator id, authorizer id, location that the RBI Guidelines
require in the audit trail, the Oracle unified_audit_trail allows customization by capturing the additional attributes in the
APPLICATION_CONTEXTS column. Auditing Application context values, as referred in ‘Auditing Application Context
Values’ in the Oracle Database Security Guide, enables the capture of application context values set by the database
applications, while executing the audited statement. For example, the HR module in an application can set the appropriate
application context values so that any SQL operation that is audited while executing within the HR module can now contain
additional information relevant to the execution context.

To set the values for an application context, create a PL/SQL package procedure that uses the
DBMS_SESSION.SET_CONTEXT procedure. This is the only way that one can set application context values if the context is
not marked INITIALIZED EXTERNALLY or INITIALIZED GLOBALLY. One can assign the values to the application context
attributes at run time. Because the trusted procedure, and not the user, assigns the values, it is a secured application
context. A sample procedure, which populates application context with attributes from gv$session and userenv, and the
audit configuration capturing the attributes in audit trail, is shown in Application activity auditing sample.

In this way, one can extend the unified audit trail to capture any additional application attributes. Consider enforcing it for
application service accounts.

RBI also recommends capturing unsuccessful logon attempts from application service accounts. Ensure that the Oracle pre-
defined audit policy ORA_LOGON_FAILURES is enabled in the database to track unsuccessful login attempts.

RBI recommends that for the core Internet banking systems, finer controls like upper limit on transaction value and SMS
alerts to customers be configured. Consider using Fine-grained auditing (FGA) policies as explained in Sensitive Data Access,
which allows configuring audit policies based on values in the database table, in-addition to configuring alerts using event
handler. Additionally, alerting in Audit Vault and Database Firewall product could be leveraged, which allows alerts to be
created and emailed and/or integrated with a SIEM product.

Implementing Continuous Monitoring Controls:

Leverage the following features of Oracle Audit Vault and Database Firewall:

1. Track failed logins from the application using the ‘Failed Login Events’ activity reports as shown in the sample
below. The report shows the USER_LOGIN events where the Event Status is ‘Failure’.

15 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 Failed status of
USER_LOGIN events

2. Create alerts with appropriate threshold and alert conditions such as EVENT_STATUS=FAILURE and
EVENT_NAME=LOGIN. Consider configuring alerts based on time-period and frequency. For example, trigger an
alert when there are three failed login attempts on Oracle Database target within a five-minute period.
3. Create a custom report to monitor activity on sensitive data access by application service accounts. Use ‘Activity on
Sensitive Data’ data privacy report as detailed in the section Establish Proactive Security Monitoring Practices,
including Sensitive Data Access.
4. Consider tracking transaction updates in critical systems such as Internet banking systems using ‘Data Modification
Before-After Values Report’ to understand the before and after values of the update, as shown in the sample below.

Old value of New value of sensitive

sensitive columns columns post Update

1.5. Inactive User Accounts

Inactive user accounts increase the attack surface of the applications and database, and can be used by an attacker as a
means of entry. RBI Guidelines recommend establishing a mechanism to keep track of attempts to access deactivated
accounts if any of the deactivated accounts need to still exit in the system.

RBI Guideline Source Audit Implication

Banks should frequently review all system accounts and Ref 1, Page 32, item Monitor activity on
disable any account that cannot be associated with a 17.(viii),(ix),(xi),(xii),(xiii) dormant account as
business process and business owner. Reports that may be part of security
generated from systems and reviewed frequently may monitoring.
include, among others, a list of locked out accounts,
disabled accounts, accounts with passwords that exceed the
maximum password age, and accounts with passwords that
never expire.

Banks should establish and follow a process for revoking

system access by disabling accounts immediately upon
termination of an employee or contractor.

Banks should monitor account usage to determine

dormant accounts that have not been used for a given
period, say 15 days, notifying the user or user’s manager of

16 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 the dormancy. After a longer period, say 30 days, the
account may be disabled.

On a periodic basis, say monthly or quarterly basis, banks

should require that managers match active employees and
contractors with each account belonging to their managed
staff. Security/system administrators should then disable
accounts that are not assigned to active employees or
contractors.

Banks should monitor attempts to access deactivated

accounts through audit logging.

Implement controls to minimize invalid logon counts, Ref 2, Page 11, item 8.6 Track dormant
deactivate dormant accounts. accounts.

Recommendations:

Oracle Database Auditing Controls:

Consider creating user profile with ‘inactive_account_time’ and ‘password_life_time’ and associate it with user accounts.
Create an audit policy to track all top-level actions on these inactive locked user accounts if any of these accounts need to
still exit in the system. Use a cron job to schedule a periodic audit configuration for newer locked user accounts in the
system and create new audit policies for these accounts.

Ensure pre-defined audit policy ORA_SECURECONFIG is enabled in the system. This captures executions of ‘ALTER
PROFILE’ audit events if there is any un-authorized attempts to modify the user profile settings.

Implementing Continuous Monitoring Control:

To monitor usage of dormant accounts, leverage the ‘Dormant User activity’ report in Oracle Audit Vault and Database
Firewall as detailed in the section Establish Proactive Security Monitoring Practices, including Sensitive Data Access.

1.6. Specific Components

RBI Guidelines recommend auditing specific components as highlighted here.

RBI Guideline Source Audit Implication

Data transfer from one process to another or from one application Ref 1, Page 26, Audit of data transfer
to another, particularly for critical systems…. The process needs to item 11.27 process in
be automated and properly integrated with due authentication applications.
mechanism and audit trails…

Audit trails need to be available to document the conversion, Ref 1, Page 27, Audit of data
including data mappings and transformations…Integrity of data.. item 12.(i)(ii) migration activity.
Completeness.. Confidentiality of data.. Consistency of data..

Logging the auditing of key management-related activities Ref 1, Page 29, Audit of key
item 14.(iii).g management tasks.

17 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
Recommendations:
Data transfer process or data migration activity involving Oracle Data Pump can be audited. Consider auditing Data Pump
export (expdp) and import (impdp) operations. Refer to ‘Auditing Oracle Data Pump Events’ in the Oracle Database
Security Guide for configuration details.

Data transfers/ transformations involving RMAN backup/ restore operations gets audited by default in the Oracle Database
using mandatory auditing capabilities.

For auditing key management-related activities, ensure the Oracle pre-defined audit policy ORA_SECURECONFIG is enabled
in the database. This policy monitors usage of ADMINISTER KEY MANAGEMENT privilege, which is used to manage
keystores, encryption keys and secrets. Consider auditing for 'ACTIONS ADMINISTER KEY MANAGEMENT' to capture the
audit record for every key management related activity (irrespective of usage ADMINISTER KEY MANAGEMENT privilege).

2. RBI GUIDELINES FOR ENSURING AUDIT INTEGRITY

RBI guidelines recommend audit trails be secure to ensure the integrity of the information, since that is the authoritative
source of information for forensic analysis. Here are some key references.

RBI Guideline Source Audit Implication

The audit trails need to be stored as per a defined period as per any Ref 1, Page 25, Application audit
internal/regulatory/statutory requirements and it should be ensured item 11.c.7 data integrity.
that they are not tampered with.

The integrity of the monitoring logs and processes should be Ref 1, Page 32, Maintaining integrity
safeguarded through appropriate access controls and segregation of item 17.vii of logs.
duties.

Digital evidence is similar to any other form of legal proof - it needs Ref 1, Page 16, Digital evidence as
to withstand challenges to its integrity,.. item 1.5 legal proof.

Banks needs to ensure that audit trails exist for IT assets satisfying Ref 1, Page 36, Audit trails need to
the banks business requirements including regulatory and legal item 21.i,ii be secure to protect
requirements, facilitating audit, serving as forensic evidence when the integrity of the
required and assisting in dispute resolution. This could include, as audit data.
applicable, various areas like transaction with financial
consequences, …., modifications in sensitive master data, accessing
or copying of sensitive data/information; and granting, modification Ability to define
or revocation of systems access rights or privileges for accessing policy for retention of
sensitive IT assets. audit data.
Audit trails should be secured to ensure the integrity of the
information captured, including the preservation of evidence.
Retention of audit trails should be in line with business, regulatory
and legal requirements.

E-banking systems should be designed and installed to capture and Ref 1, Page 36, Audit records must
maintain forensic evidence in a manner that maintains control item 21.vii be secure from
over the evidence, and prevents tampering and the collection of alteration or
false evidence. destruction.

Ensuring that privileged users do not have access to systems logs in Ref 1, Page 21, Block privileged user
which their activities are being captured item 5.(xiii).f access to audit logs
to ensure they do not
tamper it.

18 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 Before the system is live, there should be clarity on the audit trails Ref 1, Page 24, Ensure there is
and the specific fields that are required to be captured as part of item 11.c.3 agreement on what
audit trails and an audit trail or log monitoring process including audit data should be
personnel responsible for the same. captured and how
that audit data
should be
maintained.

Recommendations:
Oracle Database auditing stores audit records in a secure schema within the audited database. Oracle Audit Vault and
Database Firewall extends this protection by moving the audit data into a separate secure repository that is protected from
access by database administrators.
Unified Auditing in Oracle Database is inherently secure at source. Unified Audit records are written to
AUDSYS.AUD$UNIFIED, which is a read-only table. Hence, DMLs are not permitted on the unified audit trail views. Even DML
and DDL operations on the underlying dictionary tables from AUDSYS schema are not permitted. Any attempt to directly
delete or update contents of AUD$UNIFIED fails as shown in the below figure, and generates an audit record.

Attempts to modify the data or metadata of the unified audit internal table are mandatorily audited. Because these attempts
should be considered inherently suspicious, consider creating alerts for them in AVDF.

Audit data can only be managed using the built-in audit data management package “DBMS_AUDIT_MGMT”. Audit data
cannot be directly updated or removed using UPDATE or DELETE SQL commands. Oracle Database mandatorily audits all
executions of the DBMS_AUDIT_MGMT PL/SQL package procedures.

Oracle Database facilitates separation of duties by providing two separate audit-related roles: AUDIT_ADMIN and
AUDIT_VIEWER.

AUDIT_ADMIN can configure auditing both unified audit policies and fine-grained audit policies and do administrative tasks
pertaining to auditing, such as purging the audit trail. This role also contains the ability to view and analyze audit data.
Typically, this role is granted to security administrators.

AUDIT_VIEWER can view and analyze audit data only and not create audit policies or truncate the audit trail. Typically, this
role is granted to auditors or security analysts.
The AUDSYS schema user, where Unified Audit trail resides cannot be logged into, as shown below. Thus, Oracle Database
auditing stores audit records in a schema that is protected from update and delete operations, only allowing purging of the
audit trail using the AUDIT_ADMIN role.

To ensure further integrity of audit data, key fields of unified audit records can be written to SYSLOG utility (on UNIX
platforms) or to the Windows Event Viewer (on Windows) by enabling the UNIFIED_AUDIT_SYSTEMLOG parameter. The
fields in SYSLOG uniquely identify the detailed unified audit records in the UNIFIED_AUDIT_TRAIL view.

19 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
Consider encrypting audit data tablespaces with Transparent Data Encryption (TDE). Consider protecting the Unified Audit
table with a Database Vault realm. It is a good practice to create a Database Vault realm around AUDSYS.AUD$UNIFIED table
so that only authorized administrators can access the Unified Audit trail and even users with SYSDBA privileges cannot
access unless they are part of realm authorization list.

As a best practice recommendation, forward the audit data from its source to a remote centralized location where the
individuals whose activities are audited, cannot purge the data. By removing audit data from the source Oracle Database
and storing it in the secured remote location like Oracle Audit Vault and Database Firewall (AVDF) appliance, we can protect
the integrity and reliability of the audit data and prove that it has not been tampered with.

AVDF is a secure data warehouse of audit data, with a highly scalable and secure repository that stores the audit data.
Timely transfer of audit data from source audit trails to Audit Vault server is critical to close the window on intruders who
may attempt to modify audit data and cover their tracks. Audit Vault transfers audit data on a near real time basis using the
Audit Vault Agent. Audit Vault encrypts data during transmission using industry standard TLS. Audit Vault protects audit
data using Oracle’s industry leading database security technology. The repository is an embedded Oracle Enterprise Edition
Database that includes numerous Oracle technologies, including automatic storage management (ASM), compression,
partitioning, encryption, Database Vault, and privileged user controls.

Audit Logs
User Login Oracle Database Audit Data Collection
Audit Trail
Secured At-Source
Oracle Audit Vault and
Database Firewall

Secured Remotely

AVDF uses a data warehouse schema called AVSYS. Audit data and network-based database activity event data is stored in
the AVSYS.EVENT_LOG table. The AVSYS account is locked in the Audit Vault database. The Audit Vault database uses
Oracle Database Vault to protect the AVSYS schema, and hence the Database Vault account manager can only unlock it. In
order to do so you have to login to the Audit Vault server using root password (this is set during the AVDF installation) and
then switch user to the Database Vault account manager. Thus, multiple layers of access control makes the access to the
AVSYS schema very restricted.

The AVSPACE tablespace containing the AVSYS schema in the Audit Vault server's repository is automatically encrypted
using Transparent Data Encryption (TDE). Hence, even archived event data is encrypted. AVDF protects audit trails with a
combination of encryption and strong access controls.

To enhance the integrity of audit and network data stored in AVDF, adhere to the guidelines outlined in ‘General Security
Guidelines’ of the Audit Vault and Database Firewall Administrator's Guide.
Retention of audit trails can be configured per-database target to allow for varying business requirements. For critical
systems like E-banking or core banking systems, the retention period for online and archived data can be defined to be
much longer than non-critical systems. Refer to ‘About Archiving and Retrieving Data in Oracle Audit Vault and
Database Firewall’ in the Audit Vault and Database Firewall Administrator's Guide for details on configuration.

20 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 3. RBI GUIDELINES FOR CONTINUOUS SURVEILLANCE

Providing a centralized monitoring and management console for accelerating analysis, incident response, reporting, forensic
investigation, and for demonstrating regulatory compliance is a vital component of a Database Activity Monitoring solution.
RBI Guidelines recommend continuous surveillance and proactive security monitoring practices to detect unusual activity
patterns in the database and over the network, and establish escalation and communication processes to contain security
incidents.

RBI Guidelines that recommend centralized auditing, monitoring, reporting, and alerting of anomalous activity on the
database are listed here, followed by recommendations on how Oracle Audit Vault and Database Firewall(AVDF) can be used
to meet these requirements.

RBI Guideline Source Monitoring and Alerting

Implication

Developing and implementing processes for preventing, Ref 1, Page 23, Audit data must be
detecting, analyzing and responding to information security item collected and preserved to
incidents 10.(ii).a.b.d.e, support forensic
investigation.
Establishing escalation and communication processes and lines Item 10.(iii),
of authority item 10.(iv)

Establishing the capability to investigate information security Ability to send out alerts
incidents through various modes like forensics, evidence and report on issues.
collection and preservation, log analysis, interviewing, etc.

Developing a process to communicate with internal parties and

external organizations (e.g., regulator, media, law enforcement,
customers

Common incident types include, but not limited to, ….,

unauthorised access to systems, identity theft, data leakage/loss,
malicious software and hardware, failed backup processes, denial
of service attacks and data integrity issues.
A bank needs to have clear accountability and communication
strategies to limit the impact of information security
incidents through defined mechanisms for escalation and
reporting ..

Potential security weaknesses / breaches (for example, as a Ref 1, Page 25, Support identification of
result of analyzing user behaviour or patterns of network traffic) item 11.c.13 potential breaches,
should be identified. including unusual patterns
of access to the database.

Concerns over the need to better control and protect sensitive Ref 1, Page 30, Monitoring access to
information have given rise to a new set of solutions aimed at item 15.xi sensitive information.
increasing an enterprise’s ability to protect its information assets.
… data leak prevention (DLP). It provides a comprehensive
approach covering people, processes, and systems that identify, Audit policies relating to
monitor, and protect data in use (e.g., endpoint actions), data sensitive data needs to be
in motion (e.g., network actions), and data at rest (e.g., data created.
storage) through deep content inspection and with a
centralized management framework. Most DLP solutions
include a suite of technologies that facilitate three key objectives:
• Locate and catalogue sensitive information stored
throughout the enterprise

21 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 • Monitor and control the movement of sensitive
information across enterprise networks

• Monitor and control the movement of sensitive

information on end-user systems

Robust monitoring processes in place to identify events and Ref 1, Page 31, Ability to identify unusual
unusual activity patterns. The strength of the monitoring item activity patterns, and
controls needs to be proportionate to the criticality of an IT asset. 17.(i),(ii),(xv) generate alerts.
Alerts would need to be investigated in a timely manner.

Common monitoring processes include activity logging

Need to track access to
(including exceptions to approved activity), for example, device,
sensitive data.
server, network activity, security sensor alerts; monitoring staff
or third-party access to sensitive data/information…

System administrators and information security personnel should

consider devising profiles of common events from given
systems, so that they can tune detection to focus on unusual
activity, reducing false positives, more rapidly identify
anomalies, and prevent overwhelming the analysts with
insignificant alerts.

Banks needs to ensure that audit trails exist for IT assets Ref 1, Page 36, Database activity
satisfying the banks business requirements including regulatory item 21.(i),(iv) monitoring and auditing,
and legal requirements, facilitating audit, serving as forensic along with the ability to
evidence when required and assisting in dispute resolution. monitor SQL traffic and
store in a central place is
Network and host activities typically are recorded on the host
needed.
and sent across the network to a central logging facility which
may process the logging data into a common format. The The solution should
process, called normalization, enables timely and effective log support heterogeneous
analysis. databases, and support
reporting and alerting.

• All remote access to an internal network, … Ref 1, Page 36, Ability to identify users
item 21.(v) accessing the database
• Operating systems should be configured to log access
remotely, and identify
control events … without the appropriate permissions
anomalies in access
• identify anomalies in logs and actively review the anomalies, patterns and alert on
events. In addition, audit
• Network boundary devices, including firewalls, network-
logs from OS should also
based IPSs, and inbound and outbound proxies may be
be captured.
configured to log verbosely all traffic (both allowed and
blocked) arriving at the device

Given the multiplicity of devices and systems, banks should Ref 1, Page 37, Ability to forward alerts to
consider deploying a Security Information and Event item 21.(vi) the SIEM for aggregation
Management (SIEM) system tool for log aggregation and and correlation.
consolidation from multiple machines/systems and for log
correlation and analysis..

Security monitoring arrangements should provide key decision- Ref 1, Page Ability to monitor SQL
makers … with an informed view of aspects like the 37/38, item traffic and log it, along with
effectiveness and efficiency of information security 22.(i),(iii),(iv),(v), database activity in a
arrangements.. (vi),(vii) centralized way giving key
decision makers a
Analysis performed as part of security monitoring and reporting
dashboard view is
arrangement may include
important. Ability to

22 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 …Details relating to information security incidents and their support ad-hoc analysis
impact… and reporting is required.
Operational security statistics, such as firewall log data…..

Information collected as part of security reporting arrangements

should include details about all aspects of information risk like
criticality of information, identified vulnerabilities and level of
threats, potential business impacts and the status of security
controls in place.

Metrics can be an effective tool for security managers to

discern the effectiveness of various components of their
security policy and programs…

The use of metrics needs to be targeted towards the areas of

greatest criticality.
A comprehensive set of metrics that provide for prospective and
retrospective measures, like key performance indicators and
key risk indicators, can be devised.

The first step in an investigation process is gathering the entire Ref 1, Page 117, Fraud investigation
transaction details, documents and complete details of the item 2.(iii).a requires analyzing large
customer/employee or vendor. In order to investigate into volumes of data with
suspected cases, the group would adopt various advanced ability to store and archive
techniques including computer forensics, forensic accounting and data, so that historical data
tools to analyse large volumes of data. can also be considered as
part of the forensic
analysis.

Put in place mechanism to detect and remedy any unusual Ref 2, Page 9, Database Activity
activities in systems, servers, network devices and endpoints. item 4.7 Monitoring to detect
unusual activity within
your databases and send
alerts to SIEM so that
notifications can be sent to
administrators for taking
remedial actions.

Manage and analyse audit logs in a systematic manner so as to Ref 2, Page 14, Manage audit logs from
detect, understand or recover from an attack. item 16.2 multiple sources
(databases, operating
systems, firewall traffic),
and store and analyze
them to detect and
understand an attack.

Implement and periodically validate settings for capturing of Ref 2, Page 14, Database auditing should
appropriate logs/audit trails of each device, system software and item 17.1 contain the necessary
application software, ensuring that logs include minimum information to uniquely
information to uniquely identify the log for example by including identify the source of
a date, timestamp, source addresses, destination addresses. activity and detect any
audit setting changes.

Arrangement for continuous surveillance - Setting up of Cyber Ref 4, Page 9, Database auditing and
Security Operation Centre (C-SOC): item 1.1 network-based activity
monitoring are a key part
• Ability to Provide real-time/near-real time
of continuous surveillance,
information on and insight into the security posture of
preserving evidence of
the UCB
who did what, when they

23 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 • Ability to know who did what, when, how and did it, and where they did
preservation of evidence it.

• Integration of various log types and logging options

into a Security Information and Event Management
(SIEM) system,…
• Able to monitor the logs of various network activities
and should have the capability to escalate any abnormal
/ undesirable activities.
• Key Responsibilities of C-SOC could include:

o Monitor, analyse and escalate security

incidents

o Develop Response - protect, detect, respond,

recover

o Conduct Incident Management and Forensic

Analysis

Ensure proactive monitoring capabilities aligned with the banking Ref 4, Page 9, Ability to quickly collect
technology risk profile item 1.2 various audit logs centrally
for processing, making it
Security analytics engine which can process the logs within
available for analysis and
reasonable time frame and come out with possible
alerting. Additionally, there
recommendations
is a need to process and
Deep packet inspection approaches analyze SQL traffic.

Develop a comprehensive set of metrics that provides for Ref 4, Page 10, Support forensic
prospective and retrospective measures, like key performance item 4.1,item investigation, including
indicators and key risk indicators…. 4.2 correlation of activity
across different databases.
Have support/ arrangement for network forensics/forensic
investigation….

Recommendations:

Oracle Audit Vault and Database Firewall (AVDF) provides a comprehensive Database Activity Monitoring solution by
collecting and consolidating audit data, monitoring and logging network traffic, policy management, raising alerts, and
providing detailed reports for forensic and compliance purposes. Salient features of Oracle Audit Vault and Database
Firewall include:

a) Audit Data Collection from databases and policy provisioning

• Collection and consolidation of audit data from Oracle and non-Oracle databases
• Audit data collection from operating systems, file systems, and directory services

• Display and provisioning of Oracle Database audit policies

• Monitoring user entitlement changes and stored procedure changes for Oracle Database
b) SQL traffic monitoring and analysis

• Monitoring SQL traffic over the network using Database Firewall

• Securing targets from SQL Injection attacks
• Selectively allowing or blocking SQL traffic based on whitelists or blacklists
c) Sensitive data activity tracking within the database and validating SQL statements before they reach the database

d) Powerful, customizable alerts

24 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 • Alerting and Notifications based on audit data collected

• Ability to customize and create powerful alerts based on frequency of actions, and composite conditions
based on the audit data collected
e) Reporting
• Reporting for forensics and compliance tracking

• Ability to customize and run ad-hoc reports

• Scheduling of reports with email based notification
f) Audit data archiving

g) Integration with SIEM products

h) High availability and reliability, supporting the needs of large enterprises for continuous monitoring and auditing

Best practice recommendations to build an effective continuous surveillance solution, to help comply with RBI Guidelines,
fall in the following categories:

3.1. Configure Integrated Security Monitoring

3.2. Create Selective and Focused Audit, Firewall and Alert Policies
3.3. Define Alerts that are Actionable and Granular
3.4. Establish Proactive Security Monitoring Practices, including Sensitive Data Access
Subsequent sections highlights the recommendations:

3.1. Configure Integrated Security Monitoring

RBI Guidelines lay equal emphasis on database auditing as well as tracking suspicious behavior of users over the network. It
is therefore necessary to configure both database audit collection and network monitoring, which can be done using Oracle
Database auditing along with AVDF to provide a comprehensive solution, which covers both Oracle and non-Oracle
databases, operating systems and directory audit logs. The table shows how database auditing and network monitoring
complement each other and are therefore mandatory in establishing an effective security monitoring solution.

Database Auditing Network Monitoring

Purpose Support regulatory compliance and Identify SQL-injection attempts and

audit privileged user activities, other unauthorized activity, enforce
providing guaranteed audit trail to corporate data security policy
enable control

Information Captured Who, what, where, when Who, what, where, when
Before/After values

Full execution and application

context

Pathways Monitored All: stored procedures, direct Network

connections, scheduled jobs,
operational activities

Impact on database Requires native database auditing, Completely independent of

performance impact determined by database resources, negligible
the amount of audit data being performance impact
produced

25 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
Steps for configuring and implementing Database Audit collection and Network monitoring:
a) Identify the targets to monitor

• Audit trails supports audit data collection from a broad spectrum of targets, including

• Database audit trails from Oracle Database, Microsoft SQL Server, MySQL, SAP Sybase
and IBM DB2 for LUW. The audit data can be collected from audit tables or files.

• Before/After values from REDO records of Oracle databases.

• OS audit trails from Oracle Linux, Oracle Solaris, Microsoft Windows, and IBM AIX.

• Microsoft Active Directory audit trails.

• File systems such as Oracle ACFS.

• Custom audit data in either database tables or XML files. Audit data for custom
applications can be collected and reported.

• Refer to ‘Supported Secured Targets’ in the Audit Vault and Database Firewall
Installation Guide for the list of targets and their versions supported.

• Network trails support a broad set of database targets

• By configuring the database firewall in proxy mode, network traffic to/from Oracle
Database, Microsoft SQL Server, SAP Sybase, IBM DB2, and MySQL can be monitored
and blocked if needed. Refer to ‘Database Firewall Protection: Supported Secured
Target Types and Versions’ in the Audit Vault and Database Firewall Installation
Guide for the list of targets and their versions supported.

• Host monitor, which captures SQL traffic from the network card and sends it over the
network to a Database Firewall, can also be used for monitoring SQL traffic, but this
cannot be used for blocking. The platforms where host monitor is supported, is listed in
‘Host Monitor: Supported Platforms and Versions’.
b) Configure data retention policies for each target based on data sensitivity and corporate retention rules

• Retention policies determine how long data is retained in the Audit Vault Server and can be used
for reporting, after what time period should the data be archived, and for how long archived data
can be brought back into the Audit Vault Server for reporting and forensics. Retention policies
may be different for different databases monitored by the same Audit Vault and Database
Firewall.

• Refer to ‘About Archiving And Retrieving Data In Oracle Audit Vault And Database
Firewall’ in the Audit Vault and Database Firewall Administrator’s Guide for
configuration details.
c) Enforce segregation of duties

• AVDF supports two types of users: Auditors and Administrators.

• Auditors can configure and provision audit policies and firewall monitoring policies for databases,
as well as define, generate, and access audit reports and alerts.

• Administrators can configure basic network and host settings for the targets, start and stop Audit
Vault Agents and Database Firewalls, and configure and monitor Audit Vault Server operation.
Administrators do not have access to audit information and cannot create audit policies /firewall
monitoring policies.

• A single user can have only the auditor or administrator role.

• Within the two role categories, further separation of duties can be defined. A subset of database
targets can be assigned to individual auditors and administrators, ensuring that segregation of
duties is possible not only by role, but by the targets that they are allowed access to.

• Refer to ‘Managing User Accounts and Access’ in the Audit Vault and Database Firewall
Administrator’s Guide for configuration details.

26 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 3.2. Create Selective and Focused Audit, Firewall and Alert Policies
Be selective on what you want to audit in the database or log based on the network traffic and create alerts only on the
events of interest. Fine-tuning the policies and creating targeted alerts reduces false positives (alerts where no attack exists)
and false negatives (no alert when an attack does take place). While false negatives are obviously a concern, false positives
can also hinder detection. When security personnel are overwhelmed with the number of alerts which are false positives,
their review of alerts may be less effective thereby allowing real attacks to be reported but not suitably acted upon. RBI
emphasizes the need to ensure the detection capability is adequate and effective. Three categories of policies that needs to
be fine-tuned are:
a) Audit policies

Follow the recommendations highlighted in RBI Guidelines for Database Auditing to make the audit policy
configuration granular and conditional.
b) Firewall policies
Follow the recommendations highlighted in Firewall Policy to make the Firewall policy configuration selective.

c) Alert policies

Follow the recommendations highlighted in Define Alerts that are Actionable and Granular to ensure alerts are
specific to the conditions of interest and are targeted.

3.3. Define Alerts that are Actionable and Granular

RBI recommends establishing escalation and communication processes in the event a security incident has occurred. Alerts
are a useful mechanism for defining events of interest.

AVDF provides the ability to detect and alert on activities that may indicate attempts to gain unauthorized access to systems
and/or abuse system privileges. It lets you define rule-based alerts on audit records, whether these records come from the
native database audit trail, or are collected from the network by the Database Firewall. Database Firewall policies can be
configured to generate alerts on network activity, providing an early-warning detective control for potential malicious
activity. AVDF continuously monitors the events collected, evaluating the activities against defined alert conditions and
generating an alert if the condition is met. Alerts can be associated with any database event including system events such as
changes to application tables, creating privileged users, or events when someone attempts to access to sensitive business
information. Any actions that are blocked by an Oracle Database Vault policy also generate an audit event on top of which
an alert can be created.
Alert management capability in AVDF can be used to create alert definitions that raise alerts on the auditor’s dashboard and
send notifications to users for investigation. Alerts can be defined specifying a Boolean condition using SQL comparison
operators (=, <, LIKE, IN, NULL, and so on) and logical operations (NOT, AND, OR) using the fields in the audit record, as
shown in the screenshot below. Refer to ‘Creating Alerts’ in the Audit Vault and Database Firewall Auditor’s Guide for
details on alert configuration.

Flexibility to create
conditional alerts

Additionally, the AVDF dashboard provides graphical summaries of alerts as shown below. These include a summary of alert
activity. Consider using the alert trend in the auditor’s dashboard for analyzing the risk trends over time.

27 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
For reporting, alerts can be grouped by source, event category, and severity (warning or critical) as shown below so the
security personnel can focus on high priority alerts first.

Consider configuring notifications for the generated alerts. For example, you can set up an email to be automatically sent to
a user, such as a security officer, or to a distribution list. Alerts can also be forwarded to syslog. This is useful if you want to
integrate AVDF with another system like the enterprise SIEM. Refer to ‘Responding to an Alert’ in the Audit Vault and
Database Firewall Auditor’s guide for information on configuring notifications.

3.4. Establish Proactive Security Monitoring Practices, including Sensitive Data Access
RBI recommends banks have continuous surveillance and robust monitoring processes in place to identify suspicious events
and unusual activity patterns. Use AVDF reports to establish continuous monitoring practices in your environment.

AVDF reports can be used to monitor a wide range of activities including privileged user activity on the database server,
changes to database structures, and SQL statements on the network that are executed on the database server. Reports are
based on the consolidated audit information from databases, operating systems, and directories, providing a holistic view of
activities across the enterprise. In addition, reports can include information on database account management, roles and
privileges, object management, and stored procedure changes.

Auditors can access reports interactively through a web interface, or generate PDF or XLS reports. The console’s easy-to-use
interactive browsing provides the ability to create color-coded charts and graphs. Columns of interest within the report can
be sorted, filtered, re-ordered, added, or removed. Rules can automatically highlight specific rows so that users can quickly
spot suspicious or unauthorized activity. PDF and XLS report definitions can be used to schedule automatic generation of
reports, which can be delivered via e-mail attachments or URLs. Reports can also be defined to require attestation by
auditors. Users can easily create new or customize PDF and XLS report templates to meet specific compliance and security
requirements.

Audit Vault Server provides optimal performance by expediting report generation with the help of Oracle Database In-
Memory feature, using which audit data can be stored in memory based on the selected date range, enabling reports to run
faster. Furthermore, the Audit Vault Server repository schema is documented and accessible, enabling integration with
third-party reporting solutions.

28 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
Various categories of built-in reports are available, including:
a) Activity Reports

b) Summary Reports
c) Compliance Reports

a) Activity Reports:
Activity reports as shown below track database access activities such as audited SQL statements, application access
activities, and user logins. Specialized activity reports also cover failed logins, user entitlements, before-after data
modifications, changes to application tables, and database schema changes.

Entitlement reports as shown below describe the types of access that users have to an Oracle Database, providing
information about the users, roles, profiles, and privileges used. These reports are useful for tracking unnecessary access to
data, finding duplicate privileges, and simplifying privilege grants. An entitlement snapshot captures the state of user
entitlement information at a specific point in time. The snapshot contains the metadata of users and roles that a user has to
the Oracle Database: system and other SQL privileges, object privileges, role privileges, and user profiles. An entitlement
report job can be scheduled such that it periodically takes a snapshot of the user entitlements at specified intervals. After an
entitlement snapshot is generated, you can compare different snapshots to find how the entitlement information has
changed over time.

29 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
Stored Procedure Audit reports helps track changes made to the stored procedures. There are common attack patterns that
replace a stored procedure with a procedure containing malicious code. Stored procedure auditing is an essential part of
protecting your database against attack.

Correlation Reports helps correlate events on the database with the Linux OS user for Oracle Database targets running on
Linux. This is useful in cases where this OS user runs a shell or executes a command on the database as another user by
using su or sudo.

Database Firewall reports provide detailed event information on the SQL traffic to the monitored databases. For example,
details of SQL statements that had alerts enabled or were blocked can be seen. General information about SQL traffic to the
databases can be seen, including statement type (DDL, DML, etc.), database username, OS username, client application
name, client IP address, and Database Firewall action and threat level.

These Database Firewall reports as shown below, along with the other built-in audit reports provide a complete
understanding of the security and compliance status of the database environment.

A sample Database Firewall report, giving detailed information on the SQL traffic that is blocked by firewall policy rule is
shown below.

SQL traffic that is

blocked by firewall
policy

b) Summary Reports:
These set of reports contain trend charts, anomaly reports and various summaries by target (DDL summary, activity
summary, failed login summary) as shown below. These reports can be used to quickly review characteristics of user activity
on specific targets or across the enterprise. These reports can be used to identify anomalies such as new and dormant user
and client IP anomalies over time. Activities by new users, or previously dormant users, can be analyzed for potential
account hijacking.

30 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
The report below shows a “Dormant User activity” report where there was a recent activity by a Linux user account that was
dormant since July 31, 2019.

There has been flurry of activity in the last 5 days by user

‘sourbasu’ who has been otherwise dormant since 31/7/2019

c) Compliance Reports:
Standard out-of-the-box audit assessment reports are available and help to meet regulations such as:
• Data Privacy Reports (GDPR)
• Payment Card Industry Data Security Standard (PCI-DSS)
• Sarbanes-Oxley Act (SOX)

• Health Insurance Portability and Accountability Act (HIPAA)

• Gramm-Leach-Bliley Act (GLBA)
• Data Protection Act (DPA)

• IRS Publication 1075

One of the out-of-the-box compliance reports is the Data Privacy Report (GDPR) as listed above. Oracle Audit Vault complies
with data protection directives and regulations by offering capabilities like centralized auditing, monitoring, reporting, and
alerting of anomalous activity on the database. It also reports on the sensitive data in the database targets as well as any
access to sensitive data by all users including privileged users.

RBI Guidelines strongly recommend locating and cataloging sensitive information. RBI Guidelines also recommend closely
monitoring and controlling the movement of sensitive information across enterprise networks and on database systems.

AVDF allows importing information on sensitive data into its repository, thereby helping track activities on sensitive data
using the Data Privacy Reports. Refer to ‘Importing Sensitive Data Into Repository’ in the Audit Vault and Database
Firewall Auditor’s Guide for importing sensitive data discovery results from DBSAT /Oracle Enterprise Manager into AVDF.

31 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
Once the information on sensitive data has been imported, Data Privacy Reports, as shown below can be used to closely
monitor access to sensitive data:

A sample report showing sensitive data discovered in a specific target is shown below.

Sensitive data in
pdb1 database target

A sample report showing activity on sensitive data is shown below.

SQL traffic details on
sensitive data access
captured in the report

Through these Data Privacy reports, AVDF can closely monitor the movement and access of sensitive information in the
database and over the network. Enforcing controls on the access and movement of sensitive data over network can be
configured using Database Firewall in proxy deployment as detailed in Increase scrutiny of sensitive data access over
network.

Refer to ‘Reports’ in the Audit Vault and Database Firewall Auditor’s guide for in-depth details on the reports that are
available in AVDF to closely monitor and track activities.

32 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 4. RBI GUIDELINES FOR MONITORING NETWORK TRAFFIC

Network traffic monitoring is an important component of Database Activity Monitoring. With near-zero overhead on the
monitored databases, network-based Database Activity Monitoring requires no modification to the databases, and can
monitor multiple heterogeneous database systems simultaneously. Network-based Database Activity Monitoring should be
used in conjunction with database auditing so that not only local activity on the database can be captured, but also any
database activity that doesn't cross the network as SQL, such as logging local or remote console connections, to make
database and user changes. An effective Database Activity Monitoring solution needs to combine native database auditing
with network-based monitoring for detecting intrusions.

One can classify the RBI Guidelines for network traffic monitoring into following three categories:
4.1. Network Segmentation
4.2. Deployment Topology
4.3. Firewall Policy

In this section, we will examine how the Database Firewall component of AVDF can help address the requirements outlined
in the RBI Guidelines.

4.1. Network Segmentation

RBI Guidelines recommend multiple layers of defense, known as defense in depth and highlights that at the minimum,
banks should consider protecting the perimeter and computing environment. It emphasizes that effective security
deployment requires carefully configured boundary defenses that separate networks with different threat levels, different
sets of users, and different levels of control. Effective multi-layered defense of perimeter networks help to lower the number
of successful attacks, allowing security personnel to focus on attackers who have devised methods to bypass boundary
restrictions. The following references in the RBI Guidelines highlight the importance of segmenting networks and building
boundary defenses.

RBI Guideline Source Network Monitoring

Implication

Defense in depth for most organizations should at least consider the Ref 1, Page 39, Ability to support
following two areas: item 24.iv network traffic
monitoring of
(a) Protecting the enclave boundaries or perimeter
databases, which are in
(b) Protecting the computing environment. distinct enclave
boundaries.
An effective approach to securing a large network involves dividing
the network into logical security domains. A logical security domain
is a distinct part of a network with security policies that differ from
other domains and perimeter controls enforcing access at a network
level.

Network configuration considerations could include Ref 1, Page 39, Ability to enforce
item 24.v different policy rules
o Identifying the various applications and systems
(including blocking/
accessed via the network…
monitoring levels) for
o Determining the most appropriate network less trusted domains.
configuration to ensure adequate security and
performance for the bank..

o Minimizing access to less-trusted domains and

employing encryption and other controls for less secure
connections

33 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 Some applications and business processes may require complete
segregation from the corporate network, for example, preventing
connectivity between corporate network and wire transfer system.

Critical infrastructure of UCB (viz., NEFT, RTGS, SWIFT, CBS, ATM Ref 3, Page2, Ability to support
infrastructure) should be designed with adequate network separation Item 4.4 network separation by
controls providing a monitored
ingress point for
database traffic.

Recommendation:
If databases are located on different subnets (logical security domains), Database Firewall can use different network
interface into each of them for outbound connections from Database Firewall.

In proxy deployment mode, ensure that all database clients connect to the Database Firewall, which in turn connects to the
database servers in different logical security domains using the corresponding network interfaces. Proxy mode of
deployment supports blocking of SQL traffic in-addition to monitoring and is ideal for enforcing strict access control for
less-trusted domains. In the diagram below, databases are segmented into two logical security domains, Database Network 1
and Database Network 2.

A SQL statement between the client application and database server goes through the following steps.
A: The clients connect to the Database Firewall Traffic Proxy through the Network Router.

B: The extracted SQL data from the client traffic is analyzed and sent to the Audit Vault Server based on the Database
Firewall policy.

C: The traffic is forwarded to the target database in logical security domain1 by the Database Firewall over proxy source,
which represents the network interface for domain1.

D: The traffic is forwarded to the target database in logical security domain2 by the Database Firewall over proxy source,
which represents the network interface for domain2.

34 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
The response from the database is returned to the Database Firewall, and then through the Network Router to the client.
The management network is separate from database networks.

The firewall can be configured to run in proxy mode (where the client traffic goes through the firewall), or in out-of-band
mode or in host-monitor mode. In out-of-band/ host-monitor deployment mode, the Database Firewall receives a copy of
the database traffic for monitoring and is not in-line with the traffic from the clients. Hence, in this configuration the
database firewall can only be used for monitoring and not blocking. As part of the configuration, ensure that the host-
monitor deployed within the logical security domains is able to forward the traffic to the Database Firewall and connect to
the Audit Vault server. Consider out-of-band /host-monitor deployment mode when you want to monitor the traffic, and
there are other network perimeter controls to ensure stricter access (such as blocking) to the less-trusted domains.

For database systems requiring complete segregation from the rest of the corporate network due to the sensitivity of data,
consider having a dedicated Database Firewall appliance instance for the specific security domain.

4.2. Deployment Topology

RBI Guidelines specify the firewall types to choose from, and recommend selecting a firewall type based on characteristics of
the security zone, such as the amount of traffic, the sensitivity of the systems and data, and applications, as stated in
references below:

RBI Guideline Source Database Firewall

Implication

Financial institutions have four primary firewall types from which to Ref 1, Page 40, To be able to classify
choose: packet filtering, stateful inspection, proxy servers, and item 24.vii.a the firewall as one of
application-level firewalls. Any product may have characteristics of the RBI recommended
one or more firewall types. The selection of a firewall type is firewall types.
dependent on many characteristics of the security zone, such as the
amount of traffic, the sensitivity of the systems and data, and
applications.

o Packet Filter Firewalls ….

o Stateful Inspection Firewalls….
o Proxy Server Firewalls ….
o Application-Level Firewalls….

Recommendation:

There are three deployment modes for Database Firewall. The capabilities of the firewall, and characteristics of its
implementation, are dependent on the deployment mode.

a) Proxy: One can configure Database Firewall in proxy mode such that all traffic to the database server is routed
through the Database firewall. The proxy mode of deployment supports both active and passive monitoring of
database activity. In this deployment mode, the Database Firewall can monitor and alert on SQL traffic, and can
block or substitute SQL statements as specified in the policy.

b) Out-of-Band: In this mode of monitoring, the Database Firewall receives a copy of the network traffic, including
client requests to the database and the database's response to those requests. Use spanning ports, network taps, or
packet replicators to copy database traffic to the firewall. In this mode, the Database Firewall can monitor and alert
on SQL traffic, but cannot block or substitute SQL statements.
c) Host Monitor: This is a specialized application of out-of-band. Database Firewall supports a local server-side
collection agent called the Host Monitor. This agent captures SQL traffic reaching the database server and securely

35 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 forwards it to Database Firewall, effectively functioning as a packet replicator. In this deployment mode, the
Database Firewall can monitor and alert on SQL traffic, but cannot block or substitute SQL statements.
These deployment modes are represented in the diagram below.

Proxy deployment mode:

In this mode, the Database Firewall is in-line with the SQL traffic and the clients connect to the Database Firewall over TCP.
The Database Firewall makes an outbound connection to the database and forwards the SQL traffic only if the incoming
requests are allowed by the firewall policy. In this mode, the Database Firewall is an intermediary between internal and
external IP addresses. Hence, in proxy deployment mode, the Database Firewall acts as a combination of Proxy Server and
Application Firewall for the SQL traffic. Other controls, including traditional network firewalls or Database Vault should be
used to block direct access to the database that attempt to bypass the Database Firewall.

Database Firewall supports the following protocols:

• Oracle DB: Transparent Network Substrate (TNS)
• MS SQL Server: Tabular Data Stream Protocol (MS-TDS)

• Sybase: TDS
• MySQL: MySQL
• DB2: DARDA V5 specification (Distributed relational database architecture)

As a database proxy, the Database Firewall can understand and validate client properties including client IP address,
program module, and operating system user. The Database Firewall is not a general-purpose proxy, for instance there is no
access to information about packets nor caching capability. As an application firewall, the Database Firewall can understand
and validate database commands and offers logging capability as well as additional screening of the SQL statements.
Database Firewall policies are used to enforce access control, for example, allow only certain users access database from
specified IP addresses.
Host Monitor/ Out-of-band deployment mode:

In this mode, the Database Firewall receives a copy of database traffic, and can be configured only for monitoring and
alerting on network SQL traffic. Hence, the Database Firewall does not behave as an application firewall because it is not in -
line with the database traffic. This deployment mode cannot be used to enforce access control.

Consider using the proxy mode of deployment for very critical or sensitive database systems, which in addition to
monitoring and alerting, need a stricter prohibition of unauthorized activities at a layer closer to where the sensitive data

36 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
resides. This would constitute the last layer of defense in a defense-in-depth protection strategy of highly secured domains
with strictly enforced access controls.

Non-proxy mode of deployment is recommended for database systems which are relatively less critical, or have other
complementary perimeter protection devices like filtering routers, web application firewall, gateways which already have the
capability to enforce stricter access control including blocking traffic.

All three modes of deployment (Proxy, Out-of-Band and Host Monitor) can monitor SQL traffic encrypted with Oracle Native
Network encryption for Oracle Databases.

4.3. Firewall Policy

RBI Guidelines emphasize the need for an effective firewall policy management to make sure that the IT infrastructure is
secured against unauthorized and potentially harmful traffic. Using a database firewall effectively requires creating and
establishing intelligent and targeted firewall policy decisions. A firewall policy dictates how Database Firewall should handle
SQL traffic for specific IP addresses, address ranges, protocols, applications, and content types (e.g., session content) based
on the organization’s information security policies. RBI Guidelines pertaining to structuring an effective firewall policy are
listed below.

RBI Guideline Source Firewall Policy

Implication

A firewall policy states management’s expectation for how the Ref 1, Page 41, To be able to reject any
firewall should function and is a component of the overall security item 24.vii.a SQL traffic not explicitly
management framework. Acceptable inbound communication allowed and log SQL
types for the organization need to be explicitly defined in the traffic as specified in the
firewall policies. … policy.

At a minimum, the policy should address various aspects like

Firewall topology and architecture and type of firewalls being
utilized, physical placement of the firewall components, permissible
traffic and monitoring firewall traffic, …., responsibility for
monitoring and enforcing the firewall policy, protocols and
applications permitted, regular auditing of a firewall’s
configuration and testing of the firewall’s effectiveness, and
contingency planning.

Given the importance of firewalls as a means of access control,

good firewall related practices include:

➢ Using a rule set that disallows all inbound and outbound

traffic that is not specifically allowed ..

➢ Restricting network mapping capabilities through the firewall,

primarily by blocking inbound ICMP (Internet Control Messaging
Protocol) traffic

➢ Logging activity, with daily administrator review and limiting

administrative access to few individuals

➢ Using security monitoring devices and practices to monitor

actions on the firewall and to monitor communications allowed
through the firewall

Applications must also provide for, inter-alia, logging unsuccessful Ref 1, Page 25, To capture unsuccessful
logon attempts, access to sensitive options in the application, item 11.c.6 logon attempts and
e.g., master record changes, granting of access rights, use of system access to sensitive data.
utilities, changes in system configuration, etc.

37 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 Banks’ networks should be designed to support effective monitoring. Ref 1, Page 32, To detect and block
Design considerations include network traffic policies that item 17.iii, v anomalous database
address the allowed communications between computers or traffic.
groups of computers, security domains that implement the policies,
sensor placement to identify policy violations and anomalous traffic,
nature and extent of logging, log storage and protection..

Highly sensitive and/or critical IT assets would need to have logging

enabled to record events and monitored at a level proportional to
the level of risk.

Network boundary devices, including firewalls, network-based IPSs, Ref 1, Page 37, Ability to configure
and inbound and outbound proxies may be configured to log item 21.v.e logging of all traffic that
verbosely all traffic (both allowed and blocked) arriving at the device passes through the
firewall.

To be able to monitor
traffic across the
network boundary.

Banks use third-party service providers in a variety of different Ref 1, Page 38, To report on third-party
capacities. It can be an Internet service provider (ISP), application or item 23.i service provider
managed service provider (ASP/MSP) or business service provider activities within the
(BSP). These providers may often perform important functions for database.
the bank and usually may require access to confidential
information, applications and systems.

Firewalls: The main purpose of a firewall is access control. By Ref 1, Page 40, To block any
limiting inbound (from the Internet to the internal network) and item 24.vii.a communications not
outbound communications (from the internal network to the explicitly allowed.
Internet), various attack vectors can be reduced.

Network access by system engineers should be monitored and Ref 1, Page 46, Close scrutiny on
reviewed closely to detect unauthorized access to the network. item 24.viii.r system engineers by
constructing policies
specific to these users.

Banks may sometimes provide employees, vendors, and others with Ref 1, Page 46, Enabling remote access
access to the institution’s network and computing resources through item 25.i, item with greater monitoring
external connections. 25.iii.h,i,j,l along with logging. All
details such as IP, user,
Logging remote access communications, analyzing them in a
time, etc. needs to be
timely manner, and following up on anomalies…
captured.
.. subject the inbound and outbound network traffic to appropriate
perimeter protections and network monitoring

Logging and monitoring the date, time, user, user location,

duration, and purpose for all remote access including all activities
carried out through remote access

Implementing controls consistent with the sensitivity of remote use.

For example, remote use to administer sensitive systems or
databases may include the controls like restricting the use of the
access device by policy and configuration,…

Instituting strong controls over remote access by privileged users Ref 1, Page 20, Privileged user remote
item 5.(xiii).b access monitoring to be
done using policies
specific to these users.

38 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 Comprehensively address network and database security: … It is Ref 2, Page 3, To be able to reject
essential that unauthorized access to networks and databases is not item 9 unauthorized access
allowed and wherever permitted, these are through well-defined patterns, and alert on
processes which are invariably followed. those as needed.

Consider implementing whitelisting of authorised applications / Ref 2, Page 8, Allow whitelisting of

software/libraries, etc item 2.1,item 2.2 applications, network
addresses, and
Mechanism to block /prevent and identify installation and running
operating system users
of unauthorised software/applications
for controlling access to
databases protected by
the firewall.

Have mechanism to automatically identify unauthorised device Ref 2, Page 9, Close supervision of
connections to the bank’s network and block such connections. item 4.6, item network access and
4.7, item 4.9 creation of policies that
Put in place mechanism to detect and remedy any unusual activities
alert on unusual access.
in systems, servers, network devices and endpoints.

Security Operation Centre to monitor the logs of various network

activities and should have the capability to escalate any abnormal /
undesirable activities

Implement controls to minimize invalid logon counts, deactivate Ref 2, Page 11, Monitors invalid logins
dormant accounts. item 8.6, item and detect changes in
8.7 logon patterns.
Monitor any abnormal change in pattern of logon.

Consider implementing whitelisting of internet websites/systems. Ref 2, Page 14, Ability to whitelist and
item 13.3, item create policies is
Consider implementing secure web gateways with capability to deep
13.4 needed.
scan network packets including secure (HTTPS, etc.) traffic passing
through the web/internet gateway

Put in place mechanism to detect and remedy any unusual Ref 4, Page 7, To detect unusual
activities in systems, servers, network devices and endpoints. item 1.1, item 1.2 activities in databases.
Firewall rules shall be defined to block unidentified outbound
connections, reverse TCP shells and other potential backdoor
connections.

Recommendation:

RBI recommends that a good firewall practice should disallow all inbound traffic that is not specifically allowed or
permitted—traffic that is not needed by the organization. This practice, known as deny by default, decreases the risk of
attack. Whitelisting is a deny by default approach. Because of the dynamic nature of hosts, networks, protocols, and
applications, deny by default(i.e. whitelisting) is a more secure approach than permitting all traffic that is not explicitly
forbidden(i.e. blacklisting). To set up a whitelist policy, create a policy that monitors “normal" user behavior and use the
observed SQL traffic to create whitelist policies.

The Database Firewall policy is a combination of different rules like Session Context Rules, SQL Statement Rules, Database
Object Rules and Default Rules. Database Firewall in AVDF is a multi-stage Firewall policy rule-processing engine as shown
below in the diagram. The rule processing happens sequentially with the first match determining the appropriate action.

39 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
a) Session Context Rules:

Session context rules based on whitelisting approach, provides a powerful means of controlling SQL requests based on
known sets of session attributes. These rules override all other policy rules and determine the action, logging level and
threat severity to use when certain session activity is observed. Session attributes that can be used are the following:

Session Attributes Sets Description

IP Address Sets Specified set of IP addresses of database clients

Database User Sets Specified set of database user login names

Database Client Sets Specified set of client programs

OS User Sets Specified set of operating system user names

Consider creating ‘Session Context rules’ to allow specific traffic from trusted application paths without needing them to go
through further processing in the Database Firewall policy engine (e.g. SQL requests from a trusted set of whitelisted client
IPs). Combining multiple sets (for example, IP with database user or IP with OS user) provides flexibility in narrowing down
the permitted traffic through the Database Firewall. Any traffic, which does not fit the whitelist, is subjected to monitoring or
blocking using a combination of Action, Logging, Threat Severity and Escalation.
A sample session context rule is shown below, that allows the SQL traffic from specific set of whitelisted DBA users ( as
configured in the set ‘Allow DBAs’) to pass through the firewall policy.

Allow the SQL traffic from

whitelisted DBA users as specified
in the set ‘Allow DBAs’

40 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
Set Action, Logging Level and Threat Severity values commensurate with the risk level of session attributes being used. For
instance, a policy that whitelists database users (e.g. DBA users) from whitelisted client IP address set can have ‘Action=Pass,
Logging Level=Unique, Threat Severity=Minimal’. However, if there were database users corresponding to third-party
service providers, even if the SQL request comes from whitelisted client IP address set, we would want to monitor them
closely. The Action, Logging Level and Threat Severity values can be set to ‘Action=Alert, Logging Level=Always, Threat
Severity=Moderate’ to always alert on their access. With increasing risk proposition, alter these settings to a more rigorous
logging strategy.

b) SQL Statement rules:

SQL Statement rules are executed after the session context rules. The Database Firewall automatically captures, analyzes the
actual SQL traffic and classifies similar SQL statements into groups known as clusters. Consider creating whitelists of SQL
Cluster sets and specify Action, Logging level and Threat severity for each SQL cluster set in the analyzed SQL policy rule.
Whitelists of “normal” behavior could also be automatically created by running the Database Firewall in training mode with
Log Unique default policy (where it logs unique SQL statement) and capturing a set of expected SQLs representing normal
traffic, such as the set of SQL generated in a test or QA system.

A sample SQL Statement rule is shown below, that allows a trained set of SQL statements from HR application to access the
database (as configured in the set ‘Normal HR Application SQL’).
Allow the trained SQL traffic as
specified in the set ‘Normal HR
Application SQL’

It is recommended to use SQL Statement firewall policy rules only when all the trusted application paths accessing the
database are well known, including the expected SQL traffic. Any anomaly in the SQL network traffic, which is not yet
profiled, can be captured with this rule. Utilize this firewall policy rule for databases with highly sensitive and/or critical IT
assets, especially for applications accessible over the public internet.

c) Database Object rules:

Database Object rules can be used to prevent or allow specific types of SQL statements (DML, DCL, etc.) acting on specific
database objects such as tables and views. Consider these rules to increase scrutiny of sensitive data access over network.
Database object rules let you closely monitor network activities on sensitive tables in the database. These rules can prevent
or allow specific types of SQL statements acting on specific database tables. For instance, allow only SELECTS on application
tables but warn/alert if there are attempts to perform data modification on sensitive application tables.

These rules are often used for controlling behavior of privileged users over the network where it might be necessary to stop
them from accessing specific sensitive application database objects.

A sample database object rule is shown below, that raises an alert if SQL traffic has any DML activity (insert, update or
delete) on any of the two sensitive tables.

41 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 Alert if there is any DML
activity on any of the two
sensitive tables

d) Default rule:

The default Rule is a catch-all rule where SQLs that does not match any of the above rules are acted upon. In the whitelisting
approach, it is recommended to alert with major threat severity so that any unseen SQL traffic is alerted on and marked as
actionable. In highly critical systems, consider using a blocking/ blocking-with-substitution action after the firewall is trained
to understand all the normal expected traffic.

Block and alert unseen

A sample Default rule is shown below which blocks all unseen SQL traffic.
SQL traffic

The various rules are explained in detail in ‘Database Firewall Deployment’ in the Audit Vault and Database Firewall
Concepts Guide.

Consider incorporating the following firewall policy configuration best practices to help comply with RBI Guidelines:

1. Allow specific whitelisted SQL traffic using Session Context rules

Whitelist based on trusted application path as discussed earlier and consider incorporating combination of session attributes
in the whitelisting rules. Consider incorporating the following:

a) Whitelist the client IP addresses that are authorized to access the database systems. For instance,
corporate network addresses that trusted clients will use to access the database. Any remote access
not originating from whitelisted client IP addresses warrants a higher level of scrutiny as indicated in
RBI Guidelines and can be configured to send an alert or be blocked.

b) Whitelist the database client programs that are authorized to connect to the database over specific
client IP address.

c) Whitelist the database users (application service accounts) expected from the client IP addresses
accessing the database systems using authorized client programs. Consider creating a combination of
client IP address, database users (application service accounts) and database client programs.

42 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
 d) While application service account’s access from known set of client IP address from known database
client may present a low risk, it is essential to detect unusual activities in case this account is hijacked
or misused by employees with knowledge of the credentials. Consider using an escalation policy in
Session Context rules to detect any anomaly.

A sample escalation policy is shown below, that allows SQL traffic to pass the firewall. But if the same SQL traffic is seen
multiple times (as configured in threshold), the SQL traffic is blocked and replaced with a substitution SQL statement.

Block and substitute the SQL

statement only if it is seen 3
times in 120-second window

e) Database administrators are frequently given direct /SSH access to the database server. Database and
operating system auditing should be used to closely monitor their activities. For remote database
access, it is imperative to monitor and closely review the activity by these privileged administrators,
especially if there is any deviation from normal pattern of access. Consider monitoring the following
actions of these privileged administrators over the network:

o If the privileged database users are accessing over the network from the whitelisted client IP
addresses. Generate an alert with setting (Action =Warn, Logging Level=Unique) and indicate
the threat severity to a level that is actionable.

o If privileged database users are accessing from non-whitelisted client IP address, further
firewall policy rules like Database Object rules, SQL Statement rules and Default Rules can
factor in increased scrutiny of their actions.

o Repetitive SQLs attempts by privileged database users from whitelisted client IP addresses
firing the same SQL in specified threshold can be flagged as potential anomaly by creating an
escalation policy where Logging Level and Threat Severity can be increased.

f) If there are third party service providers in the system (differentiated by specific OS user/database
user), subject them to a higher level of scrutiny as indicated in RBI Guidelines even if their access is
through whitelisted client IP address. Recommend not whitelisting these users.

2. Increase scrutiny of sensitive data access over network

Access to sensitive objects in the database system always warrants higher scrutiny if it is not through established application
trusted paths as indicated by RBI Guidelines. Some of the use-cases that need to be alerted, as indicated in the RBI
Guidelines include
a) Administration or other privileged access to sensitive or critical IT assets

b) Remote access through public networks to sensitive assets and activities carrying higher risk like
third-party fund transfers
c) Third-party access to sensitive data/information

d) Any modifications in sensitive master data

43 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
Consider choosing an escalation policy to change the action settings if there are repeated attempts. For instance, while
privileged users doing SELECTS on sensitive application tables can potentially be flagged as a low risk, recommend alerting
if there are repetitive attempts in a specific threshold time.

3. In the default rule, block or rigorously monitor all traffic

Use the default rule to block / monitor with ‘Action=Alert, Threat Severity=Major’ for all the traffic reaching this final Default
rule to ensure the SQL traffic is monitored rigorously.

4. Use firewall policy rules to detect abnormal login attempts

RBI recommends minimizing invalid logon counts. These actions are typical of Denial-Of-Service attacks or intruders
attempting to gain access to authorized system using brute-force attempts. If the database users are non-existent in the
Oracle Database, audit events will not be generated for failed login attempts even with ORA_LOGON_FAILURES predefined
policy. With Database Firewall, one can detect these login attempts using failed login policy settings.

A sample policy configuration is show below, that detects five consecutive failed login attempts and blocks the client
connection for a minute.

Five consecutive failed login

attempts will block the client
connection for 60 seconds.

Consider following these best practices for enabling logging in Database Firewall policy:
a) Be selective in what you log
b) Log all SQL for users with elevated privileges
c) Set Policy action to ‘Pass’ regular application activity

d) Log SQL only for sensitive activity from applications

e) Use threat levels to prioritize events

The Database Firewall sends the captured firewall events to the Audit Vault Server. There is a default alert policy rule called
‘Database Firewall Alert’, which processes all the firewall events in ‘Warn’ or ‘Bock’ status (as determined by the Action in the
firewall policy rules), and generates alerts.
A sample alert report is shown below, that provides the details of the alerted SQL traffic using the default firewall alert policy.

44 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
In addition, rule-based alerts can be defined on the event data received from the Database Firewall. Alert conditions are
flexible and can include more than one event, and the events can come from different databases.

For continuous monitoring of network activity for detecting unusual traffic patterns, consider using Database Firewall
reports as given in Establish Proactive Security Monitoring Practices, including Sensitive Data Access.

CONCLUSION

Database Activity Monitoring is one of the key requirements for RBI compliance on cyber security regulations. RBI
recommends that banks address network and database security comprehensively.

By using Oracle Database’s native auditing feature, and Oracle Audit Vault and Database Firewall (AVDF), banks can not only
accelerate their implementation but also achieve comprehensive security controls for their sensitive data.

APPENDIX

Application Activity Auditing Sample

A sample procedure, which populates application context attributes from gv$session and userenv, and the audit
configuration which captures the context attributes in the audit trail, is shown below.

-- Look up gv$session fields

SELECT V.PROGRAM INTO program_name
FROM GV$SESSION V
WHERE V.audsid = sys_context('USERENV', 'SESSIONID')
AND V.inst_id = sys_context('USERENV', 'INSTANCE')
AND V.SID = SYS_CONTEXT('USERENV','SID');

DBMS_SESSION.SET_CONTEXT('app_ctx', 'UNIQUE_SESSION_ID', DBMS_SESSION.UNIQUE_SESSION_ID );

DBMS_SESSION.SET_CONTEXT(''app_ctx'', 'PROGRAM', program_name);
DBMS_SESSION.SET_CONTEXT('app_ctx', 'SERVICE_NAME', sys_context('USERENV', 'SERVICE_NAME'));

--Enabling audit of app_ctx application context

AUDIT CONTEXT NAMESPACE app_ctx ATTRIBUTES UNIQUE_SESSION_ID, PROGRAM, SERVICE_NAME;

Unified Audit trail with APPLICATION_CONTEXTS field populated:

APPLICATION_CONTEXTS

----------------------------------------------

(APP_CTX,[email protected](TNSV1-V3));
(APP_CTX,SERVICE_NAME=adm.DEV);(APP_CTX,UNIQUE_SESSION_ID=029D07880001);

45 Accelerate DAM Readiness to RBI Guidelines

Copyright © 2020, Oracle and/or its affiliates
CONNECT WITH US
Call +1.800.ORACLE1 or visit oracle.com.
Outside North America, find your local office at oracle.com/contact.

blogs.oracle.com facebook.com/oracle twitter.com/oracle

Copyright © 2020, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without
notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties
and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed
either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without
our prior written permission.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Accelerate DAM Readiness to RBI Guidelines

June, 2020
Angeline Janet Dhanarani, Database Security Product Management