Breaches in database security have become rather commonplace in the news: that’s millions upon millions of credit card numbers, personal data and other forms of confidential information falling into the wrong hands month after month.
The victims of such breaches are not small organizations; we’ve seen big corporations with hundreds of employees in IT falling prey to data hackers. No one is completely safe, as it appears.
According to research by the Ponemon Institute, each breached record costs $188 from the company. You can Google the number of companies that have had to declare themselves bankrupt following a data breach. This brings us to the most important question of the day: what role do database administrators play in ensuring database security?
Many organizations may think information security falls solely in the docket of the network administrators: they are, after all, the people who deploy firewalls and other security tools for the protection of company information assets. However, DBAs are the first line of defense in securing organizational information, and we’ll learn why and how in the following paragraphs.
Shocking statistics about database vulnerabilities
No matter how mature and advanced a database technology is, there is a part to be played by the individuals in charge of database access. Take SQL Servers, which have been on the market for over two decades, and have been subject to SQL injection risks in about as long a time. Now, while SQL Server technology has grown in leaps and bounds, securing the database against injection risks hasn’t followed a similar path. Consider this:
- According to IBM, there were about 1,500 SQL injection attacks monthly in 2015
- In 2007, SQL injection was listed among the top vulnerabilities for web-based applications
- SQL injection was listed as the top cyber attack method by OWASP in 2013
SQL injection remains a risk despite advancing server technologies because the perpetrators are also evolving: you’ve probably heard about inference, blind and compounded SQL injections, and how cybercriminals apply them alongside DNS and XSS hijacking.
Therefore, recognizing that no database is innately secure, every organization must be proactive in finding out how the DBA is managing your information asset security procedures. This must be backed up with adequate resource allocation towards the necessary manpower and infrastructure deployments, of course.
For database administrators, security within an organization starts and ends with a few simple but critical steps, which are listed as follows:
The role of the DBA in security enforcement
Enforcement of database authorization protocols demands elevated privileges and technical expertise in the enforcer, that is, the DBA. Database security encompasses many different system procedures, commands and utilities that must be implemented for the desired effect. In the organization, you have users that need to access multiple databases housed on multiple servers, which may sometimes be located in separate physical centers. This is complicated database security for the DBA, who must institute commands to be repeated to every single database. In addition, in the absence of a single centralized data repository, the DBA must manually take charge of adding, deleting or modifying users’ security configurations within the multiple databases.
At the highest level, database security comes down to establishing the following:
- Who accesses the database (authentication)?
- Who can do what to the database (authorization)?
- Who can see what in the database (encryption and decryption)?
- Who did what to the database (audit)?
Database authentication
Strong authentication protocols are at the heart of any database security deployment. It is impossible to track usage and control authorization without the basis of strong authentication. Before authorization can be given to access and use database resources, each user of the database management system (DBMS) must be assigned a login that establishes their identity. The login ID should have an associated password, which means that only the one(s) who know(s) the password will use that ID. There are DBMSs that use their operating system’s login ID and password as the same applicable for database login, while others require that a specific login ID and password be created for database security and access.
The type of login ID notwithstanding, user passwords must be changed regularly to stop surreptitious access to the DBMS by external parties. When the DBMS user no longer needs to access the database (e.g. when they leave or move to a different department, their login should be immediately deactivated). This, however, can be complicated for certain cases. For instance, there are systems that prevent deactivation of logins belonging to users that own any database objects. It is therefore recommended that only DBAs should be allowed to create database objects, particularly within production environments.
Database authorization
Authorization within the database system is managed through the GRANT and REVOKE statements controlling the users who have access to specific commands and objects. Privileges may be granted or revoked from logins to enable users to access system commands, database objects, programs, data, etc. Instead of granting access to database users individually, authorization controls may be assigned to PUBLIC, so that persons that can log onto a DBMS have authority to carry out the basic tasks. Granting privileges to PUBLIC is however a poor security practice.
Avoiding SQL Injection attacks
SQL injection is a form of web hacking in which SQL statements are specified in a format that exposes data to an attacker. SQL injection attacks can be prevented by using the right coding applications and query language interpreters. In addition, you can use static SQL in place of dynamic SQL, enforce suitable limits to control buffer overrunning, properly testing and validating user input and preventing concatenation of user input into SQL.
Other security practices
- Implement label-based access control, which provides more granular security settings to specify the users that can read and/or edit individual rows, columns or tables of data
- Using roles and groups to manage authorization in a complicated user setting, rather than setting one-by-one
- Implementing views that omit sensitive but non-essential rows or columns of data for specific users
- Coded stored procedures to configure access to row- or column-level data subsets
- Encryption of data at rest or in transit including backup storage, allowing only those with the decryption key to be able to read the data
Lastly, database auditing requirements should be planned for and executed on schedule. This allows tracking of use of database privileges and resources, so that any unauthorized access can be noted and rectified before trouble ensues.
Sujain Thomas is a data IT professional who in addition to rendering DBA expert services runs a blog that is dedicated to sharing top quality open source resources for web designers and web developers.
Read More: Scaling your social media database for optimal performance
