Security, et al

Randy's Blog on Infosec and Other Stuff

«  Virtualization Security: ... | Need help configuring SQL... »

Automating Review and Response to Security Events

Wed, 23 Nov 2011 18:51:14 GMT

One of the next coming of age moments for audit log management is automating more of the review and response tasks associated with security events.  Right now we tend to expect log management SIEM solutions to scour logs, identity high-impact changes or other suspicious activity and simply alert someone.  It’s up to that someone to assess the information, make inquiries or other research and ultimately resolve the matter.

Instead of creating more manual work for infosec staff and administrators wouldn’t it be great if the system could carry out some of that review, inquiry and decision work on its own?

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

#1 Verifying New User Accounts

The appearance of a new user account is an important event to the security of a system since it signifies a new way to gain entry to that system’s resources.  Such new accounts need to be reviewed to prevent the unnoticed creation of backdoor accounts by intruders or simply insecure accounts created outside the change management and security controls of the organization.   But it is laborious for an infosecurity person or admin to wade through new user account notifications and potentially difficult for him or her to identify inappropriate accounts – especially at larger organizations with greater turnover.   

How could this process be automated?  Upon encountering a new user account (e.g. event ID ??? in Windows Server 2008 Active Directory) log management solution would compare the new account’s name to the naming convention standards for the organization.  Naming conventions at most organizations at least distinguish between human user accounts and system accounts created for services, applications and batch processes.  Often there are additional naming standards that make it easy to distinguish between variants like employees, contractors, privileged admin accounts. 

Let’s imagine Acme Corporation prefixes employees with e, contractors with c, admins with p and system accounts with s.  When our automated response rule encounters a new user account beginning with x it would recognize this as a non compliant user account and open a ticket with the team responsible for enforcing security standards. On the other hand when seeing an account beginning with e, it would email the manager for the employee based on the “direct reports” or “department” attribute of the new employee account and ask the manager to attest to this account as corresponding to a new hire in his or her department.  Through many audits performed over the years I’ve seen the value of ensuring that each user account can be tied to an employ record in the HR system so our automated response system may also look up the employee in the HR system ensure proper correlation there as well.  If it finds an exception an ticket would be opened with the same IT group responsible for security control compliance to track down where the disconnect occurred.  As you can see though the amount of manual intervention by IT or other departments is greatly reduced yet the amount of verification is much higher and more thorough than normally possible.  Some organizations may be able to take the automation even further by tying out new account provisioning to new hires in the HR system automatically. 

Inquiries regarding new accounts indicated to be contractors might be routed to the appropriate contract management group in purchasing or to the Manager if that attribute for contractors is populated with the employee who is the main liaison for the contractor.  Such contractor accounts would also be checked to ensure that an expiration date was configured of not more than some defined maximum period such as 3 months.  If the quantity and turnover of contractors warrants it, the system could even look up the contractor in the contract management system to correlate the account and expiration date automatically.  If such correlation fails the system would assign a ticket for the with the appropriate IT group.

By insisting that every account possible be tied to an employee or other business object such as a contract it becomes much more difficult to purposefully sidestep security controls or for accounts to slip through the cracks. 

#2 Verifying Group Membership Additions

Second only to new user accounts in security importance is a member being added to a group which with very few exceptions indicates an expansion of access be granted to the new member.  Such events (???) are likewise excellent opportunities for automated response.  The crucial element in automating new group member response is for our system to be able to identify the data “owner” responsible for approving entitlements to the data to which that group grants access.  Assuming our repository of groups is Active Directory, the obvious attribute is the Managed By property which allows you to specify a user account.  By populating each group’s Managed By attribute with the appropriate data owner we make it easy for our automated response system to determine who to contact when new members are added.  In that email notification the data owner would be asked to confirm that he or she had in fact approved this new entitlement by clicking on an appropriate link.  A positive confirmation would close out the matter and document that re-verification had been performed.  A negative response would open a ticket with the information security group to investigate including all relevant information including the user shown by the audit log to have executed the group member addition.  These are the only cases that would require manual intervention by the information security team, yet each and every group member addition would be confirmed.

#3 Following Up On Suspicious Logon Activity

One of the most difficult events to follow up on are failed logons due to a bad password (???) since they are often caused by a user simply entering the password incorrectly.  These events also present a possible opportunity for automated response.  An information security analyst who had reason to suspect an attack on a given account would typically contact the user to determine if they were inadvertently the source of the audit events.  Likewise out automated response system upon observing failed logons may contact the user similar to the processed described above for group member additions.  Of course in most cases some threshold of logon failures should first be exceeded before contacting the user so that users don’t become wearied by incessant inquires each time they mis-enter their password.  Or perhaps this automated response would only be implemented for privileged accounts with administrator or root access.  In any case consideration should be given to the method of communication used to contact the user.  Since email access may be controlled by the very account under attack it may be better to use an “out of band” communication 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 could be leveraged as well to help identify suspicious logon attempts.  When our system observes a logon attempt (successful or failed) from a country or region outside the normal area defined either for the organization as a whole or for the user individually (if physical location data is stored with the user’s directory information) the system could send message to the user asking them to contact information security if they do not recognize the activity.

These are just 3 examples of security events for review and response could be automated.  Of course 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 by careful analysis organizations can identity those operations which are important and/or frequent enough for which such an investment would pay off.  Through such integration and automation you can accomplish increased vigilance while eliminating the manual effort required to follow up on the myriad security events generated every day at any organization. 

email this digg reddit dzone
comments (0)references (0)

Live with Dell at RSA 2015
5 Indicators of Endpoint Evil
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure

Comments disabled

powered by Bloget™


Recent Blogs


Additional Resources