DataSunrise Rules Best Practices

Introduction

DataSunrise Database Security is a powerful Database Activity Monitoring/Data Auditing and real-time Data Protection and Database Firewall solution that significantly increases data and database security level both on-premise and in the cloud. Often, it is difficult to understand what data should be protected, where that data is located in your database and how to configure DataSunrise Suite to get the highest possible protection.

This document contains a detailed description of DataSunrise Rules best practices that will help you to create the most effective and appropriate data security configuration.

DataSunrise Key Features and Capabilities

1. DB Activity Monitoring / Data Auditing

DataSunrise database activity monitoring (DAM) enables real-time tracking of all user actions and changes made to a database. While database auditing is used mostly for data breach investigation, continuous database activity monitoring helps to detect access rights abuse attempts and prevent data breach preparations in advance.

Besides that, DataSunrise utilizes intelligent self-learning algorithms and behavioral analysis to speed up the database firewall deployment process. DataSunrise analyzes typical user and applications behavior and creates a “White List” of SQL queries considered safe by default.

2. Data Protection and Database Firewall

DataSunrise’s Data Security module is the primary tool defending corporate databases against harmful and hostile actions and ensuring compliance. Armed with continuous traffic monitoring and advanced SQL analysis algorithms, DataSunrise detects SQL injections and unauthorized access attempts in real time. When DataSunrise’s database firewall detects a security policy violation, it blocks the malicious SQL query immediately and notifies the administrators via SMTP or SNMP.

3. Compliance Manager

Compliance Manager ensures compliance with a number of national and international security standards and regulations such as HIPAA, PCI DSS, ISO 27001, GDPR and SOX. The Compliance Manager functionality takes total control over access to corporate databases to prevent illegal data processing, unauthorized data modification or accidental data loss.

Compliance Manager’s functionality is based on an automatic discovery of sensitive data in a target database, assigning certain roles to the target database users and implementation of security, masking and audit policies according to these roles as well as periodic compliance reporting for permanent review of database activity.

4. Sensitive Data Discovery

DataSunrise Data Discovery identifies sensitive data in corporate databases and helps to establish the most effective protection of this data. It enables companies to understand what level of control is appropriate for each type of sensitive data their databases contain. Also, this feature helps to comply with the demands of such regulations as GDPR, HIPAA, SOX, PCI DSS and others.

5. Dynamic Data Masking

DataSunrise prevents sensitive data exposure with its Dynamic Data Masking (DDM).

DataSunrise DDM secures business-critical information by obfuscating the data of interest in the complete database or just in selected tables or columns for unwanted users. DataSunrise masks the data by replacing the actual database entries with randomly-generated or user-predefined values.

In order to prevent potential data leaks, database entries specified by a DataSunrise user are masked on-the-fly before the data is extracted from the database.

Compliance Manager

Compliance Manager is a good tool for creating an initial configuration of DataSunrise. In short, it automates the setup steps of DataSunrise by performing Data Discovery and creating configuration entities based on Data Discovery results. Compliance Manager creates the following entities:

• Audit Rule for database objects that contain sensitive data
• Security Rule for blocking SQL injections
• Security Rule for blocking access to sensitive data to everyone except certain users included in database user groups defined during Compliance Manager operation
• Security Rule for blocking all admin queries issued by database users who do not belong to the “allowed” user groups
• Masking Rules for obfuscation of sensitive data for database users not included in “allowed” user groups and not authorized to process the original data.

Apart from the set of rules described above, Compliance Manager creates the following reports as well:

• Audit Report on cases of access to sensitive database objects
• Security Report on attempts to access sensitive data by users who are not authorized to handle protected data
• Errors Report on queries which were not executed due to errors of any origin
• System Events Report on events occurred in DataSunrise during the period of interest
• Masking Report on cases of access to sensitive data that resulted in obfuscation of data for users who are not allowed to handle the original sensitive data.

Note that Compliance Manager can’t ensure 100% covering of all the insecure data contained in a target database. Compliance manager provides you with a configuration that you can use as a baseline, first estimation setup for your case. Although this approach provides you with a ready-for-action setting for your DataSunrise Security Suite, though you may find the suggested role model not suitable for your particular case. In this case you can customize your Rules’ Filter Sessions options.

Sensitive Data Discovery

Sensitive Data Discovery helps you to search for sensitive data contained in your database. It is wise to configure a Data Discovery periodic task that continuously discovers sensitive data according to the multiple built-in security standards. Using Data Discovery results enables you to secure your sensitive data according to your security policies excluding manual searching and manual securing of such data at the same time.

To have a visual representation of the sensitive data found, it’s recommended to configure PDF/CSV report generation periodic tasks as well.

Nevertheless, running a Data Discovery task does not guarantee a 100% discovery of sensitive data. Consulting with DBA also is one of the important steps that should be performed in order not to leave any sensitive data insecure.

Although Data Discovery makes minor impact on the database (when compared to a client application that queries top N (N=100 by default) rows from each table in each database, you can reduce sampling set using the Advanced Settings’ “Analysed Row Count” option.

Audit Rules and Security Rules

Please note that Audit and Security Rules’ settings are similar except of the Actions section. This means that you can monitor or block database activity of interest depending on your choice without missing any possibilities.

When it comes to fine-tuning of Audit and Security rules, the general recommendation is to avoid creating general “all-in-one” rules as it may provide too much data for analysis generated by third-party processes or by a SQL Query tool (such as PGAdmin for PostgreSQL or SQL Server Management Studio for Microsoft SQL Server).

Consider establishing monitoring only for database objects that contain sensitive data or observing access to data which requires strict data access observation and logging. You can use the Object Groups feature to arrange such database objects as tables, views, stored procedures and functions into groups.

Using Object Groups in your Audit/Security rules enables you to establish control and monitoring over your data storage parts of interest to get clear and relevant audit data.

Below, you can find some “recipes” on how to set up DataSunrise Rules in order to deal with the most widespread issues that may cause problems in your database or may be the first signs of an attack on your Data Storage.

Auditing/Blocking of a Suspicious Connection Attempt (Login Attempt)

Despite the fact that applications may establish a lot of connections to a database, it is important to monitor abnormal connection count or connection failures or even restrict this type of activity originating from suspicious hosts and logins. Below, you can find some tips on how to create an Audit/Security Rule which covers all the main cases of suspicious login attempts that often mean that a bad guy is trying to commence a brute-force attack on your database.

1. Auditing/Blocking of frequent Successful/Failed connections (within a time period)

To monitor successful connections to a database through a DataSunrise proxy, use Audit Session Events with the “Audit Frequent Connections” option enabled for auditing cases when there are many frequent connections coming from a certain user+host or host.

In order to prevent frequent successful or failed connection attempts by blocking their source by host+username or by host, enable the “Block DDOS or Brute Force” in the Session Events section of your Rule.

2. Blocking queries coming outside of an allowed IP RANGE

In order to block queries originated from potentially dangerous IP addresses, use the Filter Sessions’ options to configure your Security Rule to be triggered by any queries NOT coming from the hosts included in your DataSunrise’s Hosts list.

3. Preventing insecure connections from being established

A DataSunrise proxy can be configured to accept SSL connections only by enabling “Accept Only SSL Connections” in Proxy Settings of your target database profile in the Web Console.

4. Monitoring of Root and Privileged User connections

Observation of overall Root connection activity can be accomplished by creating a default Audit Object Group or a Query Type rule and by configuring of Filter Sessions’ settings based on the root database user name (e.g. “root” for MySQL, “system/sys” for Oracle etc.) or database user name with admin privileges if you have to avoid using a root user account.

Recommendations for Queries (Session)

1. Data Modification Language Queries

Object Group Audit/Security Rules are preferred over Query Type Rules. They enable establishing monitoring and/or blocking of main CRUD operations performed on a database by adding the required objects from either the Object Browser by choosing objects listed in the rule to be processed or by specifying an Object Group created in advance manually or by using Data Discovery. If the observation of particular query types is required or restricted, use Query Type Audit/Security rule. Note that it is also possible to monitor execution of the chosen query types on certain database objects by specifying an Object Group in the Rule’s settings. Moreover, all Rules can be configured to be triggered only by queries from a certain application, user, application user, host thus ensuring that the created Security Rule will not misfire. For this, configure the Filter Sessions settings of the Rule.

2. SQL Injection type Audit and Security Rules

DataSunrise features a SQL Injection detection mechanism based on penalty points (penalties) that enables you to set your own level of “allowed” queries addressed to your database.

We recommend you to configure a SQL Injection Audit Rule to monitor suspicious queries and set up an Alert in the Notifications section of the Audit Rule. Your filter’s penalty values should correspond to “weak” SQL-Injection queries that can’t do any damage to a database.

Along with Audit Rules with configured Alerts, it is necessary to configure a SQL Injection type Security Rule that will Block SQL Injection queries that exceed the specified number of penalty points.

Note that the number of Penalties should correspond to SQL-Injection queries that can deal a significant damage to a database. The Penalty values should be higher than the ones in the Audit Rule.

3. Queries that return an enormous number of rows

A big number of affected/fetched rows when no corresponding queries used by the application or by BI tools may indicate that there is a suspicious activity happening in the database or the application was compromised. In order to prevent such queries from being executed, use an Object Group type Security rule with “Trigger the Rule Only if the Number of Affected/Fetched Rows is not Less than” enabled followed by the number of affected/fetched rows which is considered abnormal in your environment. An alternative way is to use an Audit Rule with Object Group type filter configured and a Subscriber attached in order to receive notifications on this type of events taking place in the database.

4. Queries executed for too long

When it takes too much time for your queries to be executed, it may lead to performance issues, bad user experience and also may be a sign of an insider trying to steal your valuable data since such data is got by querying an entire table which may take a while. Use an Audit Rule with Session Events configured: enable “Query Execution Takes Longer Than” and set a value (duration in seconds) which is considered abnormal and such long-executed query is required to be audited and reported using the Subscribers feature.

5. Queries with incorrect syntax (the ones that return an error)

In order to monitor queries that were not executed due to a syntax error of some kind, use an Audit Session Events type of Rule with the “Audit Operation Errors” option enabled. Configure error frequency which is considered suspicious and requires DBA or Security team attention. Attach a Subscriber to inform the staff in charge about frequently occurring SQL errors during connection establishing.

6. Queries that access sensitive tables

In order to limit access to a range of database objects, it is recommended to use an Object Group type Security Rule. Using this type of security rules enables you to limit access to certain database objects using either a list of objects which can be selected via the Object Browser or by using an Object Group containing database objects of interest. In order to provide a reasonable level of data access restriction, it is advised to configure Filter Sessions to enable this rule to be triggered or skipped for certain application/database user/application user/host and groups of database users/application users/hosts.

7. Honey Pot table

Consider creating a table (tables) that contain fake sensitive data which will act as a lure for hackers. In case a query is addressed to this table, the query source should be blocked permanently. You can also apply a Learning Rule in order to get more insights on attackers’ strategy (queries, hosts, applications etc.). In general, consider creating a honeypot database in a separate database instance in your environment and put it behind another instance of DataSunrise with separate Audit Storage and Dictionary databases.

8. Blocking unwanted queries

In order to track and/or block certain SQL statements which you do not want to be executed, use DataSunrise’s Query Groups. You can configure them either as query templates (by using regular expressions) or as exact queries that will be checked and audit/blocked on their execution. A Security Rule should be configured to check whether an incoming query is included in the Query Group attached to the Rule using the “Process Group of Query” drop-down list. It should be noted that a Query Group should be created in advance in order to be selectable from the aforementioned list. Use Query Groups in order to establish monitoring and/or restrict the use of certain queries such as GRANT statements.

9. Queries aimed at privilege manipulations

You can use the Query Groups feature in order to create sets of SQL queries that have to be identified in the database traffic and then audited and/or blocked. However, the better option for monitoring GRANT queries is to use Audit/Security Rules configured as Query Type with the corresponding query types specified. This enables you to establish a complete control over query types of interest through monitoring and restricting execution of chosen categories of queries. Consider combining Query Groups and Query Type Rules in order to achieve the desired level of control over database activity.

10. Handling SELECT * SQL queries

SELECT * FROM TABLE is not a common query. In many cases such queries may mean that somebody is trying to get as much data as possible in order to download the result set from the database. This may result in a data leak. It is recommended to control such queries by restricting their execution in the database. In order to handle SELECT * queries, use a Security Rule with “Query Includes “SELECT *” Expression” checked. When this option is checked, DataSunrise checks and blocks queries like SELECT * FROM TABLE and SELECT * FROM TABLE WHERE CONDITION=VALUE.

If it is required to execute such queries, narrow the list of allowed users/applications/application users/hosts using the Filter Sessions’ options.

Dynamic Masking Rules

General recommendations

• Couple Audit Rules with Masking Rules in order to provide a full coverage of sensitive data access
• Use the “Filter Session” option of a Masking Rule to avoid triggering the Rule by unwanted users.
• Use the “Application User” filter for the cases when Dynamic Masking Rule is used to obfuscate data accessed by Application Users in complex systems like SAP ECC and Oracle EBS.
• If it is required to mask values included in an entire row, consider using the “Hide Rows” functionality instead of regular Dynamic Masking. Using Hide Rows enables concealment of entire rows that fulfill the requirements of the Masking Rule. Use Filter Sessions to define at what conditions your Hide Rows type Dynamic Masking Rule will be triggered.

Conclusion

This document accumulates the recommendations in the form of Use Cases users can encounter when using Database Security. The provided suggestions and Use Cases are not obligatory but may be used as a reference when creating a custom DataSunrise configuration.

The document covers main tips and recommendations on what types of Rules and what Options to use in order to leverage Database Activity Monitoring, Database Firewall and Data Masking.