Two of the biggest database vulnerabilities are buffer overflows and SQL injection and both of these, despite being well-known, have been subject to exploitation by hackers for more than 10 years, the most common attack vectors for a hacker to compromise a database system.
Hackers will also get into a database by using default login credentials and all of this is happening while IT systems administrators continue to complain about the rising costs of user account provisioning.
Lastly, through disclosure of public breaches, we can see the sheer number of unencrypted tapes that are lost or how much secure data is shifted to an insecure storage place.
It is clear that basic database security steps are being missed out and that is where risk assessments and security methodology should be put to good use.
The following methodology, followed in order, will ensure a top level of database security across the entire enterprise:
- Authorization steps and access control – while you may think you already have these in place, this is not a step you can afford to skip. Access control does not equate to secure databases. Domain and database authentication are two very different things and a great deal of care is required to ensure that both systems have coordinated access and users cannot bypass the database authorization.
This is the absolute first defense of your data and database security and requires a very close inspection to ensure that accounts are configured with the correct access and both systems are deployed correctly.
- Default user passwords – this is the single biggest failure of all enterprise systems. As soon as a database is installed, it is imperative that the default login credentials are changed. This must be verified regularly in case the defaults have reverted because of an account reset or reinstallation
- Unused user accounts – those not being used must be locked or if you know for certain that they are never going to be used again, they should be removed altogether. This is all the more important in the case of demo user accounts, tutorial accounts, and canned database testing accounts. These accounts are packaged with databases and are known to be exploitable
- Stronger password – this should be enforced especially in the case of domain level access for database authorization control. Passwords should be rotated and never static
- Public accounts – should be removed, along with public access to any account simply because there should never be any instance where the public should need to have access to any of your databases.
- Domain or database authentication – pick one and stick with it. Do not mix the two together or you risk huge gaps in your security
- Examine roles and groups – list out permissions, roles and participation in groups for every individual user and review it to ensure that users are given only the access they need. This may be a long and boring job but it is essential to the security of your databases.
- Administrative functions – in particular, functions like vendors list functions, stored procedures, roles and admin-dedicated utilities should never be delegated to any user
- Admin duties – these should be divided where databases are concerned. If you have more than one administrator, divide tasks between them, using separate admin accounts. Relational database platforms have access control provisions that allow for the separation of these duties while locking the master DBA account down.
The next major step is in the configuration of the access database and is vital for determining operational integrity and security:
- Find out how each database is configured and compare it to the standard
- Get rid of any services and modules that are not needed
- Document all configuration baselines that have been approved
- Use scanning tools regularly to discover which databases you have and be consistent in your configuration settings
The next step is looking at the interaction between databases and platforms. All databases include the means to call the operating system commands directly for admin tasks and include database and operating system code, offering a bidirectional access portal into the database. The following methods are designed to shut down any security holes that are on this boundary line:
- Disable external or extended stored procedures
- Make sure that the database owner account on the local platform is not given any domain admin functions
- Domain administrators should not be database administrators – keep the two separate
- Startup scripts, utilities for import and export, properties files and registry entries should be tied to the owner credentials of the local database
Next, you need to ensure that all communication with the database is private:
- Sessions between databases and applications must be encrypted, web connections in particular
- Database port numbers should be reset to a non-default value to stop automated attacks and reduces the risks of information probes
- Ad-hoc connections should be blocked through the use of login triggers, access control systems, and database firewalls
Finally, ensure that all databases are patched centrally, using verified and approved copies, on a regular basis. Internet cycles should be synchronized with patch releases from vendors.