Meet GLBA compliance requirements for SQL Server


What is GLBA

The Gramm – Leach – Bliley Act (GLBA) was enacted in 1999. Its purpose is to protect consumer financial privacy. In order to meet GLBA compliance requirements, the financial organizations must inform their customers about the company’s information sharing and privacy practices. Customers must be given and explained their right to opt out (to say “no”) – if they don’t want their financial information shared with certain third parties

GLBA consists of three major components: Financial Privacy Rule (protects the privacy of consumer/customer information), Safeguards Rule (requirements for customer record and information security), and Pretexting Protection (preventing unauthorized access to sensitive data)

Who has to comply with GLBA?

GLBA compliance is mandatory for all financial institutions – insurance companies, banks, credit unions, and companies that offer financial products or services like loans, financial or investment advice, etc.

What is GLBA meant to ensure?

GLBA is created to ensure confidentiality, integrity, and availability of sensitive customer financial information.

How is GLBA compliance verified?

GLBA compliance is verified through periodic assessments. The organizations have to prove that access to data is secured and controlled strictly. Banks are required to present an annual GLBA compliance report to the Board of Directors.

How does GLBA affect IT?

The GLBA section 501 addresses protection of information

“501. PROTECTION OF NONPUBLIC PERSONAL INFORMATION.

  1. PRIVACY OBLIGATION POLICY.—It is the policy of the Congress that each financial institution has an affirmative and continuing obligation to respect the privacy of its customers and to protect the security and confidentiality of those customers’ nonpublic personal information.
  2. FINANCIAL INSTITUTIONS SAFEGUARDS.—In furtherance of the policy in subsection (a), each agency or authority described” 1

In other words, it’s necessary to ensure a secure and controlled environment.

The best practice to make SQL Server secure is to enforce strict access rules for the users. Once security setting is completed, audit all events, especially permission changes and access to the tables that store sensitive nonpublic personal records. Any tempering or modification by an unauthorized person must be investigated and prevented. Unprivileged access to sensitive records can bring to data leak and risking a GLBA compliance failure.

How to audit a SQL Server instance

When auditing a SQL Server instance, it’s important to audit the events on the SQL Server instance, database, and object level. All security changes, access, and activity on the tables that store nonpublic personal information must be audited. Audited information should be easily queried for reporting. Also, if the captured events take too much hard disk space, they should be archived and used later for reporting.

ApexSQL Audit is a SQL Server auditing tool that provides a variety of options for auditing SQL Server events, ensures compliance with policies, and monitors SQL Server security by tracking permission, login, and password changes. It has a range of built-in reports, commonly needed for compliance auditing.

ApexSQL Audit can help with GLBA compliance, as it:

  • Monitors SQL Server instance, database, and object events
  • Generates reports for compliance reviews
  • Generates reports that show potential security threats
  • Identifies potential tampering that can lead to incomplete auditing and compliance failure

The ApexSQL Audit reports that help with GLBA compliance

To keep the secured environment under control, create audit reports regularly. That way, you will be aware of any security threats or compliance challenges, and be able to act and fix them quickly.

If database auditing is set properly, it shouldn’t be changed without proper documentation. If the auditing is not set properly, daily auditing reports will indicate a problem and you will be able to fix it on time, before jeopardizing GLBA compliance or causing inconvenience to any customers.

The Audit settings history report shows the changes made to the auditing settings – databases, event types, and tables added or excluded from auditing. If auditing is set properly and the auditing reports don’t indicate the auditing parameters should be modified, any auditing settings modification should be investigated:

Audit settings history report in ApexSQL Audit

The Security configuration history report shows all changes on the security entities (logins, users, and roles) including entities created or dropped, permissions granted/denied, name, and password changes. Any suspicious changes, especially new user creations, permission grants, and password resets are an alert for a deeper investigation:

Security configuration history report

The Complete audit trail shows all events on the SQL Server instance, its databases, and objects. It’s not a report needed every day, but occasionally it would be good to have insight into all that’s going on:

The Activity per object report

The Access history report shows who accessed what, when, how, and what procedures and statements were executed. If the users have been granted more than minimal privileges and perform any activities on the objects they shouldn’t, this report will help identify these users and activities:

Access history per user report

The Permission changes report shows all permission changes on a specific security entity. Any undocumented permission grants can be a potential security threat:

The Permission changes per object report

The Unauthorized access report shows all unsuccessful login attempts on a SQL Server instance, due to nonexistent logins or wrong passwords:

ApexSQL Audit - Unauthorized access report

Unlike the Unauthorized access report that shows only the unsuccessful login attempts, the Logon activity history report shows both successful and failed login attempts. For each attempt, the login name, time, server, application, computer name, and status are shown:

The Role history report

Being compliant with GLBA implies SQL Server security and auditing. Security must be set to protect sensitive customer information and ensure data accuracy. Auditing helps DBAs make sure that the security settings are enforced and no unexpected events occur on their system, and it provides reports necessary for GLBA compliance verification. Use ApexSQL Audit to audit events on SQL Server instances, databases, and objects and to comply with GLBA

Useful resources
Federal Trade Commission
GLBA Compliance: How to Avoid Common Traps
Federal Deposit Insurance Corporation

October 2, 2013