Threats, Vulnerabilities and Risk Assessment

Introduction

Database systems store information that is valuable to organisations, customers, employees, governments and attackers. A database may contain identity records, payment information, health data, intellectual property, credentials, business transactions and audit evidence. The security of a database therefore depends not only on encryption or access controls, but also on recognising what can go wrong, why it can happen and which risks deserve priority.

Database security analysis examines three related elements. A threat is a potential cause of harm, such as a malicious employee, ransomware operator or software defect. A vulnerability is a weakness that can be exploited, such as excessive privileges, an unpatched database server or exposed credentials. Risk is the possibility that a threat will exploit a vulnerability and produce an unwanted consequence.

This chapter introduces practical methods for identifying database assets, analysing insider and external threats, recognising common attack paths, modelling threats and prioritising risk. The emphasis is on professional foundation skills: accurate observation, structured reasoning, evidence-based prioritisation and proportionate controls.

Learning Objectives

After studying this chapter, you should be able to:

• distinguish threats, vulnerabilities, exploits, impacts and risks;
• identify database assets and classify their business value;
• explain insider, external, technical and non-technical threats;
• recognise misconfiguration, malware, data leakage and common attack paths;
• construct a basic threat model for a database environment;
• assess and prioritise risk using qualitative and quantitative methods;
• recommend practical safeguards and communicate findings responsibly.

1. The Database Security Risk Landscape

A database environment is more than a database engine. It normally includes applications, APIs, operating systems, virtual machines or containers, networks, administrators, developers, backup systems, cloud services, monitoring tools and users. An attack may therefore begin outside the database and eventually affect it.

A useful security analysis considers the following objectives:

• Confidentiality: preventing unauthorised disclosure;
• Integrity: preventing unauthorised or inaccurate alteration;
• Availability: ensuring that authorised users can obtain services and data when needed;
• Authenticity and accountability: establishing who or what performed an action and preserving trustworthy evidence.

A single incident may affect several objectives. For example, ransomware can make data unavailable, while a compromised administrator account can alter records and expose confidential information.

Important terminology

A threat actor is an individual, group or process capable of causing harm. An attack is an intentional attempt to compromise security. An exploit is a technique, tool or code that takes advantage of a vulnerability. An exposure is a condition in which an asset is accessible to a threat, even if exploitation has not yet occurred. An incident is a security event that has, or may have, adverse consequences.

Risk analysis should avoid treating every weakness as equally urgent. A low-impact development database with a minor configuration issue may deserve less immediate attention than a production database containing regulated personal data, even when the technical weakness is similar.

2. Assets, Data and Business Context

Risk assessment begins with asset identification. An asset is anything that has value and requires protection. Examples include:

Asset identification should record the owner, location, classification, dependencies, users and recovery requirements. The data owner is normally responsible for deciding how information may be used and how sensitive it is; the system owner is responsible for operating the supporting technology. These roles may be held by different people.

Data classification

A practical classification scheme might use public, internal, confidential and restricted categories. Classification should reflect the consequences of disclosure, alteration or unavailability. For example, a public product catalogue may require integrity and availability controls but little confidentiality protection. A medical database may require strong protection across all three objectives.

Data classification must also account for aggregation. Individual records may appear harmless, but a large collection can reveal identities, behaviour or commercial patterns. Copies in test environments, spreadsheets, exports and backups must receive protection appropriate to the original data unless properly anonymised.

Business impact and criticality

Criticality is determined by business consequences, not simply by technical complexity. Questions include:

1. What business processes depend on the database?
2. How long can the service be unavailable?
3. What harm would inaccurate data cause?
4. Which legal, contractual or regulatory duties apply?
5. Can the organisation restore trustworthy data and prove what happened?

3. Threat Categories

External threats

External actors have no authorised organisational role, although they may obtain valid credentials. Common examples include cybercriminal groups, fraudsters, hacktivists, competitors, data brokers and state-sponsored operators. Their methods include phishing, credential stuffing, exploitation of internet-facing services, supply-chain compromise and social engineering.

External threats often exploit a chain of weaknesses. A public application may accept unsafe input, connect to the database using an overprivileged account and expose detailed error messages. The attacker may never log directly into the database; instead, the application becomes the attack path.

Insider threats

An insider is a person or service with legitimate access. Insider risk is not limited to malicious employees. It includes:

• Malicious insiders, who intentionally steal, alter or destroy data;
• Negligent insiders, who mishandle information, reuse passwords or disable controls;
• Compromised insiders, whose accounts or devices are controlled by an attacker;
• Third-party insiders, such as contractors and support providers.

The most effective response is not to assume that all insiders are untrustworthy. It is to apply least privilege, separation of duties, strong authentication, monitoring, approval processes and timely removal of access.

Technical and environmental threats

Technical threats include software vulnerabilities, insecure interfaces, weak authentication, unencrypted connections, malware and denial-of-service attacks. Environmental threats include power failure, fire, flood, hardware failure and loss of a cloud or network dependency. Risk assessment should include accidental and non-malicious events because availability and integrity can be harmed without an attacker.

4. Vulnerabilities and Common Attack Paths

Misconfiguration

Misconfiguration is one of the most frequent database weaknesses. Examples include:

• database services exposed directly to the public internet;
• default accounts, passwords or sample databases left enabled;
• excessive permissions or shared administrator accounts;
• unrestricted administrative interfaces;
• disabled auditing or logs that are not protected from alteration;
• storage buckets, snapshots or backups configured for public access;
• encryption keys stored beside the data they protect;
• development systems containing production data;
• unpatched database engines, operating systems or extensions;
• insecure network rules and unnecessary open ports.

Misconfiguration is dangerous because it often combines with ordinary credentials or publicly documented tools. A secure product can become insecure through an unsafe deployment.

Software and application vulnerabilities

Applications should use parameterised queries or safe database interfaces rather than constructing commands by concatenating untrusted input. Input validation is useful but should not be the sole defence. Applications should also use separate accounts for separate services, limit returned data, protect error messages and manage sessions securely.

Other weaknesses include insecure deserialisation, vulnerable dependencies, unsafe stored procedures, inadequate authorisation checks and APIs that expose records based only on predictable identifiers. An application may correctly authenticate a user but still fail to verify whether that user is authorised to access a particular record.

Malware and ransomware

Malware can arrive through phishing, compromised software, malicious documents, drive-by downloads or stolen credentials. Database-related consequences include theft of credentials, unauthorised exports, destruction of files, encryption of database storage and disabling of backup systems. Ransomware operators commonly attempt to obtain administrative privileges and delete or encrypt recovery copies before demanding payment.

Protection requires layered controls: endpoint security, patch management, application allow-listing where appropriate, network segmentation, privileged access management, offline or immutable backups, restoration testing and incident response planning.

Data leakage

Data leakage is unauthorised disclosure, whether deliberate or accidental. It may occur through SQL query results, error messages, logs, debug tools, email, removable media, screenshots, cloud sharing links, database exports, backups or test data. Leakage may also occur when a legitimate user accesses more data than required for the task.

Controls include data minimisation, masking and tokenisation, encryption in transit and at rest, access reviews, data loss prevention, export controls and monitoring of unusual queries. Encryption does not prevent leakage after an authorised user or compromised application has decrypted the information.

Common attack path

A representative attack path is:

1. The attacker sends a convincing phishing message.
2. A user supplies credentials to a fraudulent site.
3. The attacker uses the credentials against a remote access service.
4. Weak segmentation permits movement to an application server.
5. The application account has excessive database privileges.
6. The attacker extracts sensitive records and alters or encrypts data.
7. Poor logging and untested backups delay detection and recovery.

This path demonstrates why database security cannot be reduced to a single control. Effective assessment examines the sequence from initial access through privilege escalation, discovery, collection, impact and persistence.

5. Threat Modelling for Database Systems

Threat modelling is a structured process for identifying what can go wrong and selecting controls before or during system operation. It is most useful when performed with system owners, developers, database administrators and security staff.

Model the system

Begin by documenting:

• users and administrators;
• applications, APIs and services;
• database instances, schemas and data stores;
• trust boundaries between networks, accounts or organisations;
• data flows, including exports and backups;
• authentication, authorisation and key-management services.

A data-flow diagram should show where sensitive data enters, is processed, stored, copied and deleted. Each trust boundary should prompt questions about authentication, encryption, validation and logging.

Identify threats

A useful mnemonic is STRIDE:

STRIDE is a discovery aid, not a complete risk assessment. It should be supplemented with business context, privacy analysis, abuse cases and operational experience.

Identify attack paths and controls

For every important threat, ask:

• What asset is targeted?
• What vulnerability enables the action?
• What preconditions must exist?
• Which controls prevent, detect or limit it?
• What evidence would indicate the activity?
• What is the recovery process?

Controls should be mapped to stages of the attack path. Preventive controls reduce the chance of success; detective controls improve discovery; corrective controls reduce duration and impact; compensating controls provide alternative protection when an ideal control is unavailable.

6. Risk Assessment and Prioritisation

Risk assessment normally consists of identification, analysis, evaluation and treatment. The process should be repeatable and documented, while recognising that estimates contain uncertainty.

Qualitative assessment

A common method assigns likelihood and impact ratings such as low, medium and high. A risk matrix can then classify risks for management attention. Ratings must have written definitions. For example, “high likelihood” might mean that the event is expected or that known exploitation is occurring; “high impact” might mean severe legal, financial, safety or operational consequences.

A matrix is useful for communication but can create false precision. A score of 12 is not automatically twice as serious as a score of 6, especially when ordinal categories are multiplied. The organisation should define treatment thresholds and consider uncertainty, dependencies and concentration of risk.

Quantitative assessment

A basic expected-loss model is:

Here, ALE is annualised loss expectancy, SLE is single-loss expectancy, and ARO is annual rate of occurrence. SLE represents the estimated loss from one event; ARO represents the expected number of such events per year. Monetary values and the time period must be consistent. The model assumes that the estimates are meaningful and that expected losses can reasonably be aggregated.

If an incident would cost £40,000 and is estimated to occur 0.25 times per year, then:

This is an estimate, not a prediction. It may omit reputational harm, regulatory consequences, correlated events and uncertainty. It should support, not replace, professional judgement.

A simple risk-ranking score may be expressed as:

where R is a prioritisation score, L is a defined likelihood rating and I is a defined impact rating. This multiplication is appropriate only when the organisation has clearly defined the scales and accepts the limitations of the resulting score. It is not a universal law of risk.

Risk treatment

Treatment options are:

• Mitigate: reduce likelihood or impact through controls;
• Avoid: discontinue the activity or remove the vulnerable feature;
• Transfer or share: use insurance or contractual arrangements, while recognising that accountability may remain;
• Accept: consciously retain the risk within approved tolerance.

Risk acceptance should be explicit, time-limited where appropriate and approved by an accountable owner. “No action” is not the same as informed acceptance.

7. Worked Assessment Example

Consider an online retail company whose customer database is reachable by an application server. A review finds that the application account can read and modify every customer table, although the application needs only selected columns and procedures. Database backups are copied to cloud storage, and access logging is incomplete.

Asset: customer identity and order data.

Threat: external attacker compromises the application through a web vulnerability or stolen application credentials.

Vulnerability: excessive database privileges and weak monitoring.

Impact: unauthorised disclosure or alteration of customer records, regulatory investigation and service disruption.

Likelihood: medium to high because the application is internet-facing and the privilege weakness is directly usable after compromise.

Priority: high because confidentiality and integrity impacts are significant and the attack path is plausible.

Treatment plan: replace broad table privileges with restricted stored procedures or narrowly scoped permissions; rotate application credentials; segment database access; enable protected audit logging; alert on bulk exports and unusual administrative actions; review backup permissions; test restoration; and patch the application vulnerability.

The most important lesson is that the assessment does not stop at “the database is behind a firewall.” The application account and data flows must also be examined.

8. Illustrative Case Study: The Exposed Reporting Database

Background

This fictional case concerns Northbridge Services, a medium-sized organisation operating a customer support platform. It created a reporting database to allow analysts to develop dashboards. To accelerate testing, a copy of production data was placed in a cloud environment.

Problem

The reporting server was exposed through a permissive network rule. A shared administrator password was used by analysts and had not been changed after a contractor left. Database logs were retained for only three days, and the cloud backup was accessible using the same credentials.

Analysis

The assets included customer contact details, support histories and internal performance information. Threats included external scanning, a former contractor misusing credentials and malware on an analyst workstation. The key attack path was: exposed service → password attack or credential reuse → administrator access → data export → deletion or alteration of logs and backups.

The risk was high because several weaknesses reinforced one another. The reporting copy also violated the principle that non-production environments should not automatically contain identifiable production data.

Approach and solution

The organisation removed public exposure, implemented network allow-lists and individual accounts, enforced multi-factor authentication for administrative access and rotated all credentials. Production data was replaced with masked test data. Privileges were reduced according to job requirements, cloud backup access was separated from database administration, and logs were sent to a protected central system. Restoration exercises and quarterly access reviews were introduced.

Outcome

The organisation reduced the likelihood of direct compromise and improved its ability to detect and recover from incidents. It also discovered that access reviews, backup permissions and data classification were governance responsibilities rather than purely technical tasks.

Learning points

1. Copies, exports and backups are assets in their own right.
2. Shared accounts weaken accountability and make investigation difficult.
3. Defence in depth is essential because one failed control should not expose the entire dataset.
4. Risk treatment should address both technical weaknesses and organisational practices.

9. Governance, Ethics and Regulation

Database risk assessment involves ethical responsibilities. Analysts should collect only the evidence needed, protect test data, avoid unnecessary exposure of personal information and report weaknesses through authorised channels. Security testing must have written permission, defined scope and safe procedures. Exploiting a weakness beyond the approved scope can cause harm and may be unlawful.

Privacy principles commonly require purpose limitation, data minimisation, accuracy, retention control and appropriate security. Exact legal obligations depend on jurisdiction and sector, but organisations should identify applicable privacy, financial, health, education and contractual requirements. A risk register should record compliance implications without assuming that compliance alone proves security.

Governance should define ownership, escalation routes, risk appetite, review frequency and exception management. Senior management must understand material risks and resource their treatment. Technical teams should provide evidence and clear residual-risk statements rather than presenting unsupported assurances.

10. Contemporary Developments and Professional Practice

Cloud databases, managed services, containers and serverless applications change the location of responsibility but do not eliminate it. Providers may secure the underlying infrastructure while the customer remains responsible for identities, data, configuration, network policy and application security. This shared-responsibility distinction must be documented.

Artificial intelligence can assist with anomaly detection, log analysis, asset discovery and prioritisation. However, AI-generated conclusions may contain false positives, miss novel behaviour or expose sensitive logs to an unauthorised service. Human review, data minimisation, model governance and explainable evidence remain necessary.

Effective professional practice includes:

• maintaining an accurate asset inventory;
• applying secure configuration baselines;
• patching according to exploitability and business impact;
• enforcing least privilege and separation of duties;
• using individual identities and strong authentication;
• encrypting sensitive data and protecting keys separately;
• monitoring privileged activity, exports and anomalous access;
• testing backups and incident response procedures;
• reviewing third-party and cloud access;
• reassessing risk after major system or business changes.

Challenges and Limitations

Risk assessment is affected by incomplete inventories, uncertain threat intelligence, changing business processes and inaccurate impact estimates. A system may appear secure during an assessment but become exposed after a new API, cloud rule or contractor is introduced. Quantitative estimates can encourage unjustified confidence, while qualitative ratings can hide disagreement behind a single label.

Threat models also have boundaries. They may omit human behaviour, physical access, supply-chain compromise or dependencies outside the documented system. Therefore, assessments should be reviewed by people with different perspectives and validated through configuration review, vulnerability assessment, penetration testing, access review and recovery exercises where appropriate.

Chapter Summary

Database security risk assessment begins by identifying valuable data, services, credentials, configurations, backups and evidence. Threats may originate externally, internally, accidentally or through compromised legitimate accounts. Vulnerabilities include misconfiguration, excessive privileges, weak authentication, insecure applications, unprotected backups and inadequate monitoring. Common attack paths combine several weaknesses, so analysis must consider the complete sequence from initial access to impact and recovery.

Threat modelling provides a structured way to examine data flows, trust boundaries and threats such as spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. Risk can be assessed qualitatively through defined likelihood and impact scales or estimated quantitatively using models such as ALE = SLE × ARO. Results should guide mitigation, avoidance, transfer or informed acceptance. Good practice combines technical safeguards with governance, ethical testing, privacy protection, access reviews, logging, backup restoration and continuous reassessment.

Key Terms

Threat: A potential cause of harm to an asset.

Vulnerability: A weakness that can be exploited or otherwise lead to harm.

Risk: The possibility of adverse impact arising from a threat and vulnerability.

Asset: Something valuable that requires protection.

Threat actor: A person, group or process capable of causing harm.

Exploit: A technique or code that takes advantage of a vulnerability.

Insider threat: Risk arising from a person or service with legitimate access.

Misconfiguration: An insecure or inappropriate technical setting.

Data leakage: Unauthorised disclosure of information.

Least privilege: Giving an identity only the access required for its duties.

Attack path: A sequence of actions and conditions leading to compromise.

Threat modelling: Structured analysis of threats, assets, trust boundaries and controls.

STRIDE: A threat-model classification covering spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.

Likelihood: An estimate of how probable an event is within a defined context.

Impact: The consequence if a risk event occurs.

Risk appetite: The level and type of risk an organisation is willing to retain.

Residual risk: Risk remaining after controls are applied.

SLE: Single-loss expectancy, the estimated loss from one event.

ARO: Annual rate of occurrence, the expected number of events per year.

ALE: Annualised loss expectancy, calculated in the basic model as SLE multiplied by ARO.

Review Questions

Short Answer Questions

1. Distinguish between a threat, a vulnerability and an exploit.
2. Why should backups and test databases be treated as assets?
3. Identify two examples of insider threat that are not deliberate theft.
4. What does least privilege mean in a database environment?
5. State the purpose of a trust boundary in threat modelling.

Long Answer Questions

1. Explain how misconfiguration can create a database attack path, using at least three examples.
2. Describe the STRIDE framework and apply each category to a database system.
3. Compare qualitative and quantitative risk assessment, including their limitations.
4. Explain how an organisation should protect a database against ransomware.
5. Discuss the governance and ethical responsibilities involved in database security testing.

Analytical / Application Questions

1. A reporting application requires access to two customer attributes but has read and write access to every table. Analyse the risks and propose a prioritised treatment plan.
2. Construct a basic attack path for an internet-facing database application and identify one preventive, one detective and one corrective control for the path.
3. An incident has an estimated single-loss expectancy of £60,000 and an annual rate of occurrence of 0.1. Calculate the ALE and explain why management should not treat the result as a guaranteed forecast.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a vulnerability from a threat?

A. A vulnerability is a weakness; a threat is a potential cause of harm.

B. A vulnerability is always an attack; a threat is always a control.

C. A vulnerability is the business impact; a threat is the database asset.

D. A vulnerability is a backup; a threat is an audit record.

Correct Answer: A. A vulnerability is a weakness; a threat is a potential cause of harm.

Question 2

Which is an example of excessive database privilege?

A. A reporting account can execute only approved read-only procedures.

B. An application account can modify every production table although it needs only selected data.

C. An administrator uses multi-factor authentication.

D. A backup key is stored separately from the backup data.

Correct Answer: B. An application account can modify every production table although it needs only selected data.

Question 3

In STRIDE, unauthorised alteration of a financial transaction is primarily an example of:

A. Spoofing

B. Tampering

C. Repudiation

D. Denial of service

Correct Answer: B. Tampering

Question 4

Which item is most likely to be a data-leakage source?

A. A properly restricted database view

B. A masked test dataset

C. A publicly accessible production backup

D. A protected central audit log

Correct Answer: C. A publicly accessible production backup

Question 5

A database incident has an SLE of £40,000 and an ARO of 0.25. What is the ALE?

A. £1,000

B. £10,000

C. £40,250

D. £160,000

Correct Answer: B. £10,000

Question 6

Which control most directly improves accountability for database actions?

A. Shared administrator credentials

B. Individual accounts with protected audit logging

C. Disabling database logs

D. Using the same password for production and testing

Correct Answer: B. Individual accounts with protected audit logging

Question 7

Why is a production copy in a development environment risky?

A. Development systems never require authentication.

B. Copies may contain sensitive data and often have weaker controls.

C. Production data automatically becomes public when copied.

D. Development databases cannot be encrypted.

Correct Answer: B. Copies may contain sensitive data and often have weaker controls.

Question 8

What is the primary purpose of threat modelling?

A. To guarantee that no incident can occur

B. To identify threats, attack paths and suitable controls systematically

C. To replace all vulnerability testing

D. To calculate the exact financial cost of every incident

Correct Answer: B. To identify threats, attack paths and suitable controls systematically

Question 9

Which is a corrective control against ransomware impact?

A. Tested offline or immutable backups

B. A shared password

C. An unrestricted public database port

D. Disabling alerts for bulk exports

Correct Answer: A. Tested offline or immutable backups

Question 10

Which risk treatment means deliberately retaining a risk with appropriate approval?

A. Avoidance

B. Mitigation

C. Acceptance

D. Erasure

Correct Answer: C. Acceptance