Title: The DBMS must notify appropriate individuals when account disabling actions are taken.
Vulnerability ID: V-32598
STIG ID: SRG-APP-000293-DB-000130
IA Controls: None
Description: When application accounts are disabled, 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 audit account disabling actions and, as required, notify the appropriate individuals, 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 also 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 notify, or leverage other mechanisms that notify, the appropriate individuals when accounts disabling actions are taken.
Check Text: Check DBMS settings to determine whether it will notify appropriate individuals when account disabling actions are taken. If the DBMS does not notify appropriate individuals when account disabling actions are taken, this is a finding.
Fix Text: Configure the DBMS settings to notify appropriate individuals when account disabling actions are taken.[divider]
SQL Server has a few ways to be able to monitor the disabling 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 disabled. 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