SRM IST

School of Computing
Department of Networking and Communications

21CSE485T - DATABASE SECURITY

Dr. SHANMUGANATHAN V
Assistant Professor / NWC
 Course Content
Unit 1
Polyinstantiation, Integrity Lock, Sensitivity Lock, Security Models, Access

Controls (Grant & Revoke), Distributed Database Security, Outsourced Database and

Security Requirements, Query Authentication Dimension, Condensed RSA & Merkle

Tree.

CO1: Identify Fundamentals of Security Issues, Requirements & Authentication

2
 Polyinstantiation

Definition

Polyinstantiation is a database security concept that allows multiple

instances (rows) of the same primary key to exist in a table, each with different

classification levels (e.g., Unclassified, Confidential, Secret). It is used to prevent

inference attacks in multilevel secure (MLS) databases.

3
 Polyinstantiation

Purpose

In environments where users have varying security clearances (e.g.,

military or intelligence systems), polyinstantiation ensures that users can only see

the data they are cleared for, without realizing that higher-classified data even

exists.

4
 Polyinstantiation

Example

Suppose there's a Personnel table:

ID Name Salary Classification

1 Alice 50K Unclassified
1 Alice 80K Secret

A user with "Unclassified“clearance will only see the first row. A user with

"Secret" clearance will see both.

5
 Polyinstantiation

Why It's Needed?

 Inference Control: Prevents lower-level users from inferring the existence of

higher-level data.

 Security: Maintains database consistency while enforcing access controls.

 Data Integrity: Avoids errors that could arise from overwriting or denying

insertions due to access level mismatches.

6
 Polyinstantiation

Challenges

 Data Redundancy: Same keys with different values can confuse application

logic.

 Complexity in Management: Requires careful implementation of access

controls.

 Integrity Constraints: Can complicate enforcement of primary key constraints.

7
 Polyinstantiation

Applications

 Military databases

 Government intelligence systems

 Secure enterprise systems requiring role-based or clearance-level access control

8
 Polyinstantiation

Summary

 For example, two entries may exist for the same user ID one visible to
unclassified users and one to secret-level users without either interfering with
the other. This supports data confidentiality, inference control, and access
restriction based on security clearance.

 While useful for security, it introduces complexity in data management,

application logic, and enforcement of constraints like primary keys.

9
Polyinstantiation

10
Polyinstantiation

11
Polyinstantiation

12
 Integrity Lock
Definition

An Integrity Lock is a security mechanism used in databases to enforce

data integrity and access control by binding security labels or control information

directly with each data item. It combines the actual data with a security label or

access control condition, ensuring data is accessed or modified only in accordance

with predefined rules. It is particularly useful in multilevel secure (MLS) systems,

where data and users operate at different security levels (e.g., Confidential, Secret,

Top Secret).

13
 Integrity Lock

Structure of an Integrity Lock

<Data Value, Security Label, Integrity Constraint>

 Data Value: The actual piece of information (e.g., Salary = 80K).

 Security Label: Classification or clearance level required to access the data

(e.g., Secret, Top Secret).

 Integrity Constraint: A policy or rule defining who can access or modify the

data (e.g., Role = HR AND Level ≥ 5).

14
 Integrity Lock

When a user queries or attempts to modify a data item

 User Credentials (such as role, clearance level, department) are matched against

the security label and integrity constraint of the data item.

 If the user's access level satisfies the constraint, the operation is allowed.

 If not, access is denied, maintaining confidentiality and integrity.

15
 Integrity Lock

Objectives of Integrity Lock

 Prevent unauthorized access or modification of sensitive data.

 Provide fine-grained access control based on roles and security labels.

 Enforce data integrity rules dynamically at the data level.

16
 Integrity Lock

Advantages

Features Benefit
Enforces access control at the
Fine-Grained Control
individual data item level
Prevents unauthorized reads and
Enhanced Security
writes based on defined policies
Allows custom conditions like role,
Flexible Policies
department, and clearance
Ideal for environments with multiple
Supports MLS Systems
security classifications

17
 Integrity Lock

Limitations and Challenges

Challenge Description
Extra checks on every access can
Performance Overhead
reduce speed and performance
Each data item must store additional
Storage Overhead
metadata (label + constraint)
Requires support from the DBMS and
Complex Implementation
accurate policy modeling
Managing and updating security rules
Maintenance Difficulty
across records can be cumbersome

18
 Integrity Lock
Applications

 Military and Defense: Where sensitive data must be protected based on

classification levels.

 Healthcare Systems: Restricting access to medical records based on doctors'

roles and patient privacy.

 Financial Institutions: Protecting high-value transactions and customer data

based on user clearance.

 Government Databases: Handling classified information across agencies.

19
 Integrity Lock

Summary

The Integrity Lock mechanism enhances database security by associating

each data item with a security label and access control condition. This ensures that

access or modification occurs only when the user meets the defined security policy.

While it offers strong protection and fine-grained control, it also introduces

complexity in terms of performance, storage, and system design.

20
Integrity Lock

21
Integrity Lock

22
Integrity Lock

23
 Sensitivity Lock

Definition

Sensitivity Lock is a security mechanism in databases designed to protect

sensitive data by controlling access based on data classification and user clearance

levels. It’s primarily used in multilevel security (MLS) environments, like those in

defense, intelligence, or critical infrastructure databases.

24
 Sensitivity Lock

Concept of Sensitivity

 Purpose: Prevent unauthorized users from accessing or inferring sensitive

information.

 Used In: Mandatory Access Control (MAC) models and military-grade

databases.

25
 Sensitivity Lock

Sensitivity Lock Working Scenario

 Data Classification - Each data item (row, column, or cell) is assigned a

sensitivity label (e.g., Confidential, Secret, Top Secret).

 User Clearance - Users are assigned a security clearance level.

 Access Control Enforcement - Users can only view or modify data if their

clearance level matches or exceeds the data’s sensitivity level.

26
 Sensitivity Lock

Example

Data Entry Sensitivity Label

Employee Salary Confidential

Project Code Name Secret

Defense Plans Top Secret

 A user with Secret clearance Can view Confidential and Secret data.

 At the same time, it cannot access Top Secret data Sensitivity Lock prevents it.

27
 Sensitivity Lock

Benefits

 Enforces data confidentiality in sensitive environments

 Prevents data leakage or inference attacks.

 Supports compliance with military and government data protection regulations.

28
 Sensitivity Lock

Challenges

 Complexity in labeling and managing access.

 May affect query performance due to additional security checks.

 Needs tight integration with user authentication and role management.

29
 Sensitivity Lock

Polyinstantiation: Prevents inference by storing multiple versions of the same data

at different security levels.

Integrity Lock: Combines data with integrity labels for ensuring both data

confidentiality and integrity.

30
Sensitivity Lock

31
Sensitivity Lock

32
Sensitivity Lock

33
 Sensitivity Lock

Aspect Zero-Party Data First-Party Data

Collected through user

Shared by Directly by the user
behavior

Consent Explicit and intentional Implicit (via interaction)

High (user tells you what Varies (based on

Accuracy
they want) interpretation)

Lower misuse if consent Higher risk if used without

Usage Risk
honored transparency

Must ensure user knows Must secure analytics

Sensitivity Lock
how it's used infrastructure

34
Sensitivity Lock

35
 Sensitivity Lock
Aspect Second-Party Data Third-Party Data

Trusted partner’s first- Aggregators or unknown

Source
party data sources

Consent Level Indirect (via agreement) Often unclear or lacking

Medium (partner Low (data may be

Trust Level
dependent) outdated or misused)

Co-branding, cross- Ad targeting, market

Use Cases
promotions analysis

Requires strong Needs advanced

Sensitivity Lock
partnership contracts compliance and audit

36
 Security Models

Security models are formal frameworks or mechanisms that define how

data is accessed and protected within a database. They provide structured methods

for implementing confidentiality, integrity, and availability. Security models are

crucial in preventing unauthorized access, ensuring data correctness, and enforcing

access control policies.

37
 Security Models
Objectives of Security Models

 Confidentiality: Protecting sensitive data from unauthorized disclosure.

 Integrity: Preventing unauthorized data modification.

 Availability: Ensuring data is accessible to authorized users when needed.

 Access Control Enforcement: Defining who can access what data and under

what conditions.

 Policy Implementation: Providing mechanisms to implement security policies

systematically.

38
 Security Models

Types of Security Models in Database Security

Security models are broadly categorized into three types:

 Discretionary Access Control (DAC) Model

 Mandatory Access Control (MAC) Model

 Role-Based Access Control (RBAC) Model

39
 Security Models

Discretionary Access Control (DAC) Model

Definition: Access to database objects (tables, views, etc.) is granted or

revoked based on the discretion of the data owner or administrator.

Features

 Owners have control over who can access their objects.

 Commonly implemented through GRANT and REVOKE commands in SQL.

40
 Security Models

Advantages

 Flexible and easy to implement.

 User-friendly for shared environments.

Disadvantages

 Vulnerable to Trojan horse attacks (malicious code accessing data).

 Not suitable for highly sensitive data.

41
 Security Models

Mandatory Access Control (MAC) Model

Definition: Access decisions are based on security labels/classifications

assigned to both users and data objects. Users can access only data that matches

their clearance level.

Features

 Enforces strict access rules defined by the database administrator.

 Common in military and government databases.

42
 Security Models

Advantages

 Provides high-level security and prevents unauthorized data disclosure.

Disadvantages

 Complex to manage.

 Not flexible for dynamic business environments.

43
 Security Models

Role-Based Access Control (RBAC) Model

Definition: Access is based on roles assigned to users rather than

individual user identities.

Features

 Roles correspond to job functions (e.g., HR Manager, Auditor).

 Permissions are assigned to roles, and users inherit permissions from their roles.

44
 Security Models

Advantages

 Simplifies administration for large organizations.

 Enforces least privilege principle efficiently.

Disadvantages

 Requires well-defined roles.

 Less flexible in cases requiring exceptions.

45
 Security Models
Formal Security Models Used in Database Security

Formal security models provide mathematical or theoretical foundations

for secure database design.

 Bell-LaPadula (BLP) Model – Confidentiality Oriented

 Biba Model – Integrity Oriented

 Clark-Wilson Model – Commercial Integrity

 Brewer-Nash (Chinese Wall) Model – Conflict of Interest

 Harrison-Ruzzo-Ullman (HRU) Model

46
 Security Models
Bell-LaPadula (BLP) Model – Confidentiality Oriented

Purpose: Focuses on confidentiality and preventing unauthorized disclosure.

Key Principles

 Simple Security Property (No Read Up) – A subject cannot read data at a higher
classification level.

 Property (No Write Down) – A subject cannot write data to a lower

classification level.

Example: A "Confidential" user cannot read "Secret" data or write to

"Unclassified" data.

47
 Security Models
Biba Model – Integrity Oriented

Purpose: Focuses on integrity and preventing unauthorized modification.

Key Principles:

 Simple Integrity Property (No Read Down) – A subject cannot read data at a

lower integrity level.

 Integrity Property (No Write Up) – A subject cannot writedata to a higher

integrity level.

Example: A highly trusted process cannot use untrusted (low integrity) data.

48
 Security Models
Clark-Wilson Model – Commercial Integrity

Purpose: Ensures well-formed transactions and enforces separation of duties.

Features

 Uses certified programs (TPs) and controlled data (CDs).

 Prevents data corruption via certified transformations.

Example: Banking systems use Clark-Wilson for transaction validation.

49
 Security Models
Brewer-Nash (Chinese Wall) Model – Conflict of Interest

Purpose: Prevents conflict of interest in environments like consulting or finance.

Features

 A user who accesses one company’s data cannot access competitors’ data.

Example: An analyst who accesses "Company A" financials cannot later access

"Company B" (competitor).

50
 Security Models
Harrison-Ruzzo-Ullman (HRU) Model

Purpose: Formal model for access rights management.

Features

 Defines a matrix for subjects, objects, and rights.

 Analyzes safety properties (whether rights can be leaked).

51
 Security Models
Comparison of Security Models

Model Focus Example Usage

DAC Discretionary Corporate databases

MAC Confidentiality Military / Government Systems

RBAC Role-based Enterprise ERP systems

BLP Confidentiality Classified data protection

Biba Integrity Scientific data accuracy

Clark-Wilson Integrity Banking & commercial apps

Brewer-Nash Conflict Avoid Consulting & Finance firms

52
 Security Models

Conclusion

Security models in database security provide structured methods to

enforce policies, restrict unauthorized access, and protect data integrity and

confidentiality. In real-world implementations, combinations of these models (e.g.,

RBAC + MAC) are often used to achieve robust database security.

53
Security Models

54
Security Models

55
Security Models

56
Security Models

57
 Access Controls (Grant & Revoke)

Access control is a method of regulating who can access what data and

what operations they are allowed to perform.

This is critical for:

 Confidentiality: Preventing unauthorized disclosure of information.

 Integrity: Ensuring data is not improperly modified.

 Availability: Guaranteeing that authorized users can access the data.

58
 Access Controls (Grant & Revoke)

There are Two main types of Access Control

 Discretionary Access Control (DAC): Access is granted or denied based on

user identity and permissions (typical in SQL systems).

 Mandatory Access Control (MAC): Access decisions are based on fixed

security labels (used in highly secure systems).

SQL primarily supports DAC via Grant & Revoke

59
Access Controls (Grant & Revoke)

60
 Access Controls (Grant & Revoke)

GRANT Statement – Providing Access

Purpose

Used to assign privileges (permissions) to users or roles on database

objects such as tables, views, sequences, procedures, etc.

61
 Access Controls (Grant & Revoke)

Syntax

Sql

GRANT privilege_list

ON object_name

TO user_or_role

[WITH GRANT OPTION];

62
 Access Controls (Grant & Revoke)

Explanation of Terms

 privilege_list - Specific operations (e.g., SELECT, INSERT, UPDATE).

 object_name - The database object to which access is being granted.

 user_or_role - The user or role receiving the permissions.

WITH GRANT OPTION (optional) - Allows the recipient to further grant the

permission to others.

63
 Access Controls (Grant & Revoke)

Example 1

sql

GRANT SELECT, INSERT

ON Employees

TO user1;

This gives user1 the ability to read and insert records into the Employees table.

64
 Access Controls (Grant & Revoke)

Example 2

sql

GRANT SELECT

ON Employees

TO user2

WITH GRANT OPTION;

user2 can now read the table and also grant SELECT access to others.

65
 Access Controls (Grant & Revoke)

REVOKE Statement – Taking Back Access

Purpose

Used to remove previously granted privileges from a user or role.

Syntax in sql

REVOKE privilege_list

ON object_name

FROM user_or_role;

66
 Access Controls (Grant & Revoke)

Example

sql

REVOKE INSERT

ON Employees

FROM user1;

This removes the ability of user1 to insert records into the Employees table.

67
 Access Controls (Grant & Revoke)

Cascading Effect with GRANT OPTION

If a user has been granted a privilege with the GRANT OPTION, and that

user grants it to another, revoking the privilege from the first user may cascade and

remove the privilege from others who received it indirectly.

68
 Access Controls (Grant & Revoke)

Example

Admin grants SELECT to Alice with GRANT OPTION.

Alice grants SELECT to Bob.

If Admin revokes SELECT from Alice, Bob also loses the privilege (depending on

DBMS settings and cascading rules).

69
 Access Controls (Grant & Revoke)

Use Cases in Real Systems

 Multi-user Environments: Different access for HR, finance, and developers.

 Application-Level Control: Limit app users to only the operations they need.

 Security Auditing: Ensures only authorized actions are possible, simplifying

audits.

70
 Access Controls (Grant & Revoke)

Best Practices

 Use roles: Assign privileges to roles instead of individual users for easier

management.

 Principle of Least Privilege: Grant only the minimum required privileges.

 Regular Reviews: Periodically audit user permissions.

 Avoid excessive use of WITH GRANT OPTION.

71
 Access Controls (Grant & Revoke)
Common Privileges in SQL

Privilege Description

SELECT Read data from a table/view

INSERT Add new rows to a table

UPDATE Modify existing data

DELETE Remove rows from a table

EXECUTE Run a stored procedure

USAGE Use schema objects like sequences

ALL Grants all available privileges

72
 Access Controls (Grant & Revoke)

Summary

Feature GRANT REVOKE

Function Assign privileges Remove privileges

Applies To Tables, views, procedures, etc. Same objects

Can be cascaded Yes (if WITH GRANT OPTION used) Yes

Role-based control Supported Supported

73
Access Controls (Grant & Revoke)

74
Access Controls (Grant & Revoke)

75
Access Controls (Grant & Revoke)

76
Access Controls (Grant & Revoke)

77
 Distributed Database Security
A Distributed Database (DDB) is a collection of multiple logically

interrelated databases distributed over a computer network. Security in such

systems is far more complex than in centralized databases due to the decentralized

nature, multiple points of access, and communication over networks.

It involves ensuring confidentiality, integrity, and availability of data

stored across multiple locations and accessed over networks. Security must be

maintained both locally at each site and globally across the system.

78
 Distributed Database Security
Core Security Challenges in Distributed Databases
Security Concern Description
Verifying identities of users across
Authentication
multiple sites.
Enforcing user permissions across
Authorization
nodes with consistent policies.
Ensuring sensitive data is protected
Confidentiality
during storage and transit.
Preventing unauthorized or accidental
Integrity
data modification.
Guaranteeing data can be accessed even
Availability
during node failure or attack.
Security policies must be uniformly
Consistency of Policies
enforced across all sites.
Protecting inter-node data transfer from
Communication Security
interception and tampering.
79
 Distributed Database Security
Components of Distributed DB Security Architecture

 Local Security at Each Site

 Global Security Management

 Secure Communication Channels

Local Security at Each Site

 User-level access control

 Local encryption and data masking

 Local authentication (passwords, biometrics)

80
 Distributed Database Security
Global Security Management

 Centralized policy enforcement engine or federated access control

 Global user ID mapping and role-based access

 Distributed firewall and intrusion detection systems

Secure Communication Channels

 Encryption protocols like SSL/TLS for data in transit

 VPNs for secure inter-node communication

81
 Distributed Database Security
Security Mechanisms in DDBMS

Access Control

 Discretionary Access Control (DAC): Users grant/restrict permissions.

 Mandatory Access Control (MAC): Based on clearance levels and labels.

 Role-Based Access Control (RBAC): Permissions granted via roles.

Replication and Backup Security

 Secure replicated data to avoid tampering.

 Encrypted backup storage and secure recovery.

82
 Distributed Database Security
Authentication & Authorization

 Single Sign-On (SSO) & federated identity management (e.g., Kerberos,

LDAP).

 Site-to-site trust models or tokens (e.g., OAuth, JWTs).

Encryption

 Data at Rest: AES encryption of stored data.

 Data in Transit: SSL/TLS for communication.

 Column-level or Row-level Encryption for sensitive fields.

83
 Distributed Database Security
Audit and Logging

 Each node logs user activity.

 Centralized or federated audit trail analysis.

 Useful for forensic investigations.

Intrusion Detection and Prevention Systems (IDPS)

 Monitor unusual activities across nodes.

 Can trigger alerts and automated mitigation.

84
 Distributed Database Security
Security in Distributed Query Processing

When queries span multiple nodes

 Secure middleware ensures intermediate data isn’t exposed.

 Access control policies are respected at all sites.

 Data is sanitized and filtered at source nodes before transmission.

85
 Distributed Database Security
Security Models in Distributed Databases

Model Description

All sites use the same DBMS and uniform

Homogeneous Security Model
security policies. Easier to manage.

Different DBMSs with differing policies and

Heterogeneous Security Model mechanisms. Requires translation layers and
policy mapping.

Combines policies from autonomous

Federated Security Model databases under a shared framework. Often
used in multi-organization setups.

86
 Distributed Database Security
Best Practices for Distributed DB Security

 Encrypt data at rest and in transit.

 Apply RBAC across all sites for uniform access control.

 Synchronize audit logs and centralize log analysis.

 Use SSO and federated authentication for seamless access.

 Segment networks and use firewalls between database nodes.

 Regularly patch and update software at all sites.

 Perform periodic penetration testing and vulnerability assessments.

87
 Distributed Database Security
Conclusion

Distributed database security is complex but essential, especially in

enterprise and cloud environments. It involves securing:

 Multiple databases across different locations & User access

 Data in motion and at rest & Inter-node communications

Implementing robust security measures in distributed databases ensures

data protection, regulatory compliance, and trust in decentralized architectures.

88
Distributed Database Security

89
Distributed Database Security

90
Distributed Database Security

91
Distributed Database Security

92
Outsourced Database & Security Requirements

In today’s cloud-driven world, many organizations outsource their

database management to third-party service providers (e.g., AWS, Google Cloud,

Azure, Oracle Cloud). While this offers flexibility and cost benefits, it introduces

critical security concerns.

Since data is stored and processed outside the organization's control, risks

like data breaches, unauthorized access, insider threats, and compliance violations

increase. Therefore, robust security frameworks are mandatory.

93
Outsourced Database & Security Requirements

An outsourced database is

 Hosted on external infrastructure (public/private cloud or third-party data

centers).

 Managed by third-party vendors, not by the organization that owns the data.

 Accessed remotely via APIs, web portals, or database clients.

94
Outsourced Database & Security Requirements

Key Security Requirements for Outsourced Databases

 Data Confidentiality

 Data Integrity

 Access Control and Authentication

 Secure Multi-Tenancy

 Auditing and Monitoring

 Compliance with Regulations

95
Outsourced Database & Security Requirements

 Data Availability & Disaster Recovery

 Data Ownership and Portability

 Insider Threat Protection

 Trusted Execution Environments (TEE) and Secure Hardware

96
Outsourced Database & Security Requirements

Data Confidentiality

 Protect data from unauthorized access during transit and storage.

 Encryption at rest (e.g., AES-256) and encryption in transit (e.g., TLS 1.2+).

 Use end-to-end encryption for sensitive applications (e.g., healthcare, finance).

97
Outsourced Database & Security Requirements

Data Integrity

 Ensure the data is not tampered with or altered.

 Checksums, digital signatures, and hashing algorithms (e.g., SHA-256) help

verify data integrity.

 Use versioning and logs to track changes.

98
Outsourced Database & Security Requirements

Access Control and Authentication

 Enforce Role-Based Access Control (RBAC) or Attribute-Based Access

Control (ABAC).

 Implement multi-factor authentication (MFA).

 Use identity federation or single sign-on (SSO) for centralized access control.

99
Outsourced Database & Security Requirements

Secure Multi-Tenancy

 In cloud environments, multiple clients may share the same infrastructure.

 Isolation mechanisms (e.g., Virtual Private Cloud, tenant-aware access control)

must be implemented to ensure one client's data cannot be accessed by another.

100
Outsourced Database & Security Requirements

Auditing and Monitoring

 Maintain audit logs for all access and activity.

 Use real-time monitoring and anomaly detection systems to identify suspicious

activities.

 Ensure logs are immutable and stored securely.

101
Outsourced Database & Security Requirements
Compliance with Regulations

 Adhere to legal and industry standards

 GDPR (Europe)

 HIPAA (USA, for healthcare)

 PCI-DSS (for payment data)

 ISO/IEC 27001 (information security management)

 Outsourcing providers must demonstrate compliance via certifications and

audits.
102
Outsourced Database & Security Requirements

Data Availability & Disaster Recovery

 Ensure high availability with redundant servers and failover systems.

 Use automated backups, geo-replication, and disaster recovery plans.

 Define Service-Level Agreements (SLAs) with guaranteed uptime.

103
Outsourced Database & Security Requirements

Data Ownership and Portability

 Define who owns the data in the outsourcing contract.

 Ensure data can be exported or migrated easily in case of vendor change (avoid

vendor lock-in).

 Use open standards and formats (like SQL dumps or JSON/XML).

104
Outsourced Database & Security Requirements

Insider Threat Protection

 Employees of the service provider may misuse privileges.

 Implement

 Least privilege access

 Separation of duties

 Background checks and training for vendor staff

105
Outsourced Database & Security Requirements

Trusted Execution Environments (TEE) and Secure Hardware

 Use technologies like Intel SGX, ARM TrustZone, or confidential computing to

protect data during computation.

106
Outsourced Database & Security Requirements
Security Lifecycle in Outsourced DB Management

Phase Security Consideration

Planning Assess vendor security posture, policies, and certifications.

Deployment Encrypt data, configure access policies, and enable logging.

Operation Monitor usage, review logs, respond to alerts, audit access.

Termination Securely export and delete data, revoke access, verify wipe logs.

107
Outsourced Database & Security Requirements

Technologies Used

Security Feature Tools & Technologies

Encryption AES, RSA, TLS, SSL

Authentication LDAP, OAuth, SAML, MFA

Access Control IAM (Identity Access Management), RBAC

Monitoring SIEM (e.g., Splunk, ELK), CloudTrail

Backup & DR AWS Backup, Azure Site Recovery, snapshots

Compliance Cloud provider’s compliance documentation & audit reports

108
Outsourced Database & Security Requirements

Risks Without Proper Security

Risk Impact

Data Breach Loss of trust, legal fines

Unauthorized Access Data theft, service disruption

Insider Attack Business secrets leakage

Poor Configuration Open to external attacks

Non-compliance Regulatory penalties and lawsuits

109
Outsourced Database & Security Requirements

Best Practices

 Choose reputable service providers with strong security track records.

 Regularly review access permissions and conduct security audits.

 Enforce zero-trust architecture: never trust, always verify.

 Implement encryption, logging, and backup strategies.

 Draft a clear SLA and data ownership agreement with security clauses.

110
Outsourced Database & Security Requirements

Conclusion

Outsourcing databases offers scalability and cost-efficiency, but it brings

shared responsibility for security. Organizations must:

 Protect sensitive data

 Ensure privacy and compliance

 Monitor and audit regularly

 Clearly define access and ownership

111
Outsourced Database & Security Requirements

112
Outsourced Database & Security Requirements

113
Outsourced Database & Security Requirements

114
Outsourced Database & Security Requirements

115
Outsourced Database & Security Requirements

116
Outsourced Database & Security Requirements

117
 Query Authentication Dimension
Query Authentication is a dimension of database security that ensures

only authorized and authenticated users can issue queries and access data or

perform operations on the database. It focuses on verifying that a query request is:

 From a legitimate user or system, and

 Permitted under the security policy for that user or role.

This concept is especially critical in environments like distributed

systems, outsourced databases, and cloud computing, where multiple users and

services interact with the database remotely.

118
 Query Authentication Dimension
Query Authentication Dimension refers to the security checks applied to

queries before they are executed by the database, including

 Verifying the identity of the requestor

 Authorizing the query based on user privileges

 Ensuring query integrity (no tampering or injection)

 Tracking and logging query execution.

This dimension operates at the interface between the user/application and

the database engine.

119
 Query Authentication Dimension
Key Components of Query Authentication Dimension

Component Description

Ensures the query is submitted by a verified

User Authentication
identity (e.g., via password, token, certificate).

Verifies whether the user has the right to perform

Access Control Check
the requested operation (e.g., SELECT, INSERT).

Confirms that the query has not been altered or

Query Signature / Token Validation
forged.

Query Integrity Validation Protects against tampering or injection attacks.

Records who issued what query, when, and from

Audit Logging
where.

120
 Query Authentication Dimension
Techniques Used in Query Authentication

 Login-Based Authentication

 Token-Based Authentication

 Certificate-Based Authentication

 Query Signing / Hashing

 Two-Factor Authentication (2FA)

121
 Query Authentication Dimension
Threats Mitigated by Query Authentication

Threat How Authentication Helps

SQL Injection Filters unauthenticated or malformed queries.

Unauthorized Access Prevents non-privileged users from issuing queries.

Session Hijacking Token/session validation mitigates impersonation.

Replay Attacks Query tokens with timestamps or nonce prevent reuse.

Man-in-the-Middle TLS encryptions plus certificate validation protect communication.

122
 Query Authentication Dimension
Best Practices

 Enforce Strong Authentication: Use MFA or federated identity providers.

 Implement Role-Based Query Authorization: Align query privileges with job

functions.

 Use Secure Channels: Protect queries in transit using TLS.

 Tokenize or Sign Queries: For outsourced or sensitive environments.

 Log and Monitor Queries: Use SIEM tools to detect abnormal patterns.

 Restrict Dynamic Query Execution: Reduce exposure to injection threats.

123
 Query Authentication Dimension
Summary about Query Authentication Dimension

Feature Purpose

User Identity Verification Ensures the query comes from a legitimate user.

Privilege Check Confirms user has rights to run the query.

Query Integrity Prevents tampering or injection.

Logging Enables tracking and auditing.

Secure Transport Protects queries in transit.

124
 Query Authentication Dimension
Conclusion

The Query Authentication Dimension is a vital aspect of database security

that

 Protects data and operations from unauthorized queries.

 Ensures queries are executed by authenticated and authorized users.

 Helps detect and prevent injection attacks, tampering, and unauthorized access.

It forms the first line of defense in multi-user, distributed, or cloud-based

database systems.

125
 Condensed RSA & Merkle Tree
RSA (Rivest-Shamir-Adleman) – Condensed View

Purpose

Asymmetric encryption used for secure key exchange, digital signatures,

and data confidentiality.

Key Concepts

 Asymmetric keys: Public key (encrypt), Private key (decrypt)

 Mathematical foundation: Based on the difficulty of factoring large prime

products.

126
 Condensed RSA & Merkle Tree
Use Cases

 HTTPS / SSL

 Email encryption (e.g., PGP)

 Digital signatures

127
 Condensed RSA & Merkle Tree
Merkle Tree - Condensed View

Purpose

Efficient and secure verification of data integrity in distributed systems

(e.g., blockchain, databases).

Use Cases

 Blockchain (e.g., Bitcoin, Ethereum)

 Distributed databases (Cassandra, DynamoDB)

 File systems (IPFS, Git)

128
 Condensed RSA & Merkle Tree
Structure

 A binary tree of cryptographic hashes

 Leaves = hashes of data blocks

 Non-leaf nodes = hash of concatenated child hashes

 Root = Merkle root, represents the entire dataset

129
 Condensed RSA & Merkle Tree
RSA vs Merkle Tree Comparison

Feature RSA Merkle Tree

Type Asymmetric encryption Data integrity structure

Use Case Secure communication, signatures Fast integrity checks in large datasets

Based On Prime factorization Hash functions (e.g., SHA-256)

Efficiency Slower, heavy on CPU Fast and lightweight

Common In HTTPS, secure messaging Blockchains, version control

130
Condensed RSA & Merkle Tree

131
Condensed RSA & Merkle Tree

132
Condensed RSA & Merkle Tree

133
Condensed RSA & Merkle Tree

134
Condensed RSA & Merkle Tree

135
Condensed RSA & Merkle Tree

136