Introduction

PCI-DSS is a security standard published by credit card companies (PCI is the Payment Card Industry, and DSS stands for Data Security Standard). It is a mandatory requirement for anyone processing credit cards.

PCI-DSS version 4.0.1 is an almost 400-page document, so this article isn’t replacing it. But we help translate PCI-DSS to practical implementation steps in Oracle and SQL Server databases to help you understand what you need to do. We suggest best practices, methodologies, and solutions to help you comply.

The scope of this article: This article addresses duties performed by the DBA team and not for network administrators, application developers, etc. It assumes the database is configured and used in a typical way, is not accessible from the internet, and ideally, on an internal secure network. We also don’t address database-related application requirements like what data to store or how long to retain it.

The Best Practices at the end summarizes everything you need to do.

The Requirements

Unlike most compliance regulations, PCI-DSS has precise requirements. However, these requirements encompass everything in the IT environment, including networks, servers, databases, applications, etc.

Since not all the requirements apply to databases, this article addresses only the ones relevant to Oracle or SQL Server databases. These are requirements 2, 3, 6, 7, 8, 10, and 11.

Requirement 2: Secure Configurations

Requirement 2 is about changing default configurations that may assist an attacker in compromising the system. That is especially important for default passwords:

“Malicious individuals, both external and internal to an entity, often use default passwords and other vendor default settings to compromise systems. These passwords and settings are well known and are easily determined via public information.

Applying secure configurations to system components reduces the means available to an attacker to compromise the system. Changing default passwords, removing unnecessary software, functions, and accounts, and disabling or removing unnecessary services all help to reduce the potential attack surface.”

Oracle and SQL Server are pretty secure out-of-the-box. They also force you to set custom administrator passwords upon installation. The only improvement needed is turning on network encryption. Or more accurately, making encryption a server-side requirement since clients can always choose to encrypt connections.

That is a good place to start, but your database is not brand-new straight out of the box. That means you’ll need to ensure you didn’t change the default configuration to be less secure.

For example, after installation, Oracle databases contain many accounts in an “EXPIRED & LOCKED” status. These are users like Scott/tiger, hr/hr, and more. These accounts have a default password and can be unlocked, creating a security vulnerability. You should look through the list of accounts, identify ones not in active use, and disable them. You can get the list of accounts and their status using a SQL like:

select username, account_status from dba_users;

Core Audit is a powerful solution that will help identify all the configured accounts in your database and which accounts are active.

SQL Server has different challenges due to the many extra optional features you can install. While not always realistic, you should aim to remove unused features. Also, if possible, disable xp_cmdshell.

Another pitfall in all databases is applications you installed that require an account. You must ensure those are not using a default password. That includes monitoring applications, tuning software, business software, and more.

Requirement 3: Stored Cardholder Data

Requirement 3 is about protecting the storage of cardholder information:

“Protection methods such as encryption, truncation, masking, and hashing are critical components of account data protection. If an intruder circumvents other security controls and gains access to encrypted account data, the data is unreadable without the proper cryptographic keys and is unusable to that intruder… For example, methods for minimizing risk include not storing account data unless necessary, truncating cardholder data if full PAN is not needed.”

Encryption is a built-in feature in both SQL Server and Oracle Databases. It’s called TDE (Transparent Data Encryption) and you must configure it on any database that contains cardholder data.

If you have cardholder data outside of production, you must use Static Data Masking to remove it. The challenge with masking is that the masked data must not only hide the cardholder data (as required by PCI-DSS) but also deliver the expected results. For example, in the case of QA and development systems, testing with the masked data must deliver results similar to testing with the original data. Achieving effective masking isn’t trivial and we recommend using Core Masking from Blue Core Research.

Requirement 6: Secure Software

Requirement 6 is about installing Patches:

“Actors with bad intentions can use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor provided security patches, which must be installed by the entities that manage the systems. All system components must have all appropriate software patches to protect against the exploitation and compromise of account data by malicious individuals and malicious software.”

Installing database patches is usually a challenge. That’s because they are not always compatible with the software. They also require testing in non-production and downtime in production to get them installed.

The good news is that while Oracle releases countless patches, this requirement only relates to security patches. SQL Server has more security-related patches and those must be installed.

Additionally, remember that you must also patch all the software used on the database including administration, tuning, monitoring, and all other applications and tools.

Requirement 7: Restrict Access to Cardholder Data

Requirement 7 is about Minimizing Privileges:

“Unauthorized individuals may gain access to critical data or systems due to ineffective access control rules and definitions. To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.”

This is a similar challenge in both Oracle and SQL Server. You must reduce permissions and privileges as much as possible. Pay special attention to users with the DBA role, sensitive privileges (like ALTER USER or the “ANY” privileges in Oracle), and permissions related to tables and columns with cardholder data.

Using Core Audit Level 1 can help identify these types of privileges and permissions to help you comply.

Requirement 8: Individual Accounts

Requirement 8 is about having Individual Accounts (no shared accounts):

“Two fundamental principles of identifying and authenticating users are to 1) establish the identity of an individual or process on a computer system, and 2) prove or verify the user associated with the identity is who the user claims to be.

Identification of an individual or process … is conducted by associating an identity with … an identifier … (also referred to as “accounts”) … assigning unique identification … to distinguish one user or process from another. … ensures there is accountability for actions performed by that identity. When such accountability is in place, actions taken can be traced to known and authorized users and processes.

The element used … verify the identity is known as the authentication factor. Authentication factors are 1) … a password …, 2) … a token device or smart card, or 3) … a biometric element.”

Databases usually have individual accounts. The exceptions are some administration accounts (SYS and SYSTEM in Oracle and, possibly, SA in SQL Server) and the application account. You must ensure this is the case.

This requirement also includes directions regarding password policies like strong passwords (12 characters with numbers and letters), not reusing passwords, account lockouts, etc.

Requirement 10: Log and Monitor All Access

Requirement 10 is about Activity Auditing:

“Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs … allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is difficult, if not impossible, without system activity logs.”

Database auditing is a challenge in both SQL Server and Oracle databases. The problem is that using built-in database auditing features creates a significant performance overhead while failing to conform to some aspects of Requirement 10 (like securing log data).

We have full articles reviewing the options of Oracle and SQL Server auditing. The bottom line is that we recommend using Core Audit as it can capture all the activity with negligible overhead, secure the audit trail, generate the needed reports and alerts, and more.

In terms of what to audit, you’d probably need to audit at least all DBA activity and all accesses to tables containing cardholder data.

Requirement 11: Test Security of Systems Regularly

Requirement 11 is about Vulnerability Scanning and Pentesting (Penetration Testing):

“Vulnerabilities are being discovered continually by malicious individuals and researchers, as well as being introduced by new software. System components, processes, and bespoke and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.”

There are many solutions that scan for vulnerabilities and they rarely find anything significant in most databases. The reason is that it’s unlikely to penetrate a modern database without credentials. Similarly, an internal or external pentest is unlikely to reveal anything new.

However, you are required to go through these steps, and there is value in doing it given the nature of security – there’s always a hole just waiting to be found.

Best Practices

1. Scope. The first step in PCI-DSS compliance is reducing the scope of databases, servers, and networks that contain cardholder data. If a SQL Server instance contains multiple databases and one of those contains cardholder data, then the entire instance is subject to PCI-DSS. The database must also not be directly connected to the internet, ideally on an internal secure network. Isolating cardholder data to databases, servers, and networks that contain little else will significantly reduce your compliance effort.
2. Accounts. There are several steps in securing accounts, and they need to be redone at least every six months.
   • Account Inventory. Make a list of all database accounts, identify the individuals or applications associated with those accounts, and determine which are still active. We recommend using Core Audit.
   • Inactive Accounts. Close or disable all inactive accounts.
   • Individual Accounts. Ensure all the accounts are individual accounts (except shared built-in administrative accounts, and application accounts).
   • Least Privileged. Ensure all accounts have the minimal permissions required for the individuals to perform their tasks. In particular, there must be significant access restrictions to cardholder data (ideally only the application and DBAs).
3. Passwords.
   • Default Passwords. Ensure none of the accounts have a default password. When in doubt, change the password.
   • Password Policy. Strong passwords (12 characters with numbers and letters), not reusing passwords (at least 4), account lockouts (no more than 10 attempts and lockout for at least 30 minutes).
4. Encryption. Turn on network encryption and disk encryption (TDE – Transparent Data Encryption).
5. Masking. Use Static Data Masking to mask cardholder data outside of production. We recommend using Core Masking. You should, in general, ensure all copies of cardholder data outside of the production database (like backups, exports, etc.) are masked or encrypted.
6. Patches. Install all security patches for the database and all associated software. That is an ongoing activity.
7. Auditing. Audit failed logins, DBA activity, access to tables containing cardholder data, and DCLs (account-related DDLs). We recommend using Core Audit.
8. Vulnerability Scans and Pentesting. Perform internal and external vulnerability scans (there are solutions that do this), and perform penetration testing (there are certified external companies you must hire to do this).

Summary

PCI-DSS follows standard security practices, especially when it comes to databases. While you can always do more, these steps are essential to keeping data safe and should be followed in any environment that contains sensitive data.