Hubbry Logo
Database securityDatabase securityMain
Open search
Database security
Community hub
Database security
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Database security
Database security
Database security
View on Wikipedia
from Wikipedia

Database security concerns the use of a broad range of information security controls to protect databases against compromises of their confidentiality, integrity and availability.[1] It involves various types or categories of controls, such as technical, procedural or administrative, and physical.

Security risks to database systems include, for example:

  • Unauthorized or unintended activity or misuse by authorized database users, database administrators, or network/systems managers, or by unauthorized users or hackers (e.g. inappropriate access to sensitive data, metadata or functions within databases, or inappropriate changes to the database programs, structures or security configurations);
  • Malware infections causing incidents such as unauthorized access, leakage or disclosure of personal or proprietary data, deletion of or damage to the data or programs, interruption or denial of authorized access to the database, attacks on other systems and the unanticipated failure of database services;
  • Overloads, performance constraints and capacity issues resulting in the inability of authorized users to use databases as intended;
  • Physical damage to database servers caused by computer room fires or floods, overheating, lightning, accidental liquid spills, static discharge, electronic breakdowns/equipment failures and obsolescence;
  • Design flaws and programming bugs in databases and the associated programs and systems, creating various security vulnerabilities (e.g. unauthorized privilege escalation), data loss/corruption, performance degradation etc.;
  • Data corruption and/or loss caused by the entry of invalid data or commands, mistakes in database or system administration processes, sabotage/criminal damage etc.

Ross J. Anderson has often said that by their nature large databases will never be free of abuse by breaches of security; if a large system is designed for ease of access it becomes insecure; if made watertight it becomes impossible to use. This is sometimes known as Anderson's Rule.[2]

Many layers and types of information security control are appropriate to databases, including:


Databases have been largely secured against hackers through network security measures such as firewalls, and network-based intrusion detection systems. While network security controls remain valuable in this regard, securing the database systems themselves, and the programs/functions and data within them, has arguably become more critical as networks are increasingly opened to wider access, in particular access from the Internet. Furthermore, system, program, function and data access controls, along with the associated user identification, authentication and rights management functions, have always been important to limit and in some cases log the activities of authorized users and administrators. In other words, these are complementary approaches to database security, working from both the outside-in and the inside-out as it were.

Many organizations develop their own "baseline" security standards and designs detailing basic security control measures for their database systems. These may reflect general information security requirements or obligations imposed by corporate information security policies and applicable laws and regulations (e.g. concerning privacy, financial management and reporting systems), along with generally accepted good database security practices (such as appropriate hardening of the underlying systems) and perhaps security recommendations from the relevant database system and software vendors. The security designs for specific database systems typically specify further security administration and management functions (such as administration and reporting of user access rights, log management and analysis, database replication/synchronization and backups) along with various business-driven information security controls within the database programs and functions (e.g. data entry validation and audit trails). Furthermore, various security-related activities (manual controls) are normally incorporated into the procedures, guidelines etc. relating to the design, development, configuration, use, management and maintenance of databases.

Privileges

[edit]

Two types of privileges are important relating to database security within the database environment: system privileges and object privileges.

System privileges

[edit]

System privileges allow a local user to perform administrative actions in a database.

Object privileges

[edit]

Object privileges allow for the use of certain operations on database objects as authorized by another user. Examples include: usage, select, insert, update, and references.[3]

Principal of least privilege

[edit]

Databases that fall under internal controls (that is, data used for public reporting, annual reports, etc.) are subject to the separation of duties, meaning there must be segregation of tasks between development, and production. Each task has to be validated (via code walk-through/fresh eyes) by a third person who is not writing the actual code. The database developer should not be able to execute anything in production without an independent review of the documentation/code for the work that is being performed. Typically, the role of the developer is to pass code to a DBA; however, given the cutbacks that have resulted from the economic downturn, a DBA might not be readily available. If a DBA is not involved, it is important, at minimum, for a peer to conduct a code review. This ensures that the role of the developer is clearly separate.[citation needed]

Another point of internal control is adherence to the principle of providing the least amount of privileges, especially in production. To allow developers more access to get their work done, it is much safer to use impersonation for exceptions that require elevated privileges (e.g. EXECUTE AS or sudo to do that temporarily). Often developers may dismiss this as “overhead” while on their path to coding glory. Please be aware, however, that DBAs must do all that is considered responsible because they are the de facto data stewards of the organization and must comply with regulations and the law.[4]

Vulnerability assessments to manage risk and compliance

[edit]
Further information: application security

One technique for evaluating database security involves performing vulnerability assessments or penetration tests against the database. Testers attempt to find security vulnerabilities that could be used to defeat or bypass security controls, break into the database, compromise the system etc. Database administrators or information security administrators may for example use automated vulnerability scans to search out misconfiguration of controls (often referred to as 'drift') within the layers mentioned above along with known vulnerabilities within the database software. The results of such scans are used to harden the database (improve security) and close off the specific vulnerabilities identified, but other vulnerabilities often remain unrecognized and unaddressed.

In database environments where security is critical, continual monitoring for compliance with standards improves security. Security compliance requires, amongst other procedures, patch management and the review and management of permissions (especially public) granted to objects within the database. Database objects may include table or other objects listed in the Table link. The permissions granted for SQL language commands on objects are considered in this process. Compliance monitoring is similar to vulnerability assessment, except that the results of vulnerability assessments generally drive the security standards that lead to the continuous monitoring program. Essentially, vulnerability assessment is a preliminary procedure to determine risk where a compliance program is the process of on-going risk assessment.

The compliance program should take into consideration any dependencies at the application software level as changes at the database level may have effects on the application software or the application server.

Abstraction

[edit]

Application level authentication and authorization mechanisms may be effective means of providing abstraction from the database layer. The primary benefit of abstraction is that of a single sign-on capability across multiple databases and platforms. A single sign-on system stores the database user's credentials and authenticates to the database on behalf of the user. Abstraction is the idea of making complex ideas easier to understand.

Database activity monitoring (DAM)

[edit]

Another security layer of a more sophisticated nature includes real-time database activity monitoring, either by analyzing protocol traffic (SQL) over the network, or by observing local database activity on each server using software agents, or both. Use of agents or native logging is required to capture activities executed on the database server, which typically include the activities of the database administrator. Agents allow this information to be captured in a fashion that can not be disabled by the database administrator, who has the ability to disable or modify native audit logs.

Analysis can be performed to identify known exploits or policy breaches, or baselines can be captured over time to build a normal pattern used for detection of anomalous activity that could be indicative of intrusion. These systems can provide a comprehensive database audit trail in addition to the intrusion detection mechanisms, and some systems can also provide protection by terminating user sessions and/or quarantining users demonstrating suspicious behavior. Some systems are designed to support separation of duties (SOD), which is a typical requirement of auditors. SOD requires that the database administrators who are typically monitored as part of the DAM, not be able to disable or alter the DAM functionality. This requires the DAM audit trail to be securely stored in a separate system not administered by the database administration group.

Native audit

[edit]

In addition to using external tools for monitoring or auditing, native database audit capabilities are also available for many database platforms. The native audit trails are extracted on a regular basis and transferred to a designated security system where the database administrators do/should not have access. This ensures a certain level of segregation of duties that may provide evidence the native audit trails were not modified by authenticated administrators, and should be conducted by a security-oriented senior DBA group with read rights into production. Turning on native impacts the performance of the server. Generally, the native audit trails of databases do not provide sufficient controls to enforce separation of duties; therefore, the network and/or kernel module level host based monitoring capabilities provides a higher degree of confidence for forensics and preservation of evidence.

Process and procedures

[edit]

A good database security program includes the regular review of privileges granted to user accounts and accounts used by immediate processes. For individual accounts a two-factor authentication system improves security but adds complexity and cost. Accounts used by automated processes require appropriate controls around password storage such as sufficient encryption and access controls to reduce the risk of compromise.

In conjunction with a sound database security program, an appropriate disaster recovery program can ensure that service is not interrupted during a security incident, or any incident that results in an outage of the primary database environment. An example is that of replication for the primary databases to sites located in different geographical regions.[5]

After an incident occurs, database forensics can be employed to determine the scope of the breach, and to identify appropriate changes to systems and processes.

See also

[edit]

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Database security

View on Grokipedia
from Grokipedia
Database security encompasses the tools, controls, policies, and practices implemented to protect and database systems from unauthorized access, malicious attacks, and illegitimate use, ensuring the , integrity, and availability of stored data. As organizations increasingly rely on to manage vast amounts of sensitive information, including , financial records, and , robust database security is essential to mitigate risks of data breaches, which can lead to severe financial losses, , and regulatory penalties such as those under GDPR. remains a leading cause of breaches, accounting for 26% of incidents (, 2025), often through misconfigurations or inadequate access controls. Common threats to database security include insider threats from employees or contractors with legitimate access, external attacks like SQL and NoSQL injection exploits that manipulate queries to extract or alter data, malware infections, denial-of-service (DoS) attacks that overwhelm systems, and vulnerabilities in backups or cloud environments due to shared responsibility models. These risks are amplified by the growing complexity of hybrid and cloud-based infrastructures, where databases may span on-premises servers, virtual environments, and public clouds. To counter these challenges, effective database security incorporates multiple layers of defense, such as access management through (RBAC), (MFA), and the principle of least privilege to limit user permissions; encryption of data at rest and in transit to prevent interception or theft; vulnerability management via timely patching and software updates; and monitoring tools for real-time auditing, intrusion detection, and anomaly alerting. Additional measures include for hardware, data masking for non-production environments, regular penetration testing, and secure backup protocols to ensure recovery without compromising integrity. Best practices emphasize a proactive approach, including annual security assessments, employee to reduce , deployment of web application firewalls (WAF) to block injection attacks, and integration of agentless tools like database security posture management (DSPM) for cloud-native protection. By adhering to these strategies, organizations can maintain compliance, enhance resilience against evolving threats, and protect critical assets in an interconnected digital landscape.

Core Concepts

Definition and Scope

Database security refers to the technical and designed to protect database management systems (DBMS) from unauthorized access, malicious cyber-attacks, illegitimate use, data breaches, alteration, or destruction. These measures ensure that databases, which serve as critical repositories for sensitive organizational data, remain safeguarded against a wide range of threats while supporting reliable data operations. The core objectives of database security align with foundational principles, including (preventing unauthorized disclosure of data), integrity (maintaining the accuracy, completeness, and trustworthiness of data), (ensuring timely and reliable access to data for authorized users), and (providing verifiable proof of user actions and transactions to prevent denial of involvement). These objectives guide the implementation of protective mechanisms, emphasizing the need to balance security with in data handling. The field originated in the 1970s with the development of systems, such as IBM's System R project, which introduced early security features like view mechanisms and subsystems to control data access within structured query environments. Over time, database security has evolved to address the complexities of distributed systems, , and , adapting from isolated mainframe-era protections to robust defenses against modern, interconnected threats. In scope, database security encompasses relational databases (using SQL standards), NoSQL databases (for unstructured or semi-structured data), and hybrid systems that combine both paradigms, with a particular emphasis on protecting data at rest (stored on disk), in transit (during network transfer), and in use (during processing). This focus distinguishes it from broader IT security, which addresses network and endpoint protections, by prioritizing database-specific vulnerabilities such as injection attacks and privilege escalations inherent to data storage and querying operations. Recent updates, such as the OWASP Top 10 2025 released on November 10, 2025, highlight evolving web application risks including injection flaws that impact databases.

Key Threats and Risks

Database security faces a range of threats from both internal and external actors, each capable of compromising , , and . These risks underscore the need for robust protective measures, as breaches can result in unauthorized access, , or system disruption. Internal threats often arise from within the , while external ones exploit vulnerabilities from outside, and advanced persistent threats (APTs) involve prolonged, targeted campaigns. Internal threats primarily stem from authorized users, including intentional misuse and accidental errors. Insider misuse occurs when employees or contractors exploit their legitimate access to steal, alter, or for personal gain or malice, with 83% of organizations reporting at least one such incident in 2024 according to Cybersecurity Insiders' report. Accidental errors by authorized personnel, such as writing misconfigured SQL queries that inadvertently expose sensitive records or granting excessive permissions during routine maintenance, can lead to unintended leakage without any malicious intent. These internal risks are particularly challenging because they bypass external perimeter defenses, with 92% of organizations finding insider attacks as difficult or more so to detect than external cyber threats. External threats target databases through network-facing vulnerabilities and application weaknesses. SQL injection attacks represent a common vector, where attackers insert malicious SQL code into input fields—such as web forms—to alter or execute unauthorized queries on the underlying database, potentially dumping entire tables or bypassing . Distributed denial-of-service (DDoS) attacks on database servers flood them with excessive traffic or resource-intensive queries, overwhelming CPU, memory, or bandwidth to deny service to legitimate users and cause operational downtime. Unauthorized network access exploits exposed ports, weak firewalls, or unencrypted connections to infiltrate database systems, allowing attackers to enumerate schemas or extract data directly. Advanced persistent threats (APTs) involve sophisticated, long-term intrusions by state-sponsored or organized cybercriminals aiming to maintain undetected access to sensitive databases for or . These actors use stealthy techniques like lateral movement and custom to target high-value data over months or years. A notable example is the 2017 Equifax breach, where attackers exploited an unpatched vulnerability in Apache Struts (CVE-2017-5638) to access the company's database, exposing personal information of 147 million individuals including Social Security numbers and credit details. Databases face environment-specific risks that amplify broader threats, including data leakage from weak mechanisms, privilege escalation exploits, and attacks. Weak , such as default credentials or insufficient password policies, enables attackers to impersonate users and access restricted data stores. Privilege escalation exploits allow low-privileged accounts to gain administrative control, for instance, by abusing user-defined functions in to execute arbitrary code and elevate permissions. attacks enable adversaries to derive confidential information from aggregated or partially visible query results, such as statistically inferring individual salaries from department averages despite access controls limiting direct views. The consequences of these threats are severe, with data breaches imposing substantial financial and . According to IBM's 2025 Cost of a Report, the global average cost decreased to $4.44 million from $4.88 million in 2024. Despite predictions of escalation, AI-related factors contributed to varied impacts, with shadow AI breaches costing an average of $4.63 million. AI-assisted attacks, where generative AI tools enable faster vulnerability scanning, automated exploit generation, and sophisticated tailored to database administrators, remain a significant concern, with 93% of leaders anticipating daily AI-powered threats as of 2024 predictions.

Access Control Mechanisms

Privileges and Permissions

In database systems, privileges and permissions form the foundational mechanisms for controlling user access to resources, ensuring that only authorized actions are performed on and structures. System privileges grant broad administrative capabilities that apply across the entire database instance or server, such as creating users or modifying system parameters. For instance, in , privileges like CREATE USER allow the creation of new database accounts, ALTER SYSTEM enables configuration changes at the instance level, and GRANT ANY PRIVILEGE permits the delegation of other privileges on behalf of any user. Similarly, in , server-level permissions such as ALTER ANY LOGIN manage logins across the instance, while database-level privileges like CREATE USER facilitate user creation within a specific database. These privileges typically operate at a server-wide or schema-specific scope, distinguishing them from more targeted controls by affecting global operations rather than individual objects. Object privileges, in contrast, provide granular control over specific database objects such as tables, views, or procedures, limiting actions to those items alone. Common examples include SELECT for querying data, INSERT for adding rows, UPDATE for modifying existing data, and DELETE for removing rows, which can be applied to tables or views. Many systems support column-level granularity, allowing permissions on individual columns within a table; for example, in SQL Server, UPDATE can be restricted to specific columns like BusinessEntityID in a view. In , these privileges are schema-specific, meaning they apply to objects owned by a particular user or , preventing unintended access to unrelated data. This level of detail ensures precise without exposing broader system functions. To manage privileges scalably, especially in large environments, (RBAC) groups multiple privileges into predefined , which are then assigned to users based on their responsibilities. In the NIST RBAC model, permissions are associated with , and users are assigned to appropriate , enabling inheritance of access while supporting role hierarchies where senior acquire junior ones' permissions. For databases, this simplifies administration; Oracle's DBA role, for example, bundles numerous system privileges like CREATE USER and ALTER SYSTEM for database administrators. Constraints such as can prevent conflicts, like assigning incompatible to the same user. SQL Server implements similar role groupings at server and database levels, such as the db_owner role for full database control. Privileges are typically assigned and revoked using SQL statements like GRANT and REVOKE, providing a standardized interface across systems. The basic GRANT syntax is GRANT privilege ON object TO principal [WITH GRANT OPTION];, where WITH GRANT OPTION allows the recipient to further delegate the privilege. For example, in Oracle, GRANT SELECT ON employees TO analyst; grants query access to the employees table for the analyst user, while REVOKE SELECT ON employees FROM analyst; removes it. In SQL Server, the syntax mirrors this for objects: GRANT INSERT ON schema.table TO user;. Implementations vary across database management systems (DBMS), reflecting differences in architecture and granularity. supports highly fine-grained privileges, including auditing-specific ones like AUDIT SYSTEM for monitoring system-wide actions, alongside schema-level object controls. , however, organizes privileges hierarchically: global privileges (e.g., CREATE USER on .) apply server-wide, database-level ones (e.g., SELECT on db.*) to all objects in a database, and table- or column-level grants (e.g., UPDATE (column) on db.table) offer targeted access. This structure in emphasizes level-based scoping over 's object-centric model, aiding simpler deployments but requiring careful hierarchy management to avoid over-privileging.

Principle of Least Privilege

The is a foundational concept in database that restricts users, processes, or systems to the minimal set of permissions necessary to perform their assigned tasks, thereby minimizing the potential for unauthorized access or misuse. This approach applies to database environments by ensuring that accounts interacting with data—such as application users or administrators—only possess privileges aligned with their roles, such as read-only access for querying without modification capabilities. By design, it limits the in databases, where excessive permissions could expose sensitive schemas, tables, or procedures to exploitation. Adopting the principle of least privilege yields significant benefits in database security, including mitigation of insider threats and containment of damage from compromised accounts. For instance, if a database user is granted only SELECT privileges, a breach of that account would prevent data alteration or deletion, preserving even under attack. This strategy also reduces the overall risk of lateral movement by malicious actors within a database , as limited permissions hinder escalation to higher-privilege operations. In practice, organizations following this principle experience fewer incidents of privilege abuse. Implementing the principle of least privilege in databases involves several structured steps to ensure effective enforcement. First, conduct comprehensive privilege audits to inventory current user roles, permissions, and access patterns, identifying and revoking unnecessary grants such as broad administrative on production . Next, adopt (RBAC) to assign permissions dynamically, incorporating temporary or just-in-time elevation for tasks requiring elevated privileges, like schema modifications during maintenance. Automation tools can facilitate ongoing role assignments by integrating with identity management systems, ensuring privileges are provisioned based on job functions and revoked upon role changes. Regular reviews, at least annually or after significant system changes, are essential to validate compliance and adjust for evolving needs. Despite its advantages, implementing the principle of least privilege presents challenges, particularly in balancing stringent security with operational usability in database environments. Over-revocation of permissions can lead to delays in legitimate tasks, such as developers needing ad-hoc access for testing, potentially frustrating users and slowing workflows. A real-world example is the 2021 SolarWinds supply chain breach, where excessive privileges in the Orion network management software—allowing broad system changes—amplified the attack's scope, compromising over 18,000 organizations including U.S. government agencies and enabling widespread . This incident underscored how unmonitored high-privilege accounts can transform a targeted intrusion into a , highlighting the need for proactive privilege management to avoid such escalations. For tools and standards, integration with frameworks like NIST SP 800-53 provides robust guidance for privilege management in databases, emphasizing controls such as AC-6 (Least Privilege) that require organizations to define, document, and enforce minimal access based on job functions. This standard supports database-specific implementations through requirements for and periodic privilege reviews, ensuring alignment with broader federal security baselines applicable to information systems handling sensitive data.

Auditing and Monitoring

Database Activity Monitoring

Database Activity Monitoring (DAM) refers to the process of continuously tracking and analyzing interactions within a database environment, including user queries, data access patterns, and administrative actions, to identify potential security threats without introducing performance overhead or requiring modifications to the database itself. This non-intrusive approach captures database traffic in real time, enabling organizations to maintain visibility into data usage while preserving . Core components of DAM systems typically include query analyzers for SQL statements, access log aggregators for recording events, and risk scoring engines that evaluate activities against predefined policies. Key features of emphasize proactive detection and response. Real-time alerting notifies administrators of anomalies, such as spikes in query volumes or unauthorized exports, allowing immediate intervention. Behavioral analysis establishes user and application baselines over time, flagging deviations that may indicate insider or external attacks. Additionally, DAM tools integrate with (SIEM) platforms to correlate database events with network-wide logs, enhancing overall incident detection. These capabilities ensure comprehensive coverage without relying solely on database-native . Deployment models for DAM vary to suit different infrastructure needs. Agent-based deployments install software agents on database servers for inline inspection of traffic, providing deep visibility but potentially adding minimal latency. In contrast, network-based models passively sniff database packets across the network, offering agentless monitoring ideal for distributed or cloud environments where server access is limited. Prominent examples include Data Security Fabric, which supports both models for hybrid setups, and Guardium, known for its scalable, policy-driven monitoring across on-premises and cloud databases. DAM excels in specific use cases like real-time detection, where systems parse incoming queries for malicious syntax—such as unexpected input —and flag them before execution, preventing data breaches. This is particularly valuable in web-facing applications vulnerable to injection attacks. Advancements in have enhanced DAM effectiveness, particularly in , by reducing false positives through from historical data. AI-integrated models outperform rule-based systems in minimizing alert fatigue for teams.

Native Auditing Features

Native auditing features in database management systems (DBMS) offer built-in capabilities to record user activities, including SQL statements, login attempts, and schema modifications, directly within the DBMS without the need for third-party tools. These features enable administrators to maintain an for investigations, compliance verification, and troubleshooting, capturing events such as privilege usage and data access patterns. For instance, Database's auditing system logs actions on database objects and sensitive data modifications to support accountability. Similarly, SQL Server's auditing mechanism tracks server- and database-level events using extended events infrastructure. In , native logging parameters facilitate the capture of SQL executions and errors for basic auditing purposes. Configuration of native auditing typically involves setting system parameters or defining policies to specify what events to log and where to store the records, such as in operating system files, database tables, or log files. In , auditing is enabled by configuring the AUDIT_TRAIL initialization parameter to values like OS or DB, followed by SQL statements such as AUDIT SELECT ON hr.employees BY ACCESS to log all SELECT operations on a specific table, with records stored in OS files or the SYS.AUD$ table. For SQL Server, administrators create a server audit using commands like CREATE SERVER AUDIT MyServerAudit TO FILE (FILEPATH = 'C:\Audit\'), then define database specifications to target specific actions, outputting to files or Windows event logs. PostgreSQL relies on the postgresql.conf file for settings like log_statement = 'all' to enable logging of all SQL statements, with outputs directed to destinations such as stderr, CSV files, or , managed through parameters like log_directory and rotation settings. Native auditing encompasses several types tailored to different monitoring needs, including statement auditing, which records executions of specific SQL commands; privilege-use auditing, which tracks invocations of system privileges; and schema object auditing, which focuses on actions against particular database objects. In Oracle, statement auditing might log all UPDATE statements on a table, privilege-use auditing captures GRANT executions, and schema object auditing monitors DELETE operations on schemas, all configurable via unified or traditional policies. SQL Server organizes auditing into server-level action groups (e.g., SUCCESSFUL_LOGIN_GROUP for login successes) and database-level groups (e.g., SELECT on tables), allowing granular control over events like schema changes. PostgreSQL's log_statement parameter supports statement-level auditing by categories—ddl for data definition statements like CREATE TABLE, mod for data-modifying statements like INSERT or UPDATE, and all for comprehensive coverage—effectively covering schema and statement types, though it lacks explicit privilege-use auditing without extensions. Examples of native auditing implementations across major DBMS highlight their practical application. SQL Server Audit, introduced in SQL Server 2008 and enhanced in later versions, provides a flexible framework for auditing events like logins and object alterations, with records viewable via functions such as sys.fn_get_audit_file. In , the log_statement parameter serves as a core auditing tool, logging statement text and bind parameters to facilitate reviews of user activities, with outputs formatted in CSV or for easier analysis. Oracle's unified auditing, default in 12c and refined in releases up to 23ai, consolidates logs into a single UNIFIED_AUDIT_TRAIL view, supporting policy-based auditing for events like logon failures. Recent enhancements, such as those in 23ai, improve GDPR compliance by enabling finer-grained logging of access with conditional policies, reducing unnecessary records while ensuring audit trails meet regulatory retention requirements. Despite their utility, native auditing features have notable limitations, particularly regarding and operational . Enabling comprehensive can introduce overhead, with Oracle's unified auditing showing mid-single-digit CPU increases for rates of 360,000 audit records per hour, though optimized policies keep impacts in the single digits even at higher volumes like 1.8 million records per hour. SQL Server auditing may incur similar costs due to event capture and file I/O, potentially affecting query throughput under heavy loads, while PostgreSQL's full log_statement setting adds significant overhead from disk writes and can block under high concurrency if the collector is enabled. Additionally, these features generally lack built-in real-time alerting, relying on post-hoc log analysis, and generate large volumes of that demand proactive storage —such as Oracle's dedicated tablespaces with partitioning, SQL Server's log archiving, or PostgreSQL's parameters (e.g., 10MB size limits)—to prevent disk exhaustion.

Vulnerability and Risk Management

Assessment Techniques

Assessment techniques in database security involve systematic methods to identify, evaluate, and prioritize vulnerabilities, enabling organizations to mitigate risks before exploitation occurs. These techniques encompass automated scanning, simulated attacks, and structured risk modeling, often integrated into broader security practices to detect weaknesses in database management systems (DBMS) such as misconfigurations, outdated patches, or flawed access controls. By focusing on known vulnerabilities cataloged in databases like the Common Vulnerabilities and Exposures (CVE) list, assessments help prevent incidents like unauthorized data access or denial-of-service attacks. Vulnerability scanning employs automated tools to probe databases for known issues, typically by checking against CVE repositories for unpatched flaws in DBMS components. For instance, scanners can identify vulnerabilities in Oracle Database's (TNS) listener, such as CVE-2012-1675, which allows remote attackers to execute arbitrary commands via poisoned service registrations if not patched. These tools perform non-intrusive tests on database configurations, user privileges, and network exposures, generating reports on potential entry points like weak encryption or excessive permissions. recommends integrating such scans early in development to catch issues like vectors that could affect database integrity. Penetration testing simulates real-world attacks by ethical hackers to uncover exploitable weaknesses in database environments, following structured phases to mimic adversary tactics. The process begins with to gather information on the database , such as server versions and exposed ports, followed by scanning to identify services like the TNS listener. Exploitation then attempts to breach controls, for example, by cracking weak mechanisms to gain unauthorized schema access. According to NIST SP 800-115, the final reporting phase documents findings with remediation steps, ensuring tests are scoped to avoid disrupting production systems. This method reveals not only technical flaws but also procedural gaps, such as inadequate input validation leading to . Risk assessment models classify database vulnerabilities using qualitative scales, like high/medium/low based on potential impact and likelihood, or quantitative metrics for precise prioritization. The Common Vulnerability Scoring System (CVSS), maintained by FIRST, provides a standardized quantitative approach, where the Base Score reflects intrinsic vulnerability characteristics without environmental factors. In CVSS v3.1, the Base Score is computed if the Impact subscore is greater than 0. The Impact Sub-Score (ISS) is derived from Confidentiality (C), Integrity (I), and Availability (A) metrics, scored as 0 (None), 0.22 (Low), or 0.56 (High), using ISS = 1 - [(1-C)(1-I)(1-A)]. Impact is then 6.42 × ISS if Scope is Unchanged, or 7.52 × (ISS - 0.029) - 3.25 × (ISS - 0.02)15 if Scope is Changed. Exploitability = 8.22 × Attack Vector × Attack Complexity × Privileges Required × User Interaction. The Base Score is roundup(min((Impact + Exploitability), 10)) if Scope Unchanged, or roundup(1.08 × (Impact + Exploitability)) capped at 10 if Scope Changed. Scores range from 0 to 10, with 7.0-8.9 indicating high severity, guiding patch urgency for database-specific CVEs like those in MySQL or PostgreSQL. Key tools for database assessments include , an open-source scanner that conducts network-based checks against NVTs (Network Vulnerability Tests) tailored for DBMS exposures, and Trustwave DbProtect, a specialized agentless tool for deep scans of database configurations, access controls, and compliance gaps. supports authenticated testing to evaluate internal privileges, while DbProtect prioritizes risks by simulating attack paths. For high-risk environments, such as those handling sensitive financial data, experts recommend quarterly scans to align with evolving threat landscapes. Post-2020 trends reflect a shift toward continuous scanning within DevSecOps pipelines, where tools integrate with workflows to assess databases in real-time during deployments. This approach addresses rising exposures, like misconfigured AWS RDS instances.

Compliance and Regulatory Frameworks

Database security compliance involves aligning database management practices with legal and industry standards to mitigate risks associated with handling, storage, and access. These frameworks mandate specific controls to protect sensitive , ensuring organizations implement robust security measures such as , access restrictions, and audit logging to prevent unauthorized access and breaches. Key regulations shaping database security include the General Data Protection Regulation (GDPR) in the , which requires organizations to encrypt and notify supervisory authorities of breaches within 72 hours of awareness, thereby necessitating secure database configurations to safeguard data at rest and in transit. In the United States, the Health Insurance Portability and Accountability Act (HIPAA) Security Rule establishes standards for protecting electronic (ePHI) in databases, including technical safeguards like access controls and mechanisms to ensure and . The Payment Card Industry Data Security Standard (PCI DSS) outlines requirements for handling payment card in databases, such as maintaining secure networks, protecting stored cardholder data through , and implementing vulnerability management programs. Additionally, the Sarbanes-Oxley Act (SOX) in the US demands trails in financial databases to verify the of reporting , logging changes with user attribution to support accurate financial disclosures. Database features directly map to these standards; for instance, native tools in databases fulfill GDPR and PCI DSS mandates for data protection, while built-in auditing capabilities provide the SOX-required trails for tracking modifications to financial records. Similarly, HIPAA-compliant databases incorporate role-based access controls and transmission security to align with its administrative, physical, and technical safeguards. Risk management frameworks like integrate database security into broader systems (ISMS), with controls such as A.8.15 requiring for user activities, exceptions, and security incidents in databases to enable regular reviews and incident response. This standard promotes a systematic approach to identifying and treating risks, including database-specific measures for and monitoring to maintain compliance across operations. The EU's NIS2 Directive, effective October 18, 2024, further mandates enhanced risk management, incident reporting, and supply chain security for essential and important entities, impacting database security in critical sectors such as energy, transport, and digital services. Challenges in compliance arise from cross-border data flows, which complicate adherence to varying jurisdictional rules under GDPR and emerging laws, as well as evolving regulations like the 2025 (CCPA) updates that introduce requirements for risk assessments in AI-driven within databases. Non-compliance penalties are severe; GDPR violations can result in fines up to €20 million or 4% of global annual turnover, whichever is greater, with notable cases including Meta's €1.2 billion fine for data transfer issues. Auditing for compliance typically involves third-party certifications, such as ISO 27001 accreditation or SOC 2 reports, which validate database security controls through independent audits of policies, procedures, and implementations. Internal controls testing complements these by regularly evaluating database configurations against regulatory benchmarks to ensure ongoing adherence and identify gaps before external assessments.

Data Protection Techniques

Encryption Methods

Encryption methods in database security primarily focus on protecting data confidentiality through cryptographic techniques applied at rest, in transit, and in use. These approaches ensure that sensitive information remains unreadable to unauthorized parties, even if physical storage media is compromised or network traffic is intercepted. (TDE) represents a key mechanism for data at rest, encrypting database files without requiring application modifications, while Transport Layer Security (TLS) secures data in transit during client-server communications. For data in use, advanced schemes like enable computations on encrypted data, preserving privacy during processing.

Data at Rest Encryption

Data at rest encryption safeguards stored database files, logs, and backups against unauthorized access, such as theft of physical drives or insider threats. Full-disk encryption (FDE) protects entire storage volumes using tools like or , applying a single key to all data on a device for broad protection but potentially exposing non-database files if the system is booted. In contrast, field-level or column-level encryption targets specific data elements, such as sensitive columns in tables, using algorithms like AES to encrypt individual values while leaving metadata and indexes unencrypted for query efficiency. Transparent Data Encryption (TDE) implements database-level protection for data at rest in systems like Microsoft SQL Server and Oracle Database. In SQL Server, TDE performs real-time I/O encryption and decryption of the database files and transaction log using a Database Encryption Key (DEK) protected by a certificate or asymmetric key, ensuring transparency to applications with no code changes needed. Similarly, Oracle TDE encrypts tablespaces or specific columns, leveraging a master encryption key stored in a wallet or keystore, which automates encryption of data written to disk and decryption on read without altering SQL queries. These methods comply with standards like AES-256, a symmetric block cipher approved by NIST for securing electronic data.

Data in Transit Encryption

Protecting data in transit prevents or man-in-the-middle attacks during transmission between clients and database servers. TLS (formerly SSL) is the standard protocol for this, establishing an encrypted channel via a process where the client and server negotiate cipher suites, exchange certificates for , and derive session keys using asymmetric (e.g., RSA or ECDHE) before switching to symmetric encryption for the session. Database management systems like SQL Server, , and enforce TLS by configuring server certificates and requiring encrypted connections in client drivers, such as setting Encrypt=true in connection strings for SQL Server to force TLS 1.2 or higher. This ensures queries, results, and credentials are encrypted end-to-end, with overhead minimized through on modern processors.

Data in Use Encryption

Data in use encryption allows processing of encrypted information without decryption, addressing risks during active computation in memory. enables this by supporting arithmetic operations directly on ciphertexts, such that the result of a function on encrypted data yields an encryption of the function's output on plaintexts: Enc(f(m))=f(Enc(m))\text{Enc}(f(m)) = f(\text{Enc}(m)), where Enc\text{Enc} denotes encryption and ff is a permitted operation like or . Fully homomorphic schemes, building on Craig Gentry's 2009 lattice-based construction, permit arbitrary computations but remain computationally intensive for practical database queries, often limited to equality or range searches in specialized implementations. For example, MongoDB's Queryable Encryption feature in Atlas extends this for workloads, allowing equality queries on encrypted fields using deterministic encryption schemes integrated with client-side ; as of September 2025, it supports prefix, , and substring queries in public preview.

Key Management and Performance Considerations

Effective encryption relies on secure to generate, store, rotate, and revoke keys without exposing them to compromise. Hardware Security Modules (HSMs) provide tamper-resistant storage and cryptographic operations for database keys, integrating with TDE in and SQL Server via interfaces to offload key handling from software wallets. Standards like validate HSMs for compliance, ensuring keys such as AES-256 master keys are protected against extraction. Encryption introduces performance trade-offs, including CPU overhead for operations and increased I/O latency. Studies on SQL Server TDE report 2-15% degradation in transaction throughput and times, with CPU utilization rising by up to 8% under stress, though modern hardware with AES-NI instructions mitigates this to under 5% in many cases. In cloud environments like Atlas, at-rest adds negligible latency due to provider-managed . masking serves as a complementary, non-cryptographic technique for anonymizing in non-production environments, detailed further in data abstraction methods.

Data Abstraction and Masking

Data and masking are non-cryptographic techniques employed in database security to obscure sensitive information, enabling safe data usage in controlled environments while preserving the data's structural integrity and analytical utility. These methods pseudonymize personally identifiable information (PII) without altering the underlying , allowing applications to function as intended. Unlike , which provides irreversible protection suitable for production systems, masking and abstraction focus on usability in non-production settings. Data masking involves replacing sensitive data elements with realistic but fictional substitutes to prevent unauthorized exposure. Common techniques include replacement, where actual values such as Social Security numbers (SSNs) are swapped with generated fake equivalents that retain the original format (e.g., XXX-XX-1234); , which randomizes values within a while maintaining ; and tokenization, which substitutes data with unique identifiers that can map back to originals under controlled conditions. These approaches ensure that masked data remains viable for tasks like statistical analysis or application testing, as the obscured values mimic real data distributions without revealing confidential details. Abstraction layers provide another mechanism for concealing data by implementing context-aware access controls at the database level. In databases, Virtual Private Database (VPD) enforces row-level and column-level security through policies that dynamically append WHERE clauses to SQL queries based on user identity or session attributes, effectively hiding specific rows or columns from unauthorized viewers. For instance, a policy might restrict a developer to rows pertaining only to their assigned projects, abstracting away sensitive records without modifying the base tables. Database views serve a similar purpose by presenting abstracted subsets of , filtering out sensitive fields while allowing seamless querying. These techniques find primary application in development and testing environments, where full production datasets are often required but exposing PII poses significant risks. By masking or abstracting data, organizations can provision realistic test instances that support software validation and quality assurance without compromising privacy. Dynamic masking extends this to real-time scenarios, applying obfuscation on-the-fly during query execution to deliver redacted results to end-users, such as in analytics dashboards. Commercial tools facilitate implementation and ensure compliance with regulations like the General Data Protection Regulation (GDPR). InfoSphere Optim applies masking transformations across databases, files, and reports, supporting format-preserving substitutions to de-identify data in non-production workflows. Delphix, similarly, automates masking for virtualized test environments, enabling self-service access to compliant datasets that reduce the scope of GDPR applicability by excluding real PII from development cycles. These tools help mitigate breach risks in shared environments, aligning with requirements under Article 4 of GDPR. Despite their benefits, data abstraction and masking have limitations, particularly their unsuitability for production databases due to potential reversibility risks in techniques like tokenization, which could allow reconstruction of original if mapping keys are compromised. Over-masking may also degrade data utility, leading to inaccurate testing outcomes. As of 2025, advancements in AI-generated offer a complementary alternative, producing entirely fabricated datasets that statistically mirror real ones without any derivation from actual records, thereby eliminating re-identification risks while supporting privacy-preserving .

Implementation Practices

Security Procedures and Policies

Security procedures and policies form the foundational framework for organizations to systematically protect database environments from unauthorized access, data breaches, and other threats. These procedures establish standardized rules and processes that align with established security standards, ensuring consistent application across the database lifecycle. Developing robust policies begins with creating security baselines that mandate controls such as (MFA) for database administrators to verify user identities beyond passwords, thereby reducing the risk of credential compromise. Similarly, regular patch management is essential, involving the timely application of software updates to address known vulnerabilities in database management s, which helps prevent exploitation by attackers targeting outdated software. These baselines are typically derived from authoritative frameworks like NIST SP 800-53, which outlines controls for identification, , and system maintenance. Incident response procedures are critical components of database security policies, providing a structured approach to detecting, containing, and recovering from breaches. Upon identifying a potential incident, organizations must isolate affected database systems to limit further damage, followed by forensic analysis using audit logs to trace the breach's origin and scope. Notification timelines are governed by regulations such as the General Data Protection Regulation (GDPR), which requires controllers to report personal data breaches to supervisory authorities without undue delay and, where feasible, not later than 72 hours after becoming aware of the incident. These procedures, informed by NIST SP 800-61, emphasize preparation through predefined playbooks that detail roles, communication channels, and recovery steps to minimize downtime and data loss. The access management lifecycle ensures controlled provisioning and of database privileges throughout user tenures. During , organizations provision roles based on the principle of least privilege, granting only the minimum permissions necessary for job functions, such as read-only access for analysts. Offboarding involves immediate of privileges upon employee departure to prevent unauthorized post-termination access. Periodic reviews, conducted at least annually, evaluate and adjust access to align with current roles and detect any anomalies, as recommended in CIS Control 6 for management. This lifecycle approach, supported by NIST guidelines on identity management, helps maintain ongoing compliance and reduces risks. Backup and recovery security policies safeguard data integrity and availability by incorporating protective measures into routine operations. Backups must be encrypted to protect sensitive information in transit and at rest using strong cryptographic standards to prevent unauthorized decryption. Secure offsite storage, such as air-gapped or cloud-based repositories with access controls, ensures redundancy against physical or local threats. Organizations should test backups regularly, at least monthly for critical data, and review disaster recovery plans annually to validate restoration processes, confirming that databases can be recovered within defined recovery time objectives without data corruption. These practices, outlined in NIST SP 800-209, integrate with auditing mechanisms to verify the security of backup procedures. Training programs are integral to policy enforcement, fostering awareness among users and administrators to mitigate human-related vulnerabilities. These programs should cover risks such as attacks that could lead to credential theft and exploits targeting database inputs, emphasizing recognition and safe practices like input validation. Regular sessions, delivered annually or upon policy updates, equip personnel with skills to adhere to security baselines. Effectiveness can be measured through metrics like the reduction in misconfigurations. Aligned with CIS Control 14, these initiatives promote a culture of security vigilance. Implementing zero-trust architecture in database security involves verifying every access request regardless of origin, thereby eliminating implicit trust and reducing the risk of lateral movement by attackers. This approach mandates continuous authentication, least-privilege access, and micro-segmentation to protect sensitive data stores. Automating security within pipelines ensures that changes, configurations, and deployments undergo vulnerability scans, compliance checks, and secret management to prevent misconfigurations from reaching production. Conducting regular penetration testing simulates real-world attacks on database systems to identify weaknesses such as or unauthorized access paths, with tests recommended after significant updates or on a recurring basis such as annually. Enforcing (MFA) for all database connections adds layers of verification beyond passwords, incorporating possession-based tokens or inherence factors like to thwart credential theft. Integration with identity and access management (IAM) platforms, such as , enables adaptive MFA that assesses risk contextually, ensuring biometric options like fingerprint or facial recognition are seamlessly applied to database logins. Emerging trends in database security emphasize protections for cloud-native databases, where services like AWS RDS offer encryption for data at rest using AES-256, which must be enabled, alongside automated backups and fine-grained access controls to address shared infrastructure risks. AI and machine learning models trained on query logs enable proactive threat prediction through anomaly detection, identifying unusual patterns such as deviant access frequencies or injection attempts in real time. Blockchain technology enhances audit immutability by creating tamper-proof logs of database transactions, distributing records across nodes to prevent retroactive alterations and ensure verifiable compliance. Preparation for quantum-resistant encryption is accelerating, with organizations beginning to adopt NIST's standards released in 2024 and updated in 2025, including algorithms like ML-KEM for key encapsulation, to safeguard databases against future quantum threats over the coming decade. In March 2025, NIST selected HQC for further standardization in the fourth round of its process. The 2019 breach, which exposed over 100 million customer records in AWS due to a misconfigured , underscores the importance of the shared responsibility model in cloud security, where customers must actively manage access controls and monitoring despite provider safeguards.

References

  1. https://www.ibm.com/think/topics/database-security
  2. https://www.imperva.com/learn/data-security/database-security/
  3. https://www.paloaltonetworks.com/cyberpedia/database-security
  4. https://www.ibm.com/reports/data-breach
  5. https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/draft-en/03-appendices/05-glossary
  6. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-12r1.pdf
  7. https://www.techtarget.com/searchsecurity/definition/nonrepudiation
  8. https://dl.acm.org/doi/10.1145/358769.358784
  9. https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html
  10. https://owasp.org/www-project-top-ten/
  11. https://www.techtarget.com/searchsecurity/tip/Evaluate-cloud-database-security-controls-best-practices
  12. https://www.ibm.com/think/insights/83-percent-organizations-reported-insider-threats-2024
  13. https://gurucul.com/blog/insider-threat-report/
  14. https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection
  15. https://securosis.com/blog/database-denial-of-service-the-attacks/
  16. https://www.computer.org/publications/tech-news/trends/vulnerabilities-cybercriminals-exploit
  17. https://investor.equifax.com/news-events/press-releases/detail/237/equifax-releases-details-on-cybersecurity-incident
  18. https://medium.com/r3d-buck3t/privilege-escalation-with-mysql-user-defined-functions-996ef7d5ceaf
  19. https://www.sciencedirect.com/science/article/abs/pii/S0167404897876079
  20. https://www.ibm.com/think/insights/cybersecurity-trends-ibm-predictions-2025
  21. https://www.trendmicro.com/vinfo/us/security/news/threat-landscape/trend-micro-state-of-ai-security-report-1h-2025
  22. https://docs.oracle.com/cd/B19306_01/network.102/b14266/authoriz.htm
  23. https://learn.microsoft.com/en-us/sql/relational-databases/security/permissions-database-engine?view=sql-server-ver16
  24. https://learn.microsoft.com/en-us/sql/t-sql/statements/grant-object-permissions-transact-sql?view=sql-server-ver16
  25. https://dl.acm.org/doi/10.1145/344287.344301
  26. https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html
  27. https://csrc.nist.gov/glossary/term/least_privilege
  28. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
  29. https://www.idmanagement.gov/playbooks/pam/
  30. https://www.acc.com/sites/default/files/2021-02/Lessons%20Learned%20from%20the%20SolarWinds%20Hack.pdf
  31. https://www.varonis.com/blog/what-is-dam
  32. https://satoricyber.com/database-security/database-activity-monitoring-uses-features-and-how-to-choose/
  33. https://www.teradata.com/insights/data-security/what-is-data-activity-monitoring
  34. https://library.nagios.com/industry-insights/database-activity-monitoring/
  35. https://www.imperva.com/products/data-risk-analytics/
  36. https://docs.oracle.com/en/database/oracle/oracle-database/26/dbseg/introduction-to-auditing.html
  37. https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-database-engine?view=sql-server-ver17
  38. https://www.postgresql.org/docs/current/runtime-config-logging.html
  39. https://docs.oracle.com/en/database/oracle/oracle-database/21/sqlrf/AUDIT-Traditional-Auditing.html
  40. https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/create-a-server-audit-and-database-audit-specification?view=sql-server-ver17
  41. https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-action-groups-and-actions?view=sql-server-ver17
  42. https://www.oracle.com/a/tech/docs/dbsec/unified-audit-best-practice-guidelines.pdf
  43. https://www.oracle.com/docs/tech/dbsec/oracle-database-auditing-security-and-perf-best-practices.pdf
  44. https://www.first.org/cvss/v3-1/specification-document
  45. https://gdpr.eu/what-is-gdpr/
  46. https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
  47. https://www.pcisecuritystandards.org/standards/pci-dss/
  48. https://gdpr-info.eu/issues/encryption/
  49. https://www.cynet.com/cynet-for-compliance/gdpr-data-breach-notifications-everything-you-need-to-know/
  50. https://www.hhs.gov/hipaa/for-professionals/security/index.html
  51. https://www.pcisecuritystandards.org/documents/PCI_DSS-QRG-v3_2_1.pdf
  52. https://www.imperva.com/resources/datasheets/WP_SOX_compliance.pdf
  53. https://www.varonis.com/blog/sox-compliance
  54. https://www.isms.online/iso-27002/control-8-15-logging/
  55. https://digital-strategy.ec.europa.eu/en/policies/nis2-directive
  56. https://cppa.ca.gov/announcements/2025/20250923.html
  57. https://gdpr-info.eu/issues/fines-penalties/
  58. https://dataprivacymanager.net/5-biggest-gdpr-fines-so-far-2020/
  59. https://www.bsigroup.com/globalassets/localfiles/en-us/whitepapers/Information%2520Security/bsi-whitepaper-hipaa-iso-iec-27001.pdf
  60. https://sprinto.com/blog/compliance-standards/
  61. https://auditboard.com/blog/sox-compliance
  62. https://www.imperva.com/learn/data-security/data-encryption/
  63. https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption?view=sql-server-ver17
  64. https://docs.oracle.com/en/database/oracle/oracle-database/26/dbtde/introduction-to-transparent-data-encryption.html
  65. https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-sql-server-encryption?view=sql-server-ver17
  66. https://eprint.iacr.org/2009/616
  67. https://www.mongodb.com/company/blog/product-release-announcements/mongodb-announces-queryable-encryption
  68. https://www.mongodb.com/company/blog/product-release-announcements/queryable-encryption-expands-search-power
  69. https://docs.aws.amazon.com/cloudhsm/latest/userguide/oracle-tde.html
  70. https://csrc.nist.gov/projects/cryptographic-module-validation-program
  71. https://journalofbigdata.springeropen.com/articles/10.1186/s40537-021-00520-z
  72. https://www.mongodb.com/docs/atlas/reference/faq/security/
  73. https://docs.oracle.com/en/cloud/paas/data-safe/udscs/data-masking-overview.html
  74. https://www.ibm.com/products/infosphere-optim-data-privacy
  75. https://docs.oracle.com/database/121/DMKSB/intro.htm
  76. https://www.ibm.com/docs/en/iotdm/11.3.0?topic=data-overview-optim-privacy-application
  77. https://www.sia-partners.com/en/insights/publications/data-masking-challenges-and-opportunities
  78. https://docs.oracle.com/en/database/oracle/oracle-database/26/dbseg/using-oracle-vpd-to-control-data-access.html
  79. https://aws.amazon.com/what-is/data-masking/
  80. https://www.tripwire.com/state-of-security/introduction-data-masking-privacy-engineering
  81. https://www.k2view.com/blog/data-masking-use-cases/
  82. https://www.perforce.com/solutions/data-compliance
  83. https://web-assets2.delphix.com/f/137721/x/a82761ee54/delphix_guide-to-data-masking_2023.pdf
  84. https://www.preemptive.com/blog/data-masking-vs-data-obfuscation/
  85. https://pathlock.com/learn/data-masking-vs-tokenization/
  86. https://www.k2view.com/blog/best-synthetic-data-generation-tools/
  87. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf
  88. https://gdpr-info.eu/art-33-gdpr/
  89. https://www.cisecurity.org/controls/cis-controls-list
  90. https://csrc.nist.gov/pubs/sp/800/63/b/upd2/final
  91. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-209.pdf
  92. https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf
  93. https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html
  94. https://www.ibm.com/think/topics/penetration-testing
  95. https://www.okta.com/products/adaptive-multi-factor-authentication/
  96. https://www.okta.com/identity-101/biometrics-secure-authentication/
  97. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html
  98. https://aws.amazon.com/blogs/machine-learning/efficiently-build-and-tune-custom-log-anomaly-detection-models-with-amazon-sagemaker/
  99. https://pmc.ncbi.nlm.nih.gov/articles/PMC7372773/
  100. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
  101. https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization
  102. https://www.bitsight.com/blog/cloud-security-lessons-learned-from-capital-one-data-breach
Add your contribution
Related Hubs
User Avatar
No comments yet.