Database security

Introduction

All systems have ASSETS and security is about protecting assets. The first thing, then, is to know your assets and their value. In this chapter, concentrate on database objects (tables, views, rows), access to them, and the overall system that manages them. Note that not all data is sensitive, so not all requires great effort at protection. All assets are under threat.

The second thing to know is what THREATs are putting your assets at risk. These include things such as power failure and employee fraud. Note that threats are partly hypothetical, always changing and always imperfectly known. Security activity is directed at protecting the system from perceived threats.

If a threat is potential, you must allow for it to become an actuality. When it becomes actual there is an IMPACT. Impact you can consider and plan for. But in the worst case, there will be a LOSS. Security activity here is directed at minimizing the loss and recovering the database to minimize the loss as well as further protecting from the same or similar threats.

An outlined development mechanism is:

1. Document assets (what they are, what their value is).

2. Identify treats (what they are, how likely they are, what the impact is if they occur).

3. Associate threats with each asset.

4. Design mechanisms to protect each asset appropriate to its value and the cost of its protection, to detect a security breach against each asset, to minimize the losses incurred and to recover normal operation.

Threats to the database

You will build your security skills from two directions. One is from the appreciation and awareness of changing threats, and the other from the technical remedies to them. Threats include:

• Unauthorized modification: Changing data values for reasons of sabotage, crime or ignorance which may be enabled by inadequate security mechanisms, or sharing of passwords or password guessing, for example.
• Unauthorized disclosure: When information that should not have been disclosed has been disclosed. A general issue of crucial importance, which can be accidental or deliberate.
• Loss of availability: Sometimes called denial of service. When the database is not available it incurs a loss (otherwise life is better without the system!). So any threat that gives rise to time offline, even to check whether something has occurred, is to be avoided.

The rest of this section is an overview of the categories of specific regulatory threats to database systems.

• Commercial sensitivity: Most financial losses through fraud arise from employees. Access controls provide both protection against criminal acts and evidence of attempts (successful or otherwise) to carry out acts detrimental to the organization, whether fraud, extraction of sensitive data or loss of availability.
• Personal privacy and data protection: Internationally, personal data
  is normally subject to legislative controls. Personal data is data about
  an identifiable individual. Often the individual has to be alive but the
  method of identification is not prescribed. So a postal code for a home
  may in some cases identify an individual, if only one person is living at
  an address with the postal code. Such data needs careful handling and
  control. The issues are too extensive to be discussed here but the implications should be noted. Personal data needs to be identified as such. Controls must exist on the use of that data (which may restrict ad-hoc queries). Audit trails of all access and disclosure of the information need to be retained as evidence.
• Computer misuse: There is also generally legislation on the misuse of
  computers. Misuse includes the violation of access controls and attempts
  to cause damage by changing the database state or introducing worms
  and viruses to interfere with proper operation. These offences are often
  extraditable. So an unauthorized access in Hong Kong using computers
  in France to access databases in Germany which refer to databases in
  America could lead to extradition to France or Germany or the USA.
• Audit requirements: These are operational constraints built around the
  need to know who did what, who tried to do what, and where and when
  everything happened. They involve the detection of events (including
  CONNECT and GRANT transactions), providing evidence for detection,
  assurance as well as either defense or prosecution. There are issues related
  to computer-generated evidence not covered here.

In considerations of logical access to the database, it is easy to lose sight of
the fact that all system access imposes risks. If there is access to operating
system utilities, it becomes possible to access the disk storage directly and
copy or damage the whole database or its components. A full consideration
has to take all such access into account. Most analysts would be looking to
minimize communications (direct, network and telecommunications) and isolate

the system from unnecessary threats. It is also likely that encryption would be
used both on the data and the schema. Encryption is the process of converting
text and data into a form that can only be read by the recipient of that data or
text, who has to know how to convert it back to a clear message.

You will find it easier to consider security and auditing as issues separate from
the main database functions, however they are implemented. Visualize the
security server and audit servers as separate functional modules.

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.

Implementing database security

In this topic we cover useful database security implements that can help keep your databases safe from attackers:

• Ensure Physical Database Security

In the traditional sense this means keeping your database server in a secure, locked environment with access controls in place to keep unauthorized people out. But it also means keeping the database on a separate physical machine, removed from the machines running application or web servers.

A web server is more likely to be attacked since it is located in a DMZ and therefore publicly accessible. And if a web server is compromised and the database server runs on the same machine, the attacker would have access as a root user to your database and data.

• Use Web Application and Database Firewalls

Your database server should be protected from database security threats by a firewall, which denies access to traffic by default. The only traffic allowed through should come from specific application or web servers that need to access the data. The firewall should also protect your database from initiating outbound connections unless there is a specific need to do so.

In addition to protecting the database with a firewall, you should also deploy a web application firewall. That’s because attacks such as SQL injection attacks directed at a web application can be used to exfiltrate or delete data from the database. A database firewall won’t necessarily prevent this from happening if the SQL injection attack comes from an application which is an allowed source of traffic, but a web application firewall may.

• Harden Your Database to Fullest Extent Possible

Clearly it’s important to ensure that the database you are using is still supported by the vendor or open source project responsible for it, and that you are running the most up-to-date version of the database software with all database security patches installed to remove known vulnerabilities.

But that’s not sufficient. It’s also important to uninstall or disable any features or services that you don’t need to use, and ensure that you change the passwords of any default accounts from their default values — or better still, delete any default accounts that you don’t need.

Finally, ensure that all database security controls provided by the database are enabled (most are enabled by default) unless there is a specific reason for any to be disabled.

Once you have done all this, you should audit the hardened configuration — using an automated change auditing tool if necessary — to ensure that you are immediately aware if a change to the hardened configuration is made that compromises your database security.

• Encrypt Your Data

It is standard procedure in many organizations to encrypt stored data, but it’s important to ensure that backup data is also encrypted and stored separately from the decryption keys. (Not, for example, stored in encrypted form but alongside the keys in plaintext.) As well as encrypting data at rest, it’s also important to ensure confidential data is encrypted in motion over your network to protect against database security threats.

• Minimize Value of Your Database

Attackers can only get their hands on what is stored in a database, so ensure that you are not storing any confidential information that doesn’t need to be there. Actively manage the data so you can delete any information that you don’t need from the database. Data that must be retained for compliance or other purposes can be moved to more secure storage — perhaps offline — which is less susceptible to database security threats.

In a similar vein, ensure you delete any history files (such as the MySQL history file ~/.mysql_history) that are written by a server during the original install procedure. While these files are useful to analyze if the install fails, if installation is successful they have no value to you but can contain information which is valuable to attackers.

• Manage Database Access Tightly

You should aim for the least number of people possible to have access to the database. Administrators should have only the bare minimum privileges they need to do their job, and only during periods while they need access. For smaller organizations this may not be practical, but at the very least permissions should be managed using groups or roles rather than granted directly.

If yours is a larger organization, you should consider automating access management using access management software. This can provide authorized users with a temporary password with the privileges they require each time they need to access a database. It also logs the activities carried out during that period and prevents administrators from sharing passwords. While admins may find sharing passwords convenient, doing so makes proper database security and accountability almost impossible.

On top of this, it is wise to ensure standard account security procedures are followed:

• Strong passwords should be enforced
• password hashes should be stored encrypted and salted
• Accounts should be locked after three or four login attempts
• A procedure should be put in place to ensure that accounts are deactivated when staff leave or move to different roles
• Audit and Monitor Database Activity

This includes monitoring logins (and attempted logins) to the operating system and database and reviewing logs regularly to detect anomalous activity.

Effective monitoring should allow you to spot when an account has been compromised, when an employee is carrying out suspicious activities or when your database is under attack. It should also help you determine if users are sharing accounts, and alert you if accounts are created without your permission (for example, by a hacker).

Database activity monitoring (DAM) software can help with this by providing monitoring which is independent of native database logging and audit functions; it can also help monitor administrator activity.

Thanks for reading

“Self-education is lifelong curiosity.”

— Abdullah M.R.M

follow me on:

linked in : www.linkedin.com/in/abdullah-ramees-886a5b1a9

twitter : https://twitter.com/Abdullah_BScSE