Security, et al

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. 

Introducing:  LOGbinder SQL - SQL Audit Policy Wizard

Our totally free SQL Audit Policy Wizard steps you through the process of implementing SQL Server 2008 auditing. You can use our recommended baseline audit policy or customize it to fit your requirements.

After selecting your SQL Server and fine tune your desired audit policy, SQL Audit Policy Wizard automatically creates the necessary Server Audit and Server Audit Specification objects on your SQL server and optionally enables them so that auditing begins automatically.

You can also see the actual Transact-SQL generated by the wizard for learning purposes or for further customization. SQL Server 2008 Audit Policy Wizard even allows you to modify existing audit objects.

Get the wizard now, for free - no trialware expiration, etc.

Much of the security and control of an enterprise IT environment rests on Active Directory. It provides authentication and access control for Windows users and applications, as well as for UNIX, Linux and mainframes. Even VPNs, extranets and internal network security technologies all use Active Directory for policy and identity information.

To comply with information security best practices and compliance requirements, Active Directory must be regularly monitored and audited. However, if you've spent any time with the the native Windows security log you know that it provides only limited Active Directory audit capabilities.

Just one example is the fact that while the Windows security can tell you that a Group Policy Object was edited, it cannot tell you which of the nearly 1,000 settings were changed! And don't get me started on the noisy events generated and important information not logged when you try to audit Windows file sytem access.

In this whitepaper sponsored by Quest Software I explore the gaps in native Windows auditing that prevent organizations from achieving full compliance with best practices and security requirements. In fact I identity specific requirements in PCI, SOX and FISMA that make effective audit log management of Active Directory and the larger Windows environment mandatory.

Then I provide a brief tour of Quest's new On Demand Log Management and explain how this unique cloud based solution not only provides extremely easy to deploy core log management functions but also goes much further than typical log management solutions to bridge the gaps in native Windows auditing like the one described above involving group policy.

Read this whitepaper and learn:

• Where are the serious gaps in native Windows auditing?
• Which compliance requirements do these gaps prevent you from meeting?
• How does Quest On Demand Log Management bridge these gaps by replacing certain native audit funcitons?
• How can you deploy log management and achieve compliance with a fraciton of the effort required by traditional software?

Get the paper now:  Click Here

I'm excited to announce that my software company, LOGbinder, has just released LOGbinder SQL as beta.  If you need audit logging for SQL Server you will be interested to know about SQL Server 2008's new audit foundation and how LOGbinder SQL allows you to connect SQL's audit capability to your existing SIEM/log management solution:

Introducing LOGbinder SQL

SQL Server 2008 introduced a totally new audit logging facility, which is critical to enterprises storing sensitive information and/or processing important transactions in today’s demanding compliance environment. SQL Server Audit is flexible in terms of audit policy and comprehensive in relation to the breadth and depth of objects and actions that can be audited. However, the audit data generated by SQL Server needs additional refinement and processing before it can be relied up on as a usable audit trail and be managed by your existing log management/SIEM solution.

The audit records generated by SQL Server audit are cryptic and difficult to understand. Basically, one log record format is used for documenting everything from an insertion on a table to giving a user ownership rights to a database. And while SQL Server can write events to the security log, it uses the same event ID for all events, and the IDs and keywords are not resolved. Thus, it requires in-depth knowledge of the SQL audit model in order to decipher events.

Our LOGbinder SQL agent enriches SQL Server’s cryptic and generic audit messages to produce easy-to-understand audit log events. Similar to LOGbinder SP, these events can be outputted to the Security log a custom Windows event log, where any log management or SIEM solution can collect, alert, report, and analyze. Here is an example of an event:

Raw Audit Event from SQL Server

event_time:2010-09-16 12:35:30.0787755
sequence_number:1
action_id:APRL
succeeded:true
permission_bitmask:0
is_column_permission:false
session_id:54
server_principal_id:260
database_principal_id:1
target_server_principal_id:0
target_database_principal_id:0
object_id:7
class_type:RL
session_server_principal_name: ACMESP\Administrator
server_principal_name: ACMESP\Administrator
server_principal_sid:0
database_principal_name: dbo
target_server_principal_name: ACMESP\Administrator
target_server_principal_sid: 0
target_database_principal_name: public
server_instance_name: SPDEV\SQL08ENT
database_name: AuditTest
schema_name:
object_name: MyAudit
statement: EXEC sp_addrolemember N'MyAudit', N'public'
additional_information:
file_name=c:\sql audits\AuditAll_12633920-
FB34-4FAA-8F96-E9F8FED158A9_0_ 129276798828120000.sqlaudit
audit_file_offset=1536

Same Event After LOGbinder SQL Processing

Event ID: 24020
Add member to database role succeeded
A principal was successfully added to a database role
Action Group: DATABASE_ROLE_MEMBER_CHANGE_GROUP
Occurred: 9/16/2010 12:35:30.0000000 PM
Session ID: 54
User: ACMESP\administrator
Server: SPDEV\SQL08ENT
Database: AuditTest
Member
Name: public
Domain name: n/a
Role
ID: 7
Name: MyAudit
Statement: EXEC sp_addrolemember N'MyAudit', N'public'

*Learn more about LOGbinder SQL and download the beta today! Click Here.