GLBA Compliance for SQL Server DBAs

The Gramm – Leach – Bliley Act (GLBA) is a security and privacy regulations standard created with a purpose to protect consumer financial privacy. To meet GLBA compliance requirements customers must be informed by the financial organizations about the organization’s information privacy and sharing practices. The customers must be provided with explanations about their rights and unambiguous option to deny their financial information to be shared with any third parties.

The GLBA compliance is required for any financial institution – banks, credit unions, insurance companies, and institutions that provides financial services or products like financial advices, loans, etc.

GLBA specifies only what the requirements are, not how to achieve them. The requirements are to ensure the confidentiality, integrity, and availability of sensitive customer financial information, but it’s not explained how to do that. Additionally, GLBA compliance is periodically verified trough procedures that evaluate the effectiveness and identify potential weaknesses of a financial institution’s security program.

General recommendations

The following actions are generally recommended in order to accomplish GLBA compliance:

• Ensure the security and confidentiality of customer information by using adequate user permissions and limitations, and audit permission changes
• “Identify the organizational unit and personnel responsible for performing the functions of a security response center
• Evaluate the adequacy of automated tools to support secure configuration Management, security monitoring, policy monitoring, enforcement, and reporting
• Determine that administrator or root privilege access is appropriately monitored
• Determine whether logs of security-related events are appropriately secured against unauthorized access, change, and deletion for an adequate time period, and that reporting to those logs is adequately protected
• Determine whether access to utilities on the host are appropriately restricted and monitored” [1]
• Audit and report access permission changes performed by administrative staff. Using SQL Server Roles, this recommendation can be fine-tuned and achieved by permitting access to sensitive information to adequate users only.
  When it comes to the audited information, any tampering or modification must be restricted, to both external attackers and members of the admin role. In addition, such attempts must be logged, investigated, and prevented in the future.
• Protect from potential threats and hazards to the security or integrity, using firewalls, antivirus programs, or device/system default logins and passwords. Do not use system supplied user and/or passwords defaults, and other security parameters in SQL Server. If the system creates or manages authentication credentials, such procedures must be changed in order to avoid default user/passwords being enforced. It’s recommended to use the Windows password policy for accessing SQL Server, thus enabling check against password minimum length, password history (e.g. a password cannot be used if previously used), the password minimum and maximum life, and login lockout if login failed continuously for certain number of times.
• Protect against unauthorized access to the confidential customer information that could result in substantial damage, inconvenience to any customer, and losing system compliance by logging all changes on user accounts and tracking failed logins.

A secure and controlled SQL Server environment needs to be set up and maintained to comply GLBA regulations.

SQL Server can be secured by enforcing users to follow access rules that are strict and unchangeable by unauthorized parties. Once security rules are set, audit all security related events, especially permission changes and access to the nonpublic sensitive data – both on database and table levels.

Recommendations for auditing/tracking on SQL Server

When auditing a SQL Server instance, it’s mandatory to audit all security related events on the SQL Server instance, database, and object level in order to comply with GLBA regulations. All activities, access, and security changes on the databases and tables that store personal nonpublic information must be audited. Such information should be easily queried for reporting and available on auditor’s demand.

ApexSQL Audit is a SQL Server auditing and compliance tool that can audit a range of SQL Server events, ensure compliance with regulations, and track SQL Server security by monitoring login, password, and permission changes. It provides built-in reports feature, commonly needed for GLBA compliance auditing.

ApexSQL Audit can help with GLBA compliance, as it:

• Automatically monitors SQL Server instance, database, and object events to make sure compliance rules are met
• Provides accurate and relevant reports for compliance reviews
• Provides reports that show potential risks and security vulnerabilities
• Identifies compliance and security vulnerabilities related to tampering audited information

To maintain the secure SQL Server environment, create audit reports on regular basis, and analyze them. That way, you’ll be able to detect any security or compliance threats, and be able to resolve them on time.

Track audit configuration changes on SQL Server instances

GLBA requires reports and regular reviews of auditing system changing activities. All changes in the auditing configuration must be properly documented. In case of any omissions in the auditing configuration, the documentation should provide easy and on-time correction, before causing inconvenience to customers or threatening GLBA compliance.

The Audit settings history report provides the changes applied to the ApexSQL Audit auditing settings – SQL Server instances, databases, tables, and events added or excluded from auditing. If auditing is set with GLBA compliance properly, any changes on auditing settings is indicative and should be investigated.

Audit security configurations

GLBA requires auditing of any changes related to access permissions, as these can directly threaten confidentiality and integrity of sensitive customer financial information

The following ApexSQL Audit reports correspond to the audit security configurations requirement:

• All changes related to the security entities (logins, users, and roles) are provided with the Security configuration history report, including created or dropped entities, granted/denied permissions, and name and password changes. Any changes, new user creations, granting permissions, or password resets potentially can be considered as an alert for a further investigation
• Also, all permission changes on a specific security entity are shown within the Permission changes per object and Permission changes per user reports. Permission changes, especially grants that are not documented within the report are a potential security threat, or a warning that appropriate auditing settings were not set
• Changes on the SQL Server instance, its databases, and objects are provided within the SQL Instance changes report
• The Activity per object report provides schema, data, and permission changes on a specific object. Any action performed by users with sufficient permissions on the objects will be reported, thus providing insight of activities even for the users that are not supposed to have permitted access
• The Activity per user, Activity per application, and Activity per host reports similarly report activities as the previously described report – the main difference is in the filtering parameters

Audit user access to data on SQL Server

GLBA compliance requires auditing of user access to the confidential data – any access can be a potential abuse, regardless whether the access was legitimate or not. Therefore, activities by members of the sysadmin role are tracked too

The following ApexSQL Audit audit reports provide captured access information:

• The Access history report provides what, when, how, and who accessed SQL Server objects. Also, it shows what procedures and statements were executed:

  

• The Complete audit trail report provides all captured events on the SQL Server instance set to be audited. It’s not a report that you will use often, but it’s recommended to check it periodically as it can show chronologically all events that were audited, and might indicate suspicious patterns in repeating particular events, e.g. specific successful logins followed by warnings about access denied to confidential data:

  

Audit user access to the system

GLBA compliance requires auditing of user access (logons) to the system too – any access can be a potential abuse, regardless whether the access was granted or not, and therefore captured

ApexSQL Audit provides information about tracked logons information with the following reports:

• The Unauthorized access report is perhaps the most important report that can indicate attack attempts, and provide information on attacker targets – specific logins or SQL Server instances. It shows all unsuccessful login attempts, due to non-existing logins or wrong passwords. This report can easily indicate brute-force attacks, in which case appropriate actions should be taken: disabling/renaming of login that’s under attack, or enabling use of Windows Authentication mode with the Windows password policy for accessing the SQL Server instance:

  

• The Logon activity history report, unlike the Unauthorized access report, shows both successful and failed login attempts. For each login attempt, the report shows the login name, server, time, application, application host name, and the login status:

  

Audit changes on users

Another important GLBA compliance requirement is that for any change applied to the system (SQL Server instances), users have to be captured and analyzed as a potential threat to confidentiality and integrity of sensitive customer financial information.

Complying with GLBA regulations requires a secured SQL Server environment and auditing. Ensuring sensitive customer information privacy and data accuracy is the first step. The second one, according to GLBA requirements, is to provide auditing and reporting. With a range of auditing options and comprehensive reports, ApexSQL Audit provides events auditing on SQL Server instances, databases and objects, and offers GLBA regulations compliance to meet this need.

References:
[1] Information Security – Examination Procedures

Useful resources:
Annual GLBA Board Reporting Requirements
Privacy Act Issues under Gramm-Leach-Bliley
How to Comply with the Privacy of Consumer Financial Information Rule of the Gramm-Leach-Bliley Act
Financial Institutions and Customer Information: Complying with the Safeguards Rule
GLBA Report to the Board of Directors