Chapter 4: Manage database security

4.1 Database security risks identification

A database security risk is any event or weakness that could expose, change or destroy stored data, or make it unavailable to the people who need it. Security is judged against three goals: confidentiality (only the right people see the data), integrity (the data is accurate and changed only by authorised people) and availability (the data can be used when needed). Identifying risks means finding where these goals can fail before an attacker or an accident does it. Example: a booking database for a safari lodge holds guest names, phone numbers and passport details, so a leak harms confidentiality, a changed booking harms integrity and a deleted table harms availability.

4.1.1 Common security risks

The risks below appear again and again in databases of every size. Some come from outside attackers, some from careless or dishonest insiders and some from neglect, such as old software. Learning to recognise each one is the first step in choosing the controls that stop it, which are taught later in this chapter. A single incident often combines several, for example stolen credentials (weak authentication) used by a stranger (unauthorised access) to copy customer records (data leakage).

4.1.1.1 Unauthorised Access

Unauthorised access means reaching a database, or data inside it, without permission. The person may be an outside attacker, a former employee or a staff member looking at records that are not part of their job. In Kenya the Computer Misuse and Cybercrimes Act, 2018 makes it an offence to access a computer system intentionally, knowing that the access is unauthorised. Example: a courier firm's tracking database is reachable from the internet, and a stranger finds it by scanning for open database ports.

• Exposed network ports: a database server open to the whole internet on its default port (3306 for MySQL, 5432 for PostgreSQL, 1433 for SQL Server, 27017 for MongoDB) is found quickly by automated scanners.
• Default accounts: accounts that ship with the product, sometimes with an empty or well-known password, give instant access if they are left active.
• Stolen or guessed credentials: passwords taken through phishing, reused from another site or guessed by software give an attacker a legitimate login.
• Bypassing the application: an attacker who has the database password can connect with a client tool and skip every rule that the application enforces.
• Stolen media and backups: a lost laptop, an unprotected backup file or an old hard disk gives access without any login.
• Physical access: a person in the server room can copy data files or restart the server in a way that avoids its protections.

4.1.1.2 SQL Injection Attacks

SQL injection is an attack in which a user types SQL code into a normal input field, such as a login box or a search box, and the application runs that code as part of its own query. It happens when the program builds SQL text by joining the user's input to a query string. OWASP's list of top web application risks includes injection. Example: a lodge's staff login page builds this query from what the user types:

SELECT * FROM staff WHERE username = '<typed username>' AND pin = '<typed pin>';

If the attacker types admin' -- in the username box and anything in the PIN box, the database receives:

SELECT * FROM staff WHERE username = 'admin' -- ' AND pin = 'anything';

The two hyphens followed by a space start a comment in SQL, so the check on the PIN is ignored and the attacker is logged in as admin. Typing ' OR '1'='1 in a search box that builds WHERE name = '...' makes the condition true for every row, so the whole table is returned. Where the database driver allows several statements in one call, typing '; DROP TABLE staff; -- deletes the table.

• Error-based injection: the attacker reads database error messages that the application displays, which reveal table and column names.
• Union-based injection: the attacker adds a UNION SELECT clause to join extra data, such as a user table, to the normal results.
• Blind injection: the page shows no data, so the attacker asks true or false questions and watches whether the page changes or is slow to respond.
• Stored (second-order) injection: malicious input is saved in the database first and runs later when another query uses it.
• Impact: data theft, data change, deletion, bypassing login and, on poorly configured servers, running commands on the server.

4.1.1.3 Data Leakage

Data leakage is the exposure of data to people who should not see it, whether or not anyone attacked the system. It is often accidental: a file placed in the wrong folder, a setting left open or a report sent to the wrong person. In Kenya the Data Protection Act, 2019 gives personal data legal protection. Where personal data has been accessed or acquired by an unauthorised person and there is a real risk of harm to the people concerned, the data controller must notify the Data Commissioner within 72 hours of becoming aware of the breach. Example: a developer exports the customer table of an online shoe shop to a spreadsheet for testing and uploads it to a shared online folder that anyone with the link can open.

• Unprotected backups: database dumps stored in a public cloud folder or on a shared drive without a password are an easy way for data to leak.
• Test and development copies: real customer data copied into a test database is usually less protected than the live one.
• Detailed error messages: error pages that print queries, table names or file paths help an attacker and may show personal data.
• Logs holding sensitive data: application logs that record full queries or personal details spread the data to everyone who can read the logs.
• Careless sharing: exports sent by email or messaging apps, or copied to personal flash disks, leave the organisation's control.
• Excess data in results: an application that returns every column of a record to the screen, when only two are needed, lets the extra data leak through the browser.

4.1.1.4 Insider Threats

An insider threat comes from a person who already has legitimate access: an employee, a contractor or a partner. Insiders are hard to detect because their activity looks normal. Threats fall into three groups: malicious insiders who steal or damage data on purpose, careless insiders who make mistakes, and insiders whose accounts have been taken over by an outsider. Example: a developer at a software studio keeps working database credentials after leaving the company and later copies the client list.

• Data theft for gain: a staff member copies customer lists or payment records to sell or to take to a competitor.
• Sabotage: an unhappy employee deletes tables, changes records or locks others out.
• Curiosity and misuse: staff look up records of friends, relatives or well-known people without a work reason.
• Mistakes: an administrator runs a delete command on the live database instead of the test one.
• Former staff: accounts that are not removed when someone leaves, or when their duties change, give continued access.
• Excess privileges: people with more rights than their job needs can do more damage, deliberately or by accident.

4.1.1.5 Weak Authentication and Access Control

Authentication proves who a user is, and access control decides what that user may do. If either is weak, the other protections do little. Weak authentication includes poor passwords and no second factor. Weak access control includes accounts with too many rights. Example: a hardware shop's stock application connects to its database using an administrator account, so one flaw in the application gives an attacker full control of the database.

• Weak passwords: short, common or guessable passwords fall to guessing programs within minutes.
• Default and shared passwords: one login used by several people means no one can be held responsible for an action.
• No multi-factor authentication: a stolen password is enough to log in, because nothing else is checked.
• No lockout or alerts: an attacker can try thousands of passwords because repeated failures are neither blocked nor reported.
• Over-privileged accounts: granting all rights to every user, or letting the application log in as an administrator, makes every mistake or attack more serious.
• No role separation: the same person can both change data and approve the change, so there is no check.
• Passwords stored in plain text: if the user table is stolen, every password is exposed at once.

4.1.1.6 Inadequate Patching

A patch is a fix released by the software maker to remove a weakness or a bug. Inadequate patching means installing fixes late or not at all. When a vulnerability becomes public, attackers write tools to exploit it and scan the internet for servers that still have it, so an unpatched database is an easy target. Example: a car-hire company runs its booking database on a version of the DBMS that the maker no longer supports, so newly found flaws are never fixed.

• Known vulnerabilities: each publicly listed flaw has a reference number (a CVE) and a severity score, and attackers read these lists too.
• Unsupported versions: software that has reached the end of its support period gets no more security fixes, however serious the new flaws.
• Delayed updates: a gap of weeks or months between the release of a fix and its installation gives attackers time to act.
• Forgotten components: drivers, operating system packages, web servers and programming libraries around the database also need patches.
• No inventory: a team that does not know what versions it runs cannot tell which servers are affected by a newly announced flaw.
• Untested emergency patches: fear of breaking the system leads to postponement, so patches need a test copy to try them on first.

4.1.1.7 Malware

Malware is malicious software designed to damage, steal or lock data. It reaches a database server through email attachments, infected downloads, fake software updates, infected flash disks or weak points in the network. Example: a garage's job-card database server is used by staff to browse the web, and one of them downloads a fake tool that installs ransomware.

• Ransomware: it encrypts database files and often the backups it can reach, then demands payment for the key. Backups kept offline or out of reach give a strong defence.
• Trojans and backdoors: they pretend to be useful programs and give an attacker remote access to the server.
• Keyloggers and spyware: they record what an administrator types, including database passwords, and send it to the attacker.
• Worms: they spread through the network on their own, from one infected machine to others, including database servers.
• Infected development tools: a compromised programming library or plug-in that a developer installs can send data out of the database.
• Cryptominers: they use the server's processing power for the attacker's gain, slowing the database.