DoD STIGs – V-32599

Overview:

Title:  The DBMS must notify appropriate individuals when accounts are terminated.

Vulnerability ID: V-32599

STIG ID: SRG-APP-000294-DB-000129

IA Controls: None

Severity: Medium

Description: When application accounts are terminated, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events that affect user accessibility and application processing, applications must notify the appropriate individuals when an account is terminated so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. To address the multitude of policy based audit requirements, and to ease the burden of meeting these requirements, many application developers choose to integrate their applications with enterprise level authentication/access/audit mechanisms that meet or exceed access control policy requirements. Examples include, but are not limited to, Active Directory and LDAP. The DBMS must automatically notify the appropriate individuals when accounts are terminated

Check Text: Check DBMS settings to determine whether it will notify appropriate individuals when accounts are terminated. If the DBMS does not notify appropriate individuals when accounts are terminated, this is a finding.

Fix Text: Configure the DBMS settings to notify appropriate individuals when accounts are terminated.

[divider]

Interpreting V-32599:

SQL Server has a few ways to be able to monitor the termincation of accounts. The trick with this is the whole notify aspect.

The SQL Server native methods include Triggers, Change Tracking, Change Data Capture and SQL Server Auditing. They all have specific features, similarities, differences, advantages, and disadvantages. One of the disadvantages is the lack of easy to use notification when something changes. Triggers can be configured to send an email alert, but run the risk of mass amounts of email and overhead use if not done correctly. Change tracking can work, but not for user accounts. It is more for use with actual row changes in user created tables. The system tables storing user information are not only in your application database (unless a contained database) and it can get tricky to capture everything where you would need to. Change Data Capture does capture changed data values, but is a lot like Change Tracking. You start to get into a lot of little complexities when dealing with SQL Server user security. That pretty much leaves SQL Server Audit. When you setup a SQL Audit you can set the destination as a file, security log or the application log. It is a great solution for tracking permissions changes, login creation, etc. The main issue is that it does not send an automatic alert to an individual.

Does this fit the criteria to notify individuals when accounts are terminated. Well, if you check your logs and audit files regularly, then it may be a yes, depending on your actual requirements. I myself feel that these types of notifications should be automated. We are continuing our research into ways to efficiently accomplish this without relying on a lot of tools and services outside of SQL Server. We will update this post if we find a solid solution we are satisfied with.

Return to the DoD STIGs – Database Security Requirements Guide

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.