Privileged User Monitoring
Identify risky activity such as configuration changes, escalating privileges and deleting files
IT and administrator accounts, such as those used for system and database administration, enjoy broad access privileges to sensitive systems and data. Privileged users hold the keys to the company’s most sensitive and critical data, such as customer lists, customers’ personally-identifiable information (PII), payment methods (such as bank account and credit card account details), financial transaction histories, sales lead pipelines, HR information and much more. Not only can privileged users view this data, but they usually have the privileges to alter or delete data that might be critical to the organization’s ongoing operations or legally-mandated reporting.
One of ObserveIT’s main User Activity Monitoring use cases is monitoring and auditing the activity of privileged user monitoring and auditing of critical servers. These privileged users include system administrators, help desk users, DBAs, programmers and so forth. Because these users are given extensive access to sensitive data and systems across the organization, they are the most important people to monitor—both because of the risk they pose to the organization and because industry regulations (such as PCI, HIPPA and SOX) mandate it.
Examples of privileged user activities that can impact on the security of an organization include:
- Making changes to configuration files that can cause systems to fail
- Creating unauthorized local or remote access accounts (e.g., VPN or SSH)
- Escalating privileges on Unix/Linux machines using sudo
- Changing the administrator or root password
- Using admin credentials on one machine to “leapfrog” to a more restricted machine
- Installing “backdoors” to enable later penetration
- Running malicious code that causes denial of service (DOS) to critical services
- Tampering with data by intentionally modifying data or code
Here are a couple examples of common privileged user activities that put a company at risk:
GRANTING SUDO RIGHTS TO A NON-AUTHORIZED UNIX/LINUX USER
Giving sudo rights to an account allows a user to access sensitive commands, services and data. Yet, what appears in system event logs for this action? Using auditctl and ausearch, one can only see that the visudo command was run. Unfortunately, this logging is almost entirely of a technical nature: one can see the working directory from which it was launched, its process ID, and the fact that it finished with a success return value. However, there is no indication of what rights were granted, or what the user did once those rights were assigned.
CHANGING AN IIS WEBSERVER CONFIGURATION FILE
Changing the IIS webserver configuration file can affect server operation in numerous different ways, and can expose the server to security risks. During the 20 seconds it takes a user to make a change, Windows logs 6,000 system events. The closest the log entries come to indicating that this file was changed was one log entry indicating that "web.config" was added to the "Recent Files" list in Windows!
HOW OBSERVEIT HELPS
User activity monitoring software specializes in recording and auditing all user activity on critical servers. ObserveIT provides alerting and reporting for numerous types of behavior anomalies that may put your company at risk. Security administrators can run reports and receive real-time alerts about particular user activities that they want to know about, whenever they occur.
- Any time an IT administrator edits a critical configuration file
- Any time an IT administrator changes a system password
- Any time a user escalates permissions using sudo
- Any time a user runs a particular SQL query against a production database
DB ACTIVITY AUDITING
Because of the massive DBA risk, the best User Activity Monitoring systems include feature-sets dedicated to tracking and auditing DBA activity in sophisticated ways. ObserveIT’s DBA Activity Audit feature records and analyzes every SQL query executed by DBAs against production databases. Security administrators can review all SQL queries performed on a given date, or filter results by database, DB user, server, login ID or even any text contained within the queries. SQL queries are also included in the session activity details displayed in the system’s Server Diary and User Diary. Additionally, security admins can search for, and generate reports on, specific text matches within SQL queries, such as the names of particularly sensitive data tables or fields, and SQL commands that are unusual or potentially dangerous.
Perhaps most importantly, security administrators can define rules that will generate alerts based on specific combinations of SQL command, data affected, computer accessed and user ID. By implementing a set of alert rules for the most sensitive data and SQL commands, security administrators can ensure that they are instantly made aware of any suspicious or problematic database access. DBAs do not have access to the ObserveIT management console, so that they cannot alter recording policies to prevent their own activities from being recorded. Sophisticated data integrity checks are also included so that security teams will know if any of the recorded data has been tampered with.
MONITORING SHARED ACCOUNTS
Another challenge faced by many organizations face is controlling and auditing the use of shared accounts, such as “administrator” in Windows and “root” in Unix/Linux. Access to the accounts is frequently provided to internal privileged users and outsourced contractors in order for them to do their jobs. However, having only the generic login name to track the actions performed on sensitive machines makes it difficult to determine, at a later time, who was the actual person who did those actions.
To do this, the organization’s administrators or security auditors can simply enable ObserveIT’s “secondary identification” feature for the shared accounts and/or specific servers they want to audit. ObserveIT validates these secondary credentials against the list of approved users/groups in Active Directory and will not allow the login process to proceed without valid credentials. Thus, with no more effort than assigning the appropriate Active Directory users/groups to specific shared accounts and/or designated computers, the shared account conundrum is eliminated.
At a later time, administrators and auditors can review the session records to see which particular user logged in using shared credentials. The views are either per login account or per server, with additional filtering options to make it easy to zero in on whatever is sought. Likewise, the system can generate reports with this information. Additionally, alerts can be defined to alert administrators any time a particular combination of server, shared account and secondary ID are used.