Database Security Best Practices
So far, in the year 2017, there has been a vast number of data breaches that have affected an astronomical number of user accounts. A lot of the data exposed in these data breaches came from databases not being secured. From Verizon, 14 million records of customers were exposed when they were left exposed on an Amazon S3 storage server (Wittaker, 2017) to the more recent Equifax data breach, a large number of these data breaches could have been prevented had the companies followed the current best practices on how to secure and harden databases.
Three of the most popular database applications used today are Oracle Database (Oracle), Microsoft SQL, and MySQL each have their ways to be secured against hackers. The first database that will be covered is the Oracle database. One of the first things that a database administrator (DBA) needs to do once the database is installed is to lock down the default accounts. These default accounts have privileged access to defined preset values that are common knowledge to hackers and IT professionals. The DBA can use the Oracle Database Configuration Assistant (DBCA) to automatically lock or expire the default accounts (Stark, 2012). Updating and patching the Oracle DB is the next critical step in securing the database. If the updates are not applied almost immediately the database will be exposed to well-known security vulnerabilities. The next step is the reduce the attack surface by removing all unnecessary privileges from public roles. There are specific functions that exist in Oracle that belong to a role called PUBLIC. PUBLIC roles belong to every account user, and that is where the problem lies. By eliminating services that belong in the PUBLIC roles, DBA can follow the principle of least privilege better by only allowing users the permissions they need to do their jobs. Next, auditing should be enabled to allow Oracle to log SQL commands (Stark, 2012). This is not enabled by default so if a security incident occurs, it will be more difficult to understand what happened. Another good practice involves setting up database triggers that log and audit changes in the database schema. A database schema in Oracle is the logical container for data structures. Examples of schema objects are tables or indexes (Ashdown, 2010). By setting up certain triggers, you can audit logs to find out who logged on and what changes were made to the schema. This can be helpful for when a DBA makes changes that affect the functionality of the databases or when hackers make changes to the DB. Password Management is another practice that should be enabled for all accounts. The same password policies that you would use in Microsoft Active Directory could be applied here. It is important to know that the default accounts do not have password management enabled on them (Stark, 2012). The last best practice for securing Oracle databases is enabling encryption. Oracle database supports the Federal Information Processing Standard (FIPS) encryption algorithm Advanced Encryption Standard (AES). Enabling encryption ensures that the data sent from the database to the user is in the ciphertext and not plaintext (Huey, 2017).
The next major database used is MySQL. One of the first things a DBA wants to do to secure the database server is to update and apply any security patches that are needed. On top of that, the administrator should also update the Anti-virus and Anti-spam software as well as the OS itself that is running on the server. Another consideration is remote access. If remote access is not needed that feature should be disabled. If remote access is needed you should configure the firewall only to allow that specific account and possibly computer to have remote access to the database. To prevent unauthorized reading from local files, the DBA should disable the use of the command LOAD DATA LOCAL INFILE (Maman, 2015). A one-way hacker can exploit this is by using the LOAD DATA LOCAL INFILE to read the /etc/passwd file into another table. This would give the hacker access to all of the user accounts with passwords. A fourth task for the DBA to do is to change the name of the administrator’s account. By default, the account name is root and is well known as a common name for the admin account. If the hacker gains access to the root account, they have access to the entire database. If there are any old, anonymous, or obsolete accounts, those accounts should be removed and deleted. By default, anonymous users accounts can exist without any passwords. If this is left open, it would be easy to exploit. The next thing that the DBA should implement is the principle of least privilege. This reduces the attack surface for each account. As with the Oracle database, the DBA should enable logging so that certain events can be monitored such as error logging. Lastly, the database administrator should ensure that the data is encrypted.
The third major database application is Microsoft SQL. Once the SQL server is installed, the DBA should begin hardening the server. The administrator can use the SQL Server Configuration Manager tool to disable or remove any features or services that are not planned to be used. This tool reduces the attacks surface and makes it less vulnerable to attacks. Windows Authentication mode should be used over the built-in SQL authentication. This is due to how the Windows authentication mode integrates with the Active Directory. If the Windows Authentication mode is used, all of the security policies that are created within Active Directory can apply to the SQL server. Otherwise, if SQL Authentication is used the DBA will have to create separate user accounts and recreate the account infrastructure. This adds to the complexity of maintaining the user accounts so it should not be used. The SA account should be disabled and renamed. This will stop a hacker from searching for this account. Instead, create new administrator accounts and use Role Based Access Controls (RBAC) to prevent anyone account from having access to everything (Ferraiolo Kuhn, 2017). Security by obscurity is not an actual security control. However, it can make the hacker’s job more difficult. So, the DBA should also consider changing the default ports used by the SQL server (Maman, 2015). The administrators should also hide the SQL server instances or disable the SQL Server Browser service.
Securing and hardening the database will go a long way in securing the data that is used on the network but it is not the only thing that needs to be secured. Using the concept of In-depth security the database can be secured even further. There are several organizations that develop a list on how to secure the network. SANS has a Top 20 Critical Security Controls list that is vendor neutral on how to secure computer systems. SANS is a for-profit organization that develops cybersecurity and information security training and offers certifications for those courses. SANS also created the Center for Internet Security where they created the SANS Top 20 Security Controls list.
The SANS Top 20 list is pretty though, and it is designed to be started on control number 1 and followed to control 20. CSC 1 and 2 cover inventorying of all authorized and unauthorized devices and software on the network. Because of the popularity of BYOD devices, it can become difficult for an administrator to know what is happening on their network. If you do not know what is on your network, you can secure it. CSC 3 deals with secure configuration for hardware and software on mobile devices, laptops, workstations, and servers. After you understand what you have on your network, you can use the best-known security practices to harden those devices. CSC 5 is the controlled use of administrative privileges. This is also known as the principle of least privilege and needs to know. By keeping the privileges in check and only giving those privileges to a small number of user accounts you can limit the exposure that the network has to vulnerabilities. CSC 6 is maintenance, monitoring, and analysis of audit logs. This control deals with how to setup and audit logs so that you can detect intrusions or security events if they happen. CSC 7 establishes email and web browser protections. Some of the actions in this control are to reduce the surface area of attacks by disabling or removing any services that you do not use. CSC 8 is malware defenses. Actions in this control are installing Anti-virus software, firewalls, and intrusion detection/ prevention systems. CSC 9 is the limitation and control of network ports, protocols, and services. Port security and management allows the network to turn off any unused ports so that no rouge devices can be installed. Workstations and servers can also be assigned specific ports to use so that if they are moved, they will not have access. CSC 10 deals with data recovery capability. CSC 11 controls the secure configurations for network devices. CSC 12 establishes controls for boundary defense. This is where firewalls are configured, and DMZs are established. CSC 13 deals with data protection. This controls how encryption is used on the network. CSC 14 controls access based on the need to know. CSC 15 covers the use of wireless access points. This is important today because of the use of cell phones and wireless printers. CSC 16 establishes controls for account monitoring. Security policies effective this control. For Microsoft Server, it is easy to control and monitor accounts with Active Directory. CSC 17 sets up security skills assessment and creates training for employees to fill in gaps in training and knowledge. CSC 18 is application software security. The OWASP Top ten list for application security can be used here. CSC 19 established incident response and management. Lastly, CSC 20 covers penetration testing and red team exercises. As the IT security team works their way thru this list, their entire network will be more secure. Not only the databases but the computers, networking devices, and the applications that access the data within the databases.
One of the trends of late has been that hackers have targeted databases. Two reasons that hackers have target databases are that the databases have an enormous amount of data within them. The other reason is that companies often overlook securing the databases because they are concentrating so much on application security and perimeter security. System and database administrators are also sometimes reluctant to make any changes to the database because everything works and they do not want to make changes that could break the functionality. From the Verizon 2010 Data Breach Investigations Report insiders are the cause of 46% of the data breaches. The insiders do this by abusing their privileges (Barnes, n.d.). By using the least privilege principle and continuously monitoring log files a company could prevent a lot of the insider threats. It was also noted in the report that the stolen credentials were the second highest exploit used in the database breaches (Barnes, n.d.). The first was SQL injection attacks. SQL injection attacks have also been on the OWASP top ten list for the past several years. Some other impressive statistics from the Verizon report were that 96% of the breaches in 2009 could have been prevented through the use of simple controls. 79% of organizations that had credit card data breaches in 2009 had failed their last PCI audit (Branes, n.d.).
Today, while we always hear about vulnerabilities like SQL injection, Cross-Site Scripting, and Distributed Denial of Service (DDoS) attacks, etc. It is important to understand that most of those vulnerabilities are external to the databases themselves. The risks that lie in the databases are more straightforward. Poor password policies and practice, missing or unpatched databases, misconfigured databases, and excessive privileges are what the databases are exposed to. Those vulnerabilities are neither complex nor are they difficult to fix. By taking the time before the installation begins to understand the risks and vulnerabilities the IT administrators can implement policies and processes to mitigate those threats before they even begin.
References
Wittaker, Zack. (September 2017). 2017’s biggest hacks, leaks, and data breaches – so far. Retrieved from http://www.zdnet.com/pictures/biggest-hacks-leaks-and-data-breaches-2017/3/
Stark, Chris. (March 2012). Top 10 Oracle Steps to a Secure Oracle Database Server. Retrieved from http://blog.opensecurityresearch.com/2012/03/top-10-oracle-steps-to-secure-oracle.html
Ashdown, Lance. Kyle, Tom. (February 2010). Oracle Database Concepts 11g Release 2 (11.2). Retrieved from http://docs.oracle.com/cd/E29505_01/server.1111/e25789/tablecls.htm#CNCPT111
Huey, Patricia. (April 2017). Configuring Network Data Encryption and Integrity. Retrieved from http://docs.oracle.com/database/122/DBSEG/configuring-network-data-encryption-and-integrity.htm#DBSEG9593
Maman, David. (October 2015). MySQL database – The world’s most popular open source database. Retrieved from http://www.hexatier.com/mysql-database-security-best-practices/
Maman, David. (October 2015). Microsoft SQL Server Database Security Best Practices. Retrieved from http://www.hexatier.com/microsoft-sql-server-database-security-best-practices/
Ferraiolo, David. Kuhn, Rick. (September 2017). Role Based Access Control. Retrieved from https://csrc.nist.gov/projects/role-based-access-control
Barnes, Rob. (n.d.). Database Security and Auditing: Leading Practises. Retrieved from http://www.bhamisaca.com/images/Database_Security_and_Auditing_Best_Practices.pdf