Having a background as a system administrator, I know first-hand many of the challenges you face. As every organization has a unique set of business requirements, system administrators work hard behind the scenes to keep operations running smoothly. From managing permission changes, recovering important files and monitoring user accounts, many system administrators utilize scripts to automate and manage routine tasks. Tenable.io includes over 450 pre-built audit policies and allows you to incorporate custom audit files. Custom audit files provide a great way for you to monitor routine events and changes, while making your work a little easier.
On a daily basis, organizations can generate thousands of events, and keeping track of these events across multiple systems can be difficult to manage effectively. System administrators often access multiple web interfaces or consoles to manage systems within their environment. In addition, many are also responsible for maintaining compliance, managing access permissions, and ensuring corporate policies are followed.
Scripts are often used in combination with other security devices to help system administrators monitor critical events or issues that need to be addressed. Unfortunately, no matter what you use to monitor your network, many of these solutions won’t provide the complete visibility you need to sort through all of the events and activity within your network.
By leveraging custom audit files within Tenable.io, you can easily keep track of unique or critical events within one interface. You can customize scripts based on your organizational requirements that can help to ensure service availability and protect data integrity. Tenable.io provides you with the critical insight needed to stay one step ahead of activity that could impact network security or business operations.
Monitoring Account Changes
Many organizations today are required to ensure compliance with corporate policies, as well as industry regulations. Controls requiring password changes and monitoring inactive accounts are often included within many well-known frameworks such as NIST, HIPAA, and PCI DSS.
We have also recently had several questions from customers that wanted to monitor user account changes within Active Directory. I decided to use my lab environment and test out a solution. Within my lab environment, I created several PowerShell scripts to find inactive user accounts and password changes within the domain. These controls help to prevent account compromise and reduce the risk of critical systems or data from being accessed by attackers.
Using Powershell with Tenable.io
Tenable.io has the ability to run compliance checks using PowerShell cmdlets. The compliance checks use the arguments supplied within a custom audit file and run “powershell.exe” on the remote server. Results will include either the command output or compare results against the value data specified in the file. PowerShell is Microsoft’s built-in scripting language that’s designed for System Administration tasks. Using credentialed scans, Tenable.io leverages PowerShell scripts placed within custom audit files to collect information on event changes and activity within your network.
Monitor User Accounts
Since I’m going to be querying Active Directory, I start by importing the Active Directory Module for PowerShell. The Get-ADUser cmdlet I created a script to retrieve a list of user accounts and when the password was last set. Using this cmdlet, you modify the script to include either active and inactive accounts, and track changes across specific Organizational Units (OU) or other domains within your forest.
This information can also be used by executives to confirm if corporate security policies are being followed or need to be improved. If your organization has an internal policy to remove inactive accounts after a specific time period, using this data can help you ensure compliance requirements are being met.
Tenable.io also supports the ability to use PowerShell script files within your custom audit file. The Nessus User Guide includes a detailed section on how to setup and configure your custom audit file with Powershell.
Create Custom Audit File
In my custom audit file, I’m using if/then logic to first check whether the target system is a domain controller, then runs each audit check. Since I’m going to audit my domain controller, the WMI_POLICY is used to provide an initial check that target system is either a Primary or Backup domain controller.
<custom_item> type : WMI_POLICY description : "Target is a Domain Controller" wmi_namespace : "root/CIMV2" wmi_request : "select DomainRole from Win32_ComputerSystem" wmi_attribute : "DomainRole" wmi_key : "DomainRole" value_type : POLICY_DWORD value_data : 4 || 5 </custom_item>
Next, I used the AUDIT_POWERSHELL check and added the PowerShell commands I ran previously. The description value should include the appropriate plugin name and powershell_args value should contain the PowerShell command. This check also supports the ability to use PowerShell .ps1 files as well.
<custom_item> type : AUDIT_POWERSHELL description : "<Plugin Name>" value_type : POLICY_TEXT powershell_args : "<PowerShell command>" value_data : "MANUAL REVIEW REQUIRED" severity : MEDIUM only_show_cmd_output : YES </custom_item>
The Compliance check parser provides you with the ability to add multiple audit checks within your custom audit file. Once your custom audit file is completed, save the final output into an .audit format.
Using the Policy Compliance Auditing scan template, I added my custom audit file and credentials for the domain controller. Completed results are located under the Compliance tab within the scan, and included the name of each check performed. Since we are auditing a Windows System, results are included within the Windows Compliance Checks plugin family.
Each result will look identical to the results posted earlier within PowerShell command line sessions. If you need to add more information, you can always modify your custom audit file to include the specific attributes you need based on your organizational requirements.
User accounts are one of the easiest ways for attackers to gain access to your network systems and data. Once an account is compromised, attackers can pivot and target critical systems, obtain confidential data, and remain in your network for days, weeks or even months.
These examples are just a small portion of what custom audit files can do for you. Whether you want to obtain additional information from Active Directory, monitor file and folder changes or track local account activity, using custom audit files provides you with countless ways to automate routine tasks and know what’s going on within your network.
I hope these tips help. And Happy SysAdmin Day to my fellow fearless colleagues!
Have More Questions?