Event Log Blog

This is round two in the new features available in EventSentry v2.90, and this time I'll be covering the new compliance features.

Even though EventSentry was not originally designed to help with compliance, its event log consolidation capabilities made it an effective and economical solution to help our customers with their various compliance efforts throughout the years.

But while being able to filter and search through security events is helpful, it is not enough to quickly create reports that group information based on key elements, such as user creations, group modifications, policy changes and more.

In version 2.90 we addressed this by creating the new Compliance Tracking features which are based on the previous Tracking features.

This means that in addition to the "standard" event log consolidation that simply collects events and records them as is, compliance tracking intercepts specific events (e.g. account creation, logon/logoff, process creation), parses them, extracts the required information and records the relevant information in the EventSentry database.

Compliance Tracking covers the following auditing areas in Windows:

1. Process Activity
   
2. Console & Network Logons
   
3. File Access Activity
4. Account Management (User, Group & Computer accounts)
   
5. Policy Changes
   
6. Print Jobs

For example, finding out which group memberships changed over the last week is matter of two clicks in the web reports - and restricting a report to only reflect a particular group and/or action is just as easy.

But let me briefly outline the benefits of the individual tracking features:

Process Tracking
This feature records all process activity and lets you know which processes where started when, by whom, for how long and from which computer. This feature is not only useful for security purposes, but also helpful when troubleshooting or requiring statistical information (e.g. how often is PowerPoint being run).

Logon Tracking
This component tracks everything logon-related on your network, including console, successful as well as failed network logons. Using the console logon tracking for example, you can generate reports that show what time users logon and logoff, including from which computer, whether they are local admin and more details. Using the new network logon tracking, you can track successful as well as failed network logons. The included reports can reveal information such as which users logged on with a failed password, logon protocol distribution, most common reason for failed logons and more.

File Access Tracking
This feature is new in v2.90 and tracks all successful file access activity that has been enabled on files or directories. EventSentry does this by intercepting audit events that are generated when files or folders which are being audited. Since Windows Server 2003 and earlier don't actually audit when objects are changed, but instead only audit the requested file access (click here for a related post), EventSentry can perform additional checks and verifications to complement the native auditing capabilities of the OS - such as checksum creation. Of course EventSentry also gathers additional information - such as the source computer from where a change was made.

Account Management Tracking
Also new in v2.90 is account management tracking, which encompasses user, group and computer account management tracking. This feature really makes life easier when you deal with large quantities of user, group and / or computer account changes.

For example, tracking a users group membership changes - even across computers and domains - is only a few mouse clicks away. Do you need to know which computer accounts were created in the last week in your domain? This only takes three clicks in the web reports.

Policy Change Tracking
Another feature added in v2.90, policy change tracking records the following "policy" events:

• Domain Policy Changes
• Audit Policy Changes
• Kerberos Policy Changes
• User Right Changes
• Logon Right Changes
• Trust Relationship Changes

Again, getting information about any of the above scenarios is extremely easy - such as seeing which user/logon rights were assigned in the last week or on which server the password policy was changed in the last 2 weeks.

Since none of tracking features are limited to hard-coded reports but instead are easily adaptable, they not only make your auditors happy - they provide you with valuable information. This allows you to utilize EventSentry not only for compliance but many other tasks, whether is security-related, for troubleshooting or something else.

As always, please see the documentation for more information. You can take a look at version history as well for a complete list of changes and new features in the 2.90 release of EventSentry.


Enjoy,
Ingmar.

Since we have just released EventSentry v2.90, we’ll be blogging about the improvements and new features in the coming weeks. Since event log monitoring is how it all started, my first post in this series will be about the improvements and new features in our event log monitoring engine.

Vista/Windows 2008
The biggest change in v2.90, in regards to event log monitoring, is of course the native support of the Windows Vista and Server 2008 event log API. As many of you know, Microsoft introduced a new API for event log monitoring while still keeping the legacy API in place for applications that don’t support the new API yet.

EventSentry v2.81 uses this legacy API with some work-arounds to monitor the new event logs, but I highly recommend upgrading to v2.90 if you’re monitoring Server 2008 and/or Vista event logs. Upgrading will result in less overhead and better formatting and presentation of events since the agents now access the event log with the native API. Naturally, the event log backup feature will backup event logs in the new evtx format on Vista/Server 2008 computers.

The new version also supports the new Operational event logs which are displayed under Application and Services Logs/Microsoft, for example the Microsoft-Windows-Backup/Operational log.

These operational logs need to be configured as custom event logs in EventSentry, by specifying the full path (e.g. Microsoft-Windows-Backup/Operational) as the name of the custom event log.

Please see one of my previous posts about the event log changes in Vista (which also applies to Server 2008) for more information.

Note that support for the new event log API is transparent, and there is still only one executable of the EventSentry agent for all versions of Windows.

64-Bit
EventSentry v2.81 did not format some events on 64-bit editions of Windows correctly, and we have resolved this problem in 2.90 which renders all events on 64-bit machines correctly. The EventSentry agent still runs as a 32-bit application in 2.90, but we have long-term plans to supply a 64-bit agent for x64 operating systems.

Filter Timers
Filter Timer filters allow you to ignore events that would otherwise trigger an alert, if they are followed by another event within a preset time period. For example, if an event indicating that a critical service is stopped is being immediately followed by another event indicating that the service is running again, then a filter would allow you to suppress both events.

Previously however, filter timers had to be setup exactly for each event pair. This meant that if you wanted to use a filter timer for 5 services, then you would have to create 10 events. Starting with 2.90 you only have to create 2 events now, as long as the first event and the clearing event share the same order of insertion strings - which is usually the case.

Please see the documentation for more information.

Action Trigger History
Selected actions (e.g. email, pager) now include the ability to log their trigger history - that is every time they are triggered by an event - to the database. This helps you confirm that a notification was in fact performed, and also gives you the ability to gather statistics about which actions are being triggered and how often.

The action trigger history includes the following information:

•    Date/Time
•    Computer
•    Action Name, Action Recipients
•    Event Log Package, Filter Name
•    Event Log, Event Source, Event ID, Event Number

Please see the documentation for more information.

Web Reports: Error Explanation
Many events from the security event log, for example audit failure event 675, contain error numbers and failure codes inside the event that require you to research them in order to find out what they mean. Here is an example:

You can see that the failure code of 0x25 in itself doesn’t reveal too much, but if you view the same exact event through our web reporting, then the failure code is automatically explained for you:

As you can see in the screenshot above, the Kerberos failure code of 0x25 is automatically explained as “Clock skew too great”.

Copying / Pasting event details from Emails
If you have been using EventSentry for a while, then you’ve probably setup event exclusions more than once, most likely after receiving an email from one of the agents. Starting with 2.90, you can now copy the event in your email client and paste it into a new filter. The management console will parse the event properties and automatically fill in the following fields for you:

•    Event Log
•    Event Severity
•    Event Source
•    Event Category
•    Event ID

Please see the documentation for more information.

You can take a look at version history as well for a complete list of changes and new features in the 2.90 release of EventSentry.


Enjoy,
Ingmar.

If you are managing more than a handful of servers and workstations in an Active Directory domain then you have probably come to rely on a small set of utilities to help you with your daily tasks of managing your servers and workstations. You probably carry those apps with you on a USB stick (check out PortableApps.com) or have them sitting on some network drive for access when you need them, and most of these tools are probably from different developers and vendors.

 

I personally like a lot of the Windows Sysinternals tools such as psexec, process monitor, Microsoft Network Monitor and of course the NTToolkit tools that we develop – but everybody has his or her own preference as to what they need to get the job done. And that’s exactly my point.

 

Wouldn’t it be great that every computer you manage – workstation or server – always had the tools you need automatically pre-installed? That way, they could be used in scheduled tasks, batch scripts etc. without you having to worry whether the tool is installed or not.

 

Well, it is possible – and you can do it without spending a dime – thanks to Active Directory and the folks at Caphyon in Romania that provide a freeware edition of their Advanced Installer.

 

You probably see where I am getting at. Combine a MSI created by Advanced Installer with your favorite tools and Active Directory’s “Software Distribution” feature, and you get all your tools at your fingertips – whenever you need them. In this post I’ll show you how to create a MSI with your favorite tools and automatically publish that to some or all computers in your AD domain. This approach also supports updates, so that you can publish revised MSI packages with new tools and/or updates.

 

The nice thing about this solution is that the only prerequisite is Active Directory, and even if you don’t have AD you still end up with a MSI that you can easily install on any computer.

 

1. Download & Install Advanced Installer Freeware. You can also go with one of their commercial products of course, but the freeware version is enough for our purposes here.

 

2. Organize all of your tools into one location so that they can easily be added to the installer. This is not absolutely necessary but will make working on the installer a bit easier.

 

3. Open Advanced Installer. It should open a dialog to create a new project. If not, go to File -> New.
   
   
4. Select a project type of Simple and make sure "Use wizard to create the project" is checked.
   
   
5. The New Simple Project Wizard comes up. Click next to continue, and give your project a descriptive name.
   
   
6. Browse to the folder containing all your tools.
   
   
7. The next box allows you to create shortcuts to specific programs. If you have any GUI programs in there then you may want to check them and then hit Next.
   
   
8. Now you can hit Finish on the final screen to build the project. It will save it as a .aip file in the location of your choice.
   
   
9. At this point we can just call it a day and compile the MSI file. I like having my command-line tools in the PATH environment variable however, so that I can access them conveniently from any folder. Keep reading for more info on this, otherwise just skip to step 12.
   
   
10. Click on the "Environment" link in the left panel. Now right click anywhere in the blank space on the left side and choose "New Variable".
    
    
11. In the screen shot below you can see what settings to use to add it to the Path system variable.
    
    
12. Now just click the "Build" button to create your MSI file.

Now that you have the MSI file, you can roll it out using Active Directory. If you need a refresher on how to do this, then please see the earlier blog post Applying Patches and Updates with Active Directory that shows how to distribute MSI-based patches with Active Directory - essentially the same concept.

Drawbacks & Considerations

Now, I have to admit that there are some drawbacks to using Active Directory to publish your MSI. Currently, group policy can only apply software installations in the foreground, which means that you will have to reboot a computer in order to have your new MSI installed. If you know a way around that - other than using a 3rd party software deployment suite - then please let me know.

Also keep in mind that any tool you install on your servers and/or workstations will, by default, be available to any user on that machine unless you adjust the permissions of the target folder manually. As such, I would refrain from including utilities in your MSI that make gaining unauthorized access easier, and also ensure that you always have the latest version of your tools in your MSI.

I hope this tip helps managing your servers and workstations a bit easier. Until next time,

Ingmar.