Automating Review and Response to Security Events

The next significant horizon in audit log management will be the automation of the review and response tasks associated with security events.  Currently, log management SIEM solutions are expected to scour logs, identify high-impact changes or other suspicious activity, and simply send out an alert.  It requires the intercession of a person to assess the information, make inquiries, research and review data, and ultimately resolve the matter.

In this article I’ll present several automation opportunities.  In addition to some simple integration with Active Directory or other LDAP services, these scenarios will require a degree of scripting and workflow capabilities such as those provided by SharePoint and similar technologies.

Verifying New User Accounts

The appearance of a new user account is an important event to the security of a system because it signifies a means of gaining entry into that system’s resources.  New accounts need to be reviewed to prevent the unnoticed creation of backdoor accounts by intruders, and to reduce the creation of insecure accounts outside of the change management and security controls of the organization.   However, wading through new user account notifications can be a laborious process for the information security team; it may be difficult for him or her to differentiate valid accounts from inappropriate accounts – especially at large organizations where employee turnover is high.

In this instance, automation can be an invaluable solution. When confronted with a new user account (e.g. event ID ??? in Windows Server 2008 Active Directory) the log management solution can compare the new account’s name with the naming convention standards for the organization.  At most organizations, naming conventions distinguish between human user accounts and system accounts created for services, applications and batch processes.  Often there are additional naming standards to distinguish between employees, contractors, privileged admin accounts.

For example, a company may prefix employees accounts with an “e”, contractors with a “c”, admins with “p” and system accounts with “s”, and so on.  When the automated response rule encounters a new user account that does not match this convention, it automatically recognizes the non-compliant user account and opens a trouble ticket for enforcing security standards. Conversely, an account with the proper naming convention is sent to the employee’s manager for confirmation. There is great value in corresponding a user account with an employment record in the Human Resources system so the automated response system can look up and verify an employee.  Lacking that verification, an exception ticket is generated and investigated.  By verifying all accounts, it becomes much more difficult to purposefully sidestep security controls.

Verifying Group Membership Additions

When a member is added to a group, new access is granted. Such occurrences can be excellent opportunities for automated response.  The crucial element in automating new group member response is for the system to be capable of identifying the data “owner” responsible for approving entitlements to the data to which that group is granted access.  Assuming the repository of groups is Active Directory, the obvious attribute is the Managed By property which allows a user account to be specified.  By populating each group’s Managed By attribute with the appropriate data owner the automated response system to determine who to contact when new members are added is created.  Data owners confirm and approve the new entitlement.  A positive confirmation closes the event and documents that re-verification has been performed.  A negative response opens a ticket with the information security group to investigate all relevant information (including the user listed in the audit log who executed the group member addition).  These are the only circumstances that require manual intervention by the information security team, but every group member addition can be confirmed.

Following Up On Suspicious Logon Activity

Resolving failed logons because of a bad password can be one of the most difficult tasks to execute since they are often caused by user error.  These events also present an opportunity for automated response.  When an information security analyst has reason to suspect an attack on a given account, the typical response is to contact the user to determine if they inadvertently created audit events.  An automated response system upon observing failed logons may perform the same actions similar to the process described above for group member additions.  Thresholds can be set up to prevent users from being targeted by incessant inquires each time they mis-enter their password. Since email access may be controlled by the very account under attack, it may be better to use an “out of band” communication method such as sending a text message to the user’s phone (again illustrating the important of being able to leverage information from the organizations directory when responding to events).

IP Geolocation can also be leveraged to identify suspicious logon attempts.  When a system observes a logon attempt (successful or failed) from a country or region outside the defined normal area for the organization or for an individual user (if physical location data is stored with the user’s directory information) an automated message can be sent to the user requesting confirmation of their activity.

There are multiple advantages to response automation for security events.  The ability to script such automated responses, access to the directory service, HR data, IT ticketing and some type of workflow system are important requirements but careful analysis organizations can identify those operations which are important.  Through such integration and automation, vigilance can be increased while eliminating the manual effort required to follow up on the numerous security events generated daily.