by Robert Buda | Aug 10, 2021 | Database Security, MariaDB, MySQL
Long a cornerstone of data security, encryption is becoming more important than ever as organizations come to grips with major trends like teleworking, privacy mandates and Zero Trust architectures. To comprehensively protect data from the widest possible range of threats and meet the demands of these new use cases, you need two fundamental encryption capabilities:
- The ability to encrypt sensitive data “at rest”—that is, where it resides on disk. This is a critical security capability for many organizations and applications, as well as a de facto requirement for compliance with privacy regulations like HIPAA, GDPR and CCPA. PCI DSS also requires that stored card data be encrypted.
- Encrypting data “in transit” across private and public networks. Common examples include using the HTTPS protocol for secure online payment transactions, as well as encrypting messages within VPN tunnels. Zero Trust further advocates encrypting data transmitted over your internal networks, since your “perimeter” is presumed to be compromised.
MySQL and MariaDB each support “at rest” and “in transit” encryption modalities. They both give you the ability to encrypt data at rest at the database level, as well as encrypting connections between the MySQL or MariaDB client and the server.
MySQL database-level encryption
MySQL has offered strong encryption for data at rest at the database level since MySQL 5.7. This feature requires no application code, schema or data type changes. It is also straightforward for DBAs, as it does not require them to manage associated keys. Keys can be securely stored separate from the data and key rotation is easy.
MySQL currently supports database-level encryption for general tablespaces, file-per-table tablespaces and the mysql system tablespace. While earlier MySQL versions encrypted only InnoDB tables, newer versions can also encrypt various log files (e.g., undo logs and redo logs). Also, beginning with MySQL 8.0.16, you can set an encryption default for schemas and general tablespaces, enabling DBAs to control whether tables are encrypted automatically.
MySQL database-level encryption is overall secure, easy to implement and adds little overhead. Among its limitations, it does not offer per-user granularity, and it cannot protect against a malicious root user (who can read the keyring file). Also, database-level encryption cannot protect data in RAM.
MySQL Enterprise Transparent Data Encryption
In addition to the generic database-level encryption just discussed, users of “select Commercial Editions” of MySQL Enterprise can also leverage Transparent Data Encryption (TDE). This feature encrypts data automatically, in real-time, before writing it to disk; and decrypts it automatically when reading it from disk.
TDE is “transparent” to users and applications in that it doesn’t require code, schema or data type changes. Developers and DBAs can encrypt/decrypt previously unencrypted MySQL tables with this approach. It uses database caching to improve performance and can be implemented without taking databases offline.
Other MySQL Enterprise Encryption Features
Besides TDE, MySQL Enterprise Edition 5.6 and newer offers encryption functions based on the OpenSSL library, which expose OpenSSL capabilities at the SQL level. By calling these functions, mySQL Enterprise applications can perform the following operations
- Improve data protection with public-key asymmetric cryptography, which is increasingly advocated as hackers’ ability to crack hashed passwords increases
- Create public and private keys and digital signatures
- Perform asymmetric encryption and decryption
- Use cryptographic hashes for digital signing and data verification/validation
MariaDB database-level encryption
MariaDB has supported encryption of tables and tablespaces since version 10.1.3. Once data-at-rest encryption is enabled in MariaDB, tables that are defined with ENCRYPTED=YES or with innodb_encrypt_tables=ON will be encrypted. Encryption is supported for the InnoDB and XtraDB storage engines, as well as for tables created with ROW_FORMAT=PAGE (the default) for the Aria storage engine.
One advantage of MariaDB’s database-level encryption is its flexibility. When using InnoDB or XtraDB you can encrypt all tablespaces/tables, individual tables, or everything but individual tables. You can also encrypt the log files, which is a good practice.
Encrypted MariaDB data is decrypted only when accessed via the MariaDB database, which makes it highly secure. A potential downside is that MariaDB’s encryption adds about 3-5% data size overhead.
This post explains how to setup, configure and test database-level encryption in MariaDB. For an overview of MariaDB’s database-level encryption, see this page in the knowledgebase.
Encrypting data “in transit” with MySQL
To avoid exposing sensitive data to potential inspection and exfiltration if your internal network is compromised, or if the data is transiting public networks, you can encrypt the data when it passes between the MySQL client and the server.
MySQL supports encrypted connections between the server and clients via the Transport Layer Security (TLS) protocol, using OpenSSL.
By default, MySQL programs try to connect using encryption if it is supported on the server; unencrypted connections are the fallback. If your risk profile or regulatory obligations require it, MySQL lets you make encrypted connections mandatory.
Encrypting data in transit with MariaDB
By default, MariaDB does not encrypt data during transmission over the network between clients and the server. To block “man-in-the-middle” attacks, side channel attacks and other threats to data in transit, you can encrypt data in transit using the Transport Layer Security (TLS) protocol—provided your MariaDB server was compiled with TLS support. Note that MariaDB does not support older SSL versions.
As you might expect, there are multiple steps involved in setting up data-in-transit encryption, such as creating certificates and enabling encryption on the client side. See this page in the MariaDB knowledgebase for details.
Conclusion
With data security being an increasing business and regulatory concern, and new use cases like teleworking and privacy compliance becoming the norm, encryption will certainly be used to secure more and more MySQL and MariaDB environments.
If you’d like a “second opinion” on where and how to implement encryption to address your business needs, contact Buda Consulting for a free consultation on our database security assessment process.
If you like this article, please share it with your colleagues and subscribe to our blog to get the latest updates.
by Robert Buda | Jun 29, 2020 | Database Patch News
Welcome to Database Patch News, Buda Consulting’s newsletter of current patch information for Oracle and Microsoft SQL Server. Here you’ll find information on available patches—including security patches—and desupported versions recently made available.
Why should you care about patching vulnerabilities and bugs? Two big reasons:
-
- Unpatched systems are a top cyber attack target. Patch releases literally advertise vulnerabilities to the hacker community. The longer you wait to patch, the greater your security risk.
- Along with running a supported database version, applying the latest patches ensures that you can get support from the vendor in case of an issue. Patching also helps eliminate downtime and lost productivity associated with bugs.
Here are the latest patch updates for Oracle and SQL Server:
Oracle Patches:
Apr 14 2020 Quarterly Patch Updates:
19c – Release Update 19.7 available.
18c – Release Update 18.10 available.
12.2.0.1 – APR 2020 Release Update 12.2.0.1.200414 available
Regular support ends Mar 2023 and extended support ends Mar 2026.
12.1.0.2 – Currently in extended support.
The last freely available patch was July 2019 for 12.1.0.2.
Apr 14 2020 PSU available but requires extended support purchase to access it.
Patches will be released until July 2021 for this version.
PATCH SET UPDATE 12.1.0.2.200414 available.
11.2.0.4 – Entered extended support December of 2017
Last free available patch was October 2018 for 11.2.0.4.
PATCH SET UPDATE 11.2.0.4.200414 available but requires extended support
purchase to access it.
SQL Server Patches:
SQL Server 2019
Cumulative update 3 (Latest build) Released March 12, 2020
Mainstream support ends Jan 7, 2025
Extended support ends Jan 8, 2030
SQL Server 2017
Cumulative update 20 (Latest build) Released Apr 7, 2020
Mainstream support ends Oct 11, 2022
Extended support ends Oct 12, 2027
SQL Server 2016 Service Pack 2
Cumulative update 12 Release date: Feb 25, 2020
Mainstream support ends Jul 13, 2021
Extended support ends Jul 14, 2026
SQL Server 2014 Service Pack 3
Cumulative update 3 Release date: Apr 16, 2019
Mainstream support ended Jul 9, 2019
Extended support ends Jul 9, 2024
SQL Server 2012 Service Pack 4
Release date: Oct 5, 2017
Mainstream support ended Jul 11, 2017
Extended support ends Jul 12, 2022
Note: All other SQL Server versions not mentioned are no longer supported.
by Robert Buda | Mar 3, 2020 | Best Practices, Database Security, Oracle DBA
Managed Health Systems of Indiana patient health information, July-September, 2019; Microsoft customer service and support records, January 22, 2020; Wyze email addresses, December 30, 2019; Georgia Tech student data, March 2019.
What do all of these breaches have in common? The data that was stolen was inside a database.
Yet when most companies think about data security, they still focus on securing the network, and spend very little time and energy making sure the databases—where the data actually lives—are safe.
When was the last time you had a network security assessment done? If yours is like most companies, it was pretty recently… and that’s good.
But when was the last time you had a database security assessment done? If yours is like many companies, the answer is “Never.”
Even if your network security posture is robust, it is only a matter of time before your network is breached. And don’t forget about “insider threats,” both malicious and accidental. It is best to add another layer of protection between the bad actors and your data.
Make sure that when cybercriminals do get past your network protections, your database will keep them out.
Download our Database Security Roadmap get valuable insights into create an in-depth defensive posture to protect your data.
by Robert Buda | Nov 21, 2019 | Oracle, Oracle DBA
Oracle offers various authentication and audit features to protect data from unauthorized access. But what about data at rest in operating system files, backups or other storage media?
Protect Oracle Data At Rest With TDE
To protect data at rest, Oracle offers Transparent Data Encryption (TDE). With TDE you can encrypt sensitive data so that it is unreadable if the file it is stored in is exfiltrated or breached.
Data you encrypt with TDE is “transparently” decrypted when it is accessed by authorized users and applications. That is, decryption takes place without users even being aware that data is encrypted. Likewise, applications that process sensitive data can offer data encryption via TDE with little or no code changes.
Why use TDE? It helps ensure that your sensitive data is secure, supports compliance with a wide range of regulations like Sarbanes-Oxley (SOX), HIPAA and PCI, and can simplify your overall encryption/decryption policy and operations.
Another benefit of TDE is that it is pretty fine-grained. You can encrypt data at the column level or the tablespace level. Column-level encryption is perfect for confidential data like social security numbers or credit card numbers that are stored in table columns.
When you encrypt a tablespace, all objects created in that tablespace are encrypted automatically. Tablespace level encryption works well for tables that store sensitive data in multiple columns, or for when you want to protect an entire table and not just individual columns. It’s also handy anytime you want to avoid doing a nitty-gritty analysis of each table column to determine which ones require encryption.
To enable decryption and prevent unauthorized decryption, TDE uses a two-tiered, key-based encryption architecture. It stores encryption keys in a keystore, a hardware or software security module separate from the database. You can centrally (and automatically) manage these keystores using Oracle Key Vault.
To encrypt a tablespace, TDE uses an externally stored master key to encrypt the TDE tablespace encryption key, which is used to encrypt/decrypt tablespace data. For column-level encryption, Oracle transparently accesses a TDE master encryption key to encrypt or decrypt the TDE table key, which then encrypts/decrypts column-level data in the table.
Encryption Best Practices
Of course, your encryption strategy should be integrated with your overall information security program. Best-practice security tips related to encryption include:
-
-
- Start by determining how sensitive the data is. Data that requires the strongest protection can be encrypted using the AES256 algorithm. Conversely, you can encrypt less sensitive data in several ways that offer performance benefits.
- You also need to determine your approach to keystore protection based on data sensitivity. Options range from auto-login software keystores to hardware keystores. A separate keystore for TDE only is ideal if possible.
- To limit damage from compromised admin credentials or insider threats, consider assigning separate security admins for TDE and for the database(s).
- Backup your sensitive data using protected backup procedures.
- Be aware that column-level encrypted data is decrypted during expression evaluation and could potentially be accessed in the associated on-disk swap file.
- Also be aware that your Oracle data files could contain plaintext fragments (aka “ghost records” that were deleted logically from the table but still exist physically on-disk. These could potentially be accessed similarly to finding data on-disk after it has been deleted at the operating system level.
For more information on TDE, see the Oracle Advanced Security Guide online.
For expert help and guidance with encryption, backup/recovery, high availability and other business continuity and security concerns, contact Buda Consulting for a security risk assessment—the first step to finding and closing the gaps in your database security.
by Robert Buda | Feb 19, 2015 | Database Security, Oracle DBA
Unless you’ve been in suspended animation for the past few years, you know that major government agencies and global enterprises are hacked with numbing regularity despite their best efforts to defend themselves. Whether from nation states, cybercriminals or disgruntled staff, your Oracle databases are vulnerable to similar attack.
In most organizations, two-thirds of sensitive and regulated data resides in databases. Those databases represent your organization’s “crown jewels,” yet they may as exposed as if they were left on a shelf for anyone “passing by” (inside your firewall) to read, change or delete.
If you think the perimeter defenses securing your network, IT systems and endpoints are enough—think again. You need a multilayered security strategy that includes specific protection for your sensitive data. Otherwise it’s only a matter of time before it is compromised.
Hackers can steal passwords and pose as administrators, or exploit legitimate data access via SQL injection attacks on vulnerable applications, to cite but two examples of how breaches are routinely accomplished. According to Verizon’s 2014 Data Breach Investigations Report, databases are frequently targeted in many types of attack patterns. Further, when databases are breached a significant percentage of records tend to be compromised.
A database security strategy is a plan to mitigate risk to your data. It should define and identify security objectives and controls to meet those objectives, as well as metrics to test and manage the controls. By thinking in terms of risk—how much exists and how much you can tolerate—you can proactively address the biggest issues first and minimize risk exposure given the resources available. Remember, the cost of risk mitigation is almost always a drop in the bucket compared with the cost of a breach.
How best to protect your Oracle databases? Here is an overview the top approaches:
- Data segmentation. Keep high-value data separate from less sensitive data, so you can prioritize managing the risk to it and put the protection where it will do the most good. SMBs are notoriously neglectful of this critical strategy.
- Database encryption. Encryption (combined with effective key management) make it much difficult for attackers to exploit ill-gotten access to your data.
- Control configurations. This one is easy! First, make sure you’re not using default admin passwords (which is incredibly common). Second, eliminate test databases from production database servers.
- Patch management. Exploitation of well-known vulnerabilities in database software is a major way that hackers steal data. Vulnerability scanning is an excellent way to plug those holes.
- Identity management. Role-based access controls and account revocation are first steps in making sure that only those who currently need access to your data can get it.
- Security-conscious web application development. Blocking SQL injection vulnerabilities in your web apps will greatly reduce the risk of Oracle database breaches.
Because many IT security professionals aren’t well versed in Oracle database security issues, this tasks often falls on DBAs—who frequently don’t know much about it, either.
How vulnerable are your Oracle databases? Are you facing more risk than you know? A database security assessment is a worthwhile and cost-effective way to review your database security policies, audit and report on vulnerabilities, and get started with a plan to mitigate the key vulnerabilities.
To talk over how a database security assessment could help your organization reduce financial and reputational risk by protecting your Oracle databases, contact Buda Consulting.
