Cybersecurity Alliances
DATBASE SECURITY USECASES
Most enterprises are paying too little attention to the very real security risks associated with their
databases.
Databases – especially RDBMSs – are growing larger all the time, and the information they hold is
increasingly sensitive and subject to compliance requirements of many different kinds. These sensitive
data types include intellectual property, personally identifiable information, personal health information
and financial information. These issues raise serious security and privacy concerns, but they also present
risks in other areas, including concerns about system and data availability.
There are following types of Use cases to be configured in any DAM solution,
• Audit Policy (Event collection only)
• Security Policy (Signature is fired when event matches the configured criteria)
1 AUDIT POLICY
Audit policy controls the logging and archival of in-scope database transactions and serves as a mechanism
to log and store database activity for compliance, analysis, investigation and forensics purposes.
1.1 Custom audit policies for consideration.
These are by no means a complete list, but a sample list to show what can be done with the audit policy structure.
Some of the policies require input from the customer as well as possible data being pulled from external systems.
1.1.1 Login and Logout
This audit policy shall capture all logins and logouts. It is anticipated that there may be several variants to
this audit policy depending on location, platform, and environment.
1.1.2 SQL Exceptions
Theis audit policy would track exception errors generated in the database so as to have database log errors
resident in DAM solution for the purposes of forensics or in the event that the database is unavailable.
1.1.3 Database Object changes – execution of DDL
This command-based audit policy will track anything that is not Select, Update, Delete, or Insert for the
purposes of DDL awareness.
1.1.4 User Privilege Management
This audit policy predicates tracks all SQL privileged commands related to user management and
permissions.
Cybersecurity Alliances
1.1.5 Database Management
This command-based audit policy will account for those SQL commands known to involve database
management SQL commands, conflicts, code changes, and backups.
1.1.6 Questionable Operations
This command-based audit policy will account for those SQL commands that are considered to be
questionable or deserving of deliberate scrutiny.
1.1.7 Operations Affecting Performance
This command-based audit policy will account for those SQL commands that considered to be out of the
ordinary or impactful to the database health, status, or availability.
1.1.8 Modification of system level objects
This audit policy tracks changes to system object tables.
1.1.9 Access to sensitive data tables, PCI, SOX PII
This audit policy logs activity against sensitive tables.
We can also use this policy to audit activities for data modifications by adding update, insert and
delete to the match operation.
1.1.10 Privilege changes to sensitive data tables
This audit policy logs privileged operations activity against sensitive tables.
Please keep in mind that table-based audit policies will require the entry of the table names that
house sensitive in-scope compliance data. These sensitive tables must either be mined and
provided to DAM solution or discovered via a data classification scan.
1.1.11 Targeted Account Usage
This user-based audit policy audit all activity from a specified user. It can track activity from a
user(s) under investigation.
1.1.12 Deactivated Account Usage
This user-based audit policy shall record all activity from a specified user. It can track activity from
former employees, expired contractors, former partners, decommissioned users, or any other
type of user that is regarded as deactivated.
2 SECURITY POLICY
Security policy controls the alerting and optionally the blocking of transactions that are contrary to
security protocol.
Security policies are divided into following five categories,
Cybersecurity Alliances
• Role Type No. 1. Privileged Users
• Role Type No. 2. End Users
• Role Type No. 3. Developers
• Role Type No. 4. IT Operations
• General Security Use Cases
2.1 Role Type No. 1. Privileged Users
Users with special, high-level privileges – typically database administrators (DBAs), superusers and system
administrators – should always be subject to intense scrutiny. These users have visibility into, and access
to data, so they can potentially do enormous damage. They should be monitored and audited for at least
following activities.
2.1.1 Access to, deletion of, or changes to data.
Privileged users, with very rare exceptions, do not need access to the actual data they manage
(for example, the content of database tables). The potential for abuse is obvious – a DBA could,
for example, access the payroll system to learn fellow employees’ salaries, or even to change
his/her own salary information. A system administrator might also alter financially relevant
information, deliberately or inadvertently, causing Sarbanes-Oxley Act violations in the U.S. It is
difficult to assess how serious a problem this currently represents, because many enterprises are
reluctant to publicly acknowledge such cases; however, anecdotal evidence suggests that
privileged-user access is a significant real-world problem. Preventive controls are difficult to
implement in this area, but detective controls can be effective in limiting the damage and
preserving the audit trail.
2.1.2 Unauthorized DBA Read
This security policy can be used to alert when a DBA attempts to select from tables that do not
relate to the function of a DBA.
2.1.3 Access using inappropriate or nonapproved channels.
Accessing databases outside of normal channels can also be symptomatic of compromised
accounts being used by external attackers. Best practices call for DBAs to use specific, approved
tools – for example, Tool for Application Developers (TOAD) for Oracle databases. Another
common problem is the privileged user who makes a remote console connection to the database,
or simply enters the data center and physically accesses the database, bypassing network- and
application-layer controls, concealing problems that security information and event management
(SIEM) and monitoring controls might otherwise detect. In addition to the risks associated with
accidental or deliberate disclosure of data, these practices also present potential availability and
integrity risks.
Cybersecurity Alliances
2.1.4 Unapproved Application Usage
This security policy can be used to alert when a user uses an application that is not approved for
database queries.
2.1.5 Suspicious DBA On IPC/Local
This security policy can be used to alert when a DBA or privileged account attempts to read
sensitive records locally from within the database server and not through the network. Privileged
user access not through an approved database application over the network but through an IPC
channel such as through shared memory, loopback, names pipes, etc.… almost always indicates
non-best-practice or malicious intent of theft of records by deliberately circumventing DAM
controls.
2.1.6 Schema modifications.
The schema – the metadata and the rules applied to the database’s structure – is central to its
secure and efficient operation and management. Schemas and metadata must be kept absolutely
consistent; inappropriate or unauthorized modifications to the schema can be extremely
damaging. A DBA could, for example, create a brand-new table, copying the data from another
table into the new table, download the new table – which probably would not be audited, because
its existence is unknown – and then delete that table. The result – the DBA has accessed the data
without triggering monitoring or auditing. Changes to the schema are not necessarily malicious.
They may be entirely inadvertent, but even mistakes can seriously impact data availability.
Unauthorized addition of
2.1.7 Non-Privileged User Modifying System Objects
This security policy can be used to alert when a non-privileged user attempts to modify the
underlying database structure configuration resident in system tables.
2.1.8 Non-Privileged User Stored Procedure Manipulation
This security policy can be used to alert when a non-privileged user attempts to modify stored
procedures.
2.1.9 User accounts or modification of existing accounts.
A DBA or other privileged user who knows his own activities are audited and logged could create
an account in a fictitious name, use a dormant account, or change a valid account to give it higher
levels of access. The new or altered account could then be used to access or change data, and
then be deleted so that no one knows the inappropriate activity has taken place. The
opportunities for large-scale data
2.2 Role Type No. 2. End Users
Cybersecurity Alliances
End users – individuals who have legitimate access to data through some type of application – present
serious risks for deliberate as well as unwitting misuse of that data. Security professionals should monitor
these roles for three potential problem behaviors.
2.2.1 Access to excessive amounts of data or data not needed for legitimate work.
Gartner recommends the “least privilege” approach to data access as a best practice, but we
recognize that this is difficult to implement. In real-world environments, end users are typically
granted more data access than they need to do their jobs. For this reason, enterprises should set
thresholds for “typical” levels of data access and trigger investigations on activities beyond those
thresholds. For example, a call center employee might access approximately 50 sets of customer
financial records in a typical working day. If that same worker suddenly accesses thousands of sets
of records, that activity should be taken as a clear warning sign of potentially damaging activity.
For the same reason, an end user accessing data that is not required for his/her normal role– for
example, a customer service representative downloading HR records for other employees, or a
data center employee accessing a celebrity’s healthcare information – should trigger an
immediate investigation.
2.2.2 DB Response Over X Rows – Excessive read
This security policy would alert when query response exceeds XXX records on sensitive table.
The same policy can be used for excessive modification of data by including update, insert and
delete in the match operation.
2.2.3 Excessive Read
This security policy can be used to alert on selects to sensitive contents that exceed a threshold
of affected records, which may indicate malicious intent or theft.
2.2.4 Excessive Modify
This security policy can be used to alert on modifications to sensitive contents that exceed a
threshold of affected records.
2.2.5 Non-Privileged User Performing Privileged Operations
This security policy can be used to alert on any privileged operation submitted from a user who
has no such privilege to do so.
2.2.6 Access to data outside standard working hours.
Many of the behaviors discussed up to this point relate to insider threats of various kinds, but this
is one that also raises the strong possibility of external attack. When a company’s normal working
hours are Monday to Friday from 9 a.m. to 5p.m., someone accessing a database on Sunday at 3
a.m. may indicate that an attacker has attempted to gain access using hijacked credentials. Unless
monitoring is implemented for reporting on this type of activity, the unauthorized activity is likely
to go entirely undetected, until it results in a highly damaging, highly publicized data breach.
Cybersecurity Alliances
2.2.7 Access to data through inappropriate or nonapproved channels.
This problem is similar to that for privileged users, but the risk is somewhat different. End users
sometimes access data directly, without using the approved applications or channels. They
sometimes do this simply for convenience. But the result may be undetected changes to data that
seriously impacts availability and data integrity. Enterprises need detective security measures to
determine whether end users are trying to bypass proper channels. One possible scenario could
take place if an application required creation of local database accounts. Users could potentially
go directly to the database, bypass application-level controls, and view or alter critical data.
2.2.8 Unapproved Application Usage
This security policy can be used to alert when a user uses an application that is not approved for
database queries.
2.3 Role Type No. 3. Developers
Developers, System Analysts and System Administrators These users present two specific types of IT risk.
The first is the potential for data breaches that compromise intellectual property or personal privacy,
because these roles necessarily have extremely high levels of privilege and access. A much more serious
problem, however, is that these technically skilled individuals often have the ability to access or change
systems that are in live production, which can result in poor performance, system crashes and, in some
cases, security vulnerabilities. This is the primary behavior by individuals in these roles that auditors
should watch for.
2.3.1 Access to live production systems.
Best practice indicates that developers and other users with similar roles and responsibilities not
have access to production systems using privileged accounts. Any access to these systems
that is required for normal activities should be via standard user accounts. The reality, however,
is that the overhead of using two accounts leads to violation of this policy. There are several risks
associated with this –changes made to live systems, especially without testing, could easily result
in system instability and crashes. Application or database changes made to live systems could also
alter the effective permissions and result in users having access to data to which they should not
have access.
2.4 Role Type No. 4. IT Operations
The IT operations organization – not only the individual employees, but also the processes for which the
organization is responsible –has a significant impact on the proper functioning and management of
enterprise databases. Their database-related activities should be audited in two key areas.
2.4.1 Unapproved changes to databases or applications that access the database.
IT operations personnel have a strong tendency to want to fix problems as soon as they are
recognized, without necessarily planning, testing or evaluating their “fixes” or consulting the
appropriate stakeholders. Auditors are continuing to focus on change and configuration
management processes, especially within systems containing or processing regulated data. When
databases are involved, this can cause serious data security and availability issues. Table
structures, data types and other key database elements should not be changed unless the changes
are mapped against a change management system of some kind.
Cybersecurity Alliances
2.4.2 Out-of-cycle patching of production systems.
Most enterprises with robust operational management processes have defined “operational
windows” for patches (for example, applying patches only on certain dates or at certain times).
Patches that are applied “on the fly,” or otherwise outside normal patch management processes,
may adversely impact data storage and availability – and may be a sign of a larger problem.
2.5 General Security Use Cases
2.5.1 Excessive login attempts
This security policy would alert when a user fails authentication multiple times.
Number of occurrences could be set in line with security policy,
2.5.2 Unauthorized Source
This security policy can be used to alert on activity from an unapproved or unwelcome network
segment against databases. It can also be used in a whitelist fashion stating that only queries from
known or approved source subnets will not generate an alert.
2.5.3 Disabled Active Directory User Login Attempt
This security Policy would alert when an active directory disabled account was used.
Requires lookup table for active directory disabled accounts.
2.5.4 Database default user account usage
This policy could be used to alert for when known database default user accounts are being used.
Example; Oracle platform default accounts BLAKE, SCOTT
2.5.5 Cumulative Read
This security policy can be used to alert on selects to sensitive contents that exceed a threshold
of affected records within a custom timeframe, which may indicate malicious intent or slow,
under-the-radar theft.
2.5.6 Targeted Account USAGE
This user-based security policy alerts on any activity from a specified user.
2.5.7 Deactivated Account Usage
This user-based security policy alerts on any activity from a specified user, including activity from
former employees, expired contractors, former partners, decommissioned users, or any other
type of user that is regarded as deactivated.
2.5.8 Password Spray.
This security policy can be used to alert when one password is being tried on multiple DB users in
a short interval of time.
Cybersecurity Alliances
2.5.9 Password Stuffing.
This security policy can be used to alert when pair of username and passwords are being tried in
an effort to crack one default user with default password.
2.5.10 Brute Force.
This security policy can be used to alert when multiple passwords are being tried to one particular
user.
