Corporate Security Crown - How to Protect Data at the Database Level
The press again all last year was noisy about database leaks.
While many organizations consider this an inevitable evil, but the reality is that there are many things that businesses can do right now to prevent unauthorized access to their systems and data.
Many data leaks are due to simple misconfiguration errors — database options that inadvertently increase the risk of a breach by reducing the system's security level.
They can be as simple as an inadequate password policy, or as complex as poorly configured encryption on a corporate network.
Good Guidelines for Safety Technical Development ( STIG )
')
It will also be faithful to use a public database with registered holes in the software ( National Checklist Program Repository ).
Data is one of the most valuable assets of a business, and encryption is an important step in ensuring their security.
While many still believe that encryption affects performance, the advent of cloud computing and the latest encryption technology often means that this is no longer the case.
All major database providers provide some form of database encryption, usually referring to this function as something like < Transparent Data Encryption (TDE) data encryption.
This type of encryption helps protect against attacks that attempt to bypass the database access control mechanisms, preventing intruders from accessing and reading your data through the operating system, backups, or an array of data, while protecting the database from these external group attacks.
Do not focus on continuous analysis of which data is confidential - the cost of continuous analysis and re-implementation of encryption is outweighed by the advantage of simply encrypting all application data.
Encryption at the base level allows you to protect the database or backup file from the Mask Show or from theft by direct access. In the early 2000s, unidentified people came to the tax province of Ontario (Canada), gave a guard to the head, and took the server with them.
If an intruder does not have a master key (which must be placed in a safe in another location from the server), then the data is in relative security.
Database encryption alone is not enough. The attackers who have access to the corporate network and the database server can easily make requests to the database and read the data using standard software or the database administrator can install the application directly to the server with the database and merge the data.
Proper database firewall setup means that the database operation is monitored, proactively detecting and even blocking unauthorized access, application bypass, and SQL injection.
When setting up a database firewall, you must define policies that will help you easily identify anomalous activity.
In most cases, database workloads are repetitive — with a well-defined group of application servers and clients using the same consistent set of programs to access the database.
Different database firewall vendors offer their own unique paradigms for policy development, but almost all of them have some way to identify exceptions for normal client activity.
In some cases, such profiling of normal activity may be as detailed as the definition of normal SQL activity for a database, so the database firewall may even block SQL injection attacks.
Regular database auditing is one of the best ways to minimize the risk that your data will be exposed to external threats or unauthorized access.
Organizations do not know what they don’t know, and unless regular audit processes are conducted, it’s impossible to determine where the vulnerabilities are and where confidential data is left unprotected due to improper configuration.
It is especially important if you bought or ordered a product from a third-party organization, which, if it finds a vulnerability, may not be in a hurry to advertise it due to reputational risks.
Remember that the network monitor seems to see only plain text commands that pass through the network and are not encrypted via SSL / TLS for example.
If your database allows direct local connections that are not routed over the network, the database firewall may not see them.
It will be good practice to periodically check the integrity of all created objects in the database and check the creation time of objects.
There are many ways an organization can restrict access to sensitive data without affecting the work of its employees.
Strive to limit your users and administrators to only those privileges that are necessary for their business tasks.
The first step is to determine what data is needed for each business task, and then establish strict rules for accessing specific business data sets.
This is one of the most important tools to help prevent data misuse inside the company.
If your database supports this, use access control mechanisms to separate the responsibilities of the database administrator and the system from managing the data in the database.
At a minimum, you should check access to privileged user data.
Some databases (for example, MSSQL) do not allow to protect the database from a sysadmin.
More brutal solutions work here through the separation of data into parts with the separation of the physical access of the same person to all the physical parts of the database.
Or a cheaper way - access to the database administrator only under the supervision of a specific time frame.
If this is your internal product, then the best way to do this is for the server application to have an Application Role in the database.
A third-party application should not have access to the tables at all!
Read data only through View or Function.
Any data change through the procedure.
View and Function should have only rights to read tables.
Temporary access restrictions - if the operator in the bank works from 8 to 5 - access from this computer to the database should be limited - this could be a trigger on the system table that resets the connection to the database.
Restrictions on the volume of data - if the operator processes 10-20 documents per day - then after 50 the access lock to the database should work - this allows preventing the discharge of all documents.
Sometimes application developers and administrators need a test environment for developing, supporting, and deploying business applications.
In many cases, testing and development require data sets that are equivalent in size and complexity to production, with the result that many organizations clone a production database to create these lower-level environments.
When this happens, the security risk inherent in the production database suddenly increases, since there are now two (or possibly FIVE) copies of the data.
Reduce risk by masking data — by replacing confidential data with artificially generated or encrypted data that does not reveal the true data.
The industrial term for this is static data masking.
If you sell a boxed product - most likely you will request a copy of the database from customers.
In my tenure at RIM, copies of a database of hundreds of organizations, commercial and state, passed through me.
None of the state organizations (the names of some of which I will even say to anyone aloud) have never masked the data.
Some commercial crypto backup, a couple (Walmart and some Japanese security company sent only the desired table) and only one company sent separate fields in a text file.
That is, the problem is really catastrophic.
There is another way to improve system security.
Dynamic data masking is non-destructive, with no changes to the underlying data. For example, in most cases, someone with access to a credit card number should not see the entire number — only the last four digits.
Based on the article: Securing Enterprise Crown Jewels: How to Protect Data at DB Level
While many organizations consider this an inevitable evil, but the reality is that there are many things that businesses can do right now to prevent unauthorized access to their systems and data.
Item number 1. Understanding the settings of the IT system - check the configuration
Many data leaks are due to simple misconfiguration errors — database options that inadvertently increase the risk of a breach by reducing the system's security level.
They can be as simple as an inadequate password policy, or as complex as poorly configured encryption on a corporate network.
Good Guidelines for Safety Technical Development ( STIG )
')
It will also be faithful to use a public database with registered holes in the software ( National Checklist Program Repository ).
Item number 2. Crypt all your data
Data is one of the most valuable assets of a business, and encryption is an important step in ensuring their security.
While many still believe that encryption affects performance, the advent of cloud computing and the latest encryption technology often means that this is no longer the case.
All major database providers provide some form of database encryption, usually referring to this function as something like < Transparent Data Encryption (TDE) data encryption.
This type of encryption helps protect against attacks that attempt to bypass the database access control mechanisms, preventing intruders from accessing and reading your data through the operating system, backups, or an array of data, while protecting the database from these external group attacks.
Do not focus on continuous analysis of which data is confidential - the cost of continuous analysis and re-implementation of encryption is outweighed by the advantage of simply encrypting all application data.
Encryption at the base level allows you to protect the database or backup file from the Mask Show or from theft by direct access. In the early 2000s, unidentified people came to the tax province of Ontario (Canada), gave a guard to the head, and took the server with them.
If an intruder does not have a master key (which must be placed in a safe in another location from the server), then the data is in relative security.
Item No. 3. Use SQL Database Firewall
Database encryption alone is not enough. The attackers who have access to the corporate network and the database server can easily make requests to the database and read the data using standard software or the database administrator can install the application directly to the server with the database and merge the data.
Proper database firewall setup means that the database operation is monitored, proactively detecting and even blocking unauthorized access, application bypass, and SQL injection.
When setting up a database firewall, you must define policies that will help you easily identify anomalous activity.
In most cases, database workloads are repetitive — with a well-defined group of application servers and clients using the same consistent set of programs to access the database.
Different database firewall vendors offer their own unique paradigms for policy development, but almost all of them have some way to identify exceptions for normal client activity.
In some cases, such profiling of normal activity may be as detailed as the definition of normal SQL activity for a database, so the database firewall may even block SQL injection attacks.
Item number 4. Monitor everything - check your database
Regular database auditing is one of the best ways to minimize the risk that your data will be exposed to external threats or unauthorized access.
Organizations do not know what they don’t know, and unless regular audit processes are conducted, it’s impossible to determine where the vulnerabilities are and where confidential data is left unprotected due to improper configuration.
It is especially important if you bought or ordered a product from a third-party organization, which, if it finds a vulnerability, may not be in a hurry to advertise it due to reputational risks.
Remember that the network monitor seems to see only plain text commands that pass through the network and are not encrypted via SSL / TLS for example.
If your database allows direct local connections that are not routed over the network, the database firewall may not see them.
It will be good practice to periodically check the integrity of all created objects in the database and check the creation time of objects.
Item number 5. Limit the zone of visibility - set access rules
There are many ways an organization can restrict access to sensitive data without affecting the work of its employees.
Strive to limit your users and administrators to only those privileges that are necessary for their business tasks.
The first step is to determine what data is needed for each business task, and then establish strict rules for accessing specific business data sets.
This is one of the most important tools to help prevent data misuse inside the company.
If your database supports this, use access control mechanisms to separate the responsibilities of the database administrator and the system from managing the data in the database.
At a minimum, you should check access to privileged user data.
Some databases (for example, MSSQL) do not allow to protect the database from a sysadmin.
More brutal solutions work here through the separation of data into parts with the separation of the physical access of the same person to all the physical parts of the database.
Or a cheaper way - access to the database administrator only under the supervision of a specific time frame.
If this is your internal product, then the best way to do this is for the server application to have an Application Role in the database.
A third-party application should not have access to the tables at all!
Read data only through View or Function.
Any data change through the procedure.
View and Function should have only rights to read tables.
Temporary access restrictions - if the operator in the bank works from 8 to 5 - access from this computer to the database should be limited - this could be a trigger on the system table that resets the connection to the database.
Restrictions on the volume of data - if the operator processes 10-20 documents per day - then after 50 the access lock to the database should work - this allows preventing the discharge of all documents.
Item number 6. Disguise the data, which can reduce the risk from the effects of the attack
Sometimes application developers and administrators need a test environment for developing, supporting, and deploying business applications.
In many cases, testing and development require data sets that are equivalent in size and complexity to production, with the result that many organizations clone a production database to create these lower-level environments.
When this happens, the security risk inherent in the production database suddenly increases, since there are now two (or possibly FIVE) copies of the data.
Reduce risk by masking data — by replacing confidential data with artificially generated or encrypted data that does not reveal the true data.
The industrial term for this is static data masking.
If you sell a boxed product - most likely you will request a copy of the database from customers.
In my tenure at RIM, copies of a database of hundreds of organizations, commercial and state, passed through me.
None of the state organizations (the names of some of which I will even say to anyone aloud) have never masked the data.
Some commercial crypto backup, a couple (Walmart and some Japanese security company sent only the desired table) and only one company sent separate fields in a text file.
That is, the problem is really catastrophic.
There is another way to improve system security.
Dynamic data masking is non-destructive, with no changes to the underlying data. For example, in most cases, someone with access to a credit card number should not see the entire number — only the last four digits.
Based on the article: Securing Enterprise Crown Jewels: How to Protect Data at DB Level
Source: https://habr.com/ru/post/443634/
All Articles