DoD STIGs – V-32597


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

Vulnerability ID: V-32597

STIG ID: SRG-APP-000292-DB-000138

IA Controls: None

Severity: Medium

Description: Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to modify an existing account for later use. Notification of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the creation of application user accounts and notifies administrators and/or application owners exist. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. This type of integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. The DBMS must support the requirement to notify appropriate individuals when accounts are modified.

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

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


Interpreting V-32597:

SQL Server has a few ways to be able to monitor the changing 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 modified. 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.