Understanding the Event Log

Understanding
the Event Log for
a more secured
environment
Dave Millier
Chuck Ben-Tzur

Overview

Introducing… the Event Log
Why Monitor Logs
Enabling Event Logging
Real Time Monitoring
Example: Security Log Tampering
Auditing and Analysis
Archiving Events
Example: File Modification Investigation
Event Log Limitation
Vista Event Log
Example: Creating Log File Using Event Triggered Tasks
Resources and Questions

Introducing…Event Log

Centralized log service to allow applications and the
operating system to report events that have taken place.
Introduced with Windows NT 4 (1993).
Main Windows Logs
Application (example: Database message)
System (example: driver failure)
Security (example: Logon attempt, file access)
A Windows 2003 domain controller will also include
Directory Service (example: Active Directory connection problem)
File Replication (example: domain controller information updates)
DNS
Vista has introduced a lot of changes

Why Should We Monitor Logs

We don’t NEED to… We HAVE to…
Organizations are obligated by regulations to gather and
audit systems activity logs.
HIPPA (Health Industry)
Regulatory review of system activity to ensure that a user
information remains private but accessible
Identify, respond and document security incidents
GLBA (Financial)
Dual control procedures
Segregation of duties
SOX (Financial)
Record Retention and availability
Accountability

Why Should We Monitor Logs (cont.)

To comply with the regulations organizations require the
following forms of log monitoring
Real-time monitoring
Identify attack attempts in progress and if a security breach has
occurred.
Audit and analysis
Periodic reports and analysis for regulation compliance (due diligence).
Archiving
Again… regulations compliance (log retention)
Forensic investigation of an incident

The event log should also enable the organization to
implement internal security policies.

Enabling Event Logging

Each event category is controlled by audit policies:
Account logon events (for domain accounts)
Account management (group and account events)
Directory service access
Logon events (local machine events)
Object access (user accessing an object such as file, folder, printer)
Policy change (changes in the audit, user rights and trust policies)
Privilege use (user exercising one or more of his rights)
Process tracking (detailed tracking information)
System events (events that affect the system security or log)
Each policy can be set to audit success events only, failure
events only, success/failure events, or no auditing at all.

Audit Policies (Member Server)

Real-Time Monitoring

Successful events that grant the user high level privileges
(either by spoofing identity or elevation of privileges)
Events to monitor
Successful high profile user account / group management events
#636– Group member added or removed
Successful logon events of high profile user accounts
#680 – Logon attempt
Successful logon events to a domain controller
Operations on specific high profile resources (files, folder)
#560 (Object Access), #564 (Object Deleted)
Successful policy change events
#612 – Audit Policy Change (logs no more…)
All system events
#517 – security log was cleared

Example: Event #517 (Clear Security Log)

Security Log


Security Log

A User will try
to erase the
logs


Security Log

A User will try
to erase the
logs (and not
event save it)


Security Log

A User will try to
erase the logs

A New Event is
Created


Security Log

A User will try to
erase the logs

A New Event is
Created

The Event
Contains the
User Name

Real-Time Monitoring (cont.)

Tracking and analysing event failure patterns may
indicate a range of malicious attack attempts
Failed logon activity (e.g. brute force attack)
#675 – Pre Auth, failed with Kerberos code 24 (Bad password)
#539 - logon failure due to account lockout (if systematic may be an
indication of DoS)
Failed account management activity (e.g. password reset events)
All failed system events
#517 – Audit log cleared
Note: Most of the auditing policies, by default, are set to log
successful events only. Local policies may be set to no
auditing at all.

Real-Time Monitoring (cont.)

Possible issues
Flood of events (domain controller and member server event
duplication, detailed tracking events)
Solution: Consolidate log information for better analysis
Unmonitored systems (e.g. unaudited events on a file server)
Solution: Threat modeling, identifying assets in organization
Unmonitored events (detailed user and process activity)
Solution: Organization security program and policies
False positives due to configuration problems
(e.g. expired service password)
Solution: Knowledge of the network, components and assets
(Human Factor)

Auditing and Analysis

Most regulations require a periodic review of important
events (not critical or show stoppers) for two reasons:
A “second chance” to reveal malicious activity originally undetected
(and unaccountable for).
Audit the ongoing activity to verify no major changes have taken
place.
The data is usually reviewed in the form of reports
(detailed and summarized)
Example of Events to Monitor (A short list)
#529 to #535 and #539 – Logon failure (different reasons)
#629 – User account Disabled
#644 – User account Locked Out

Auditing and Analysis (cont.)

Possible issues
Finding a critical event that was not detected by the real-time
monitoring processes
Solution: Investigate the incident to eliminate or mitigate any results of
malicious activity.
Duplicated events (Domain controller and Local Server)
Solution: Correlate and consolidate events using external system
Lack of security policies to help and identify events to be audited
(e.g. Messenger)
Solution: Define security policies to determine which event types need
to be audited on a regular basis.
Report requirements are unclear and affect the log detail level
Solution: Define auditing processes to determine what type of logs
and details are required (TIP: when in doubt, use graphs…)

Archiving Events

Event Archiving is done for two main reasons:
Log retention compliance (e.g. SOX)
Forensic investigation of a security incident (chain of evidence)
In general, all system events should be logged. However,
by default, not all audit policies are set to generate logs.
In particular, detailed tracking of high profile objects (such
as files, folders, printers, etc.) is turned off by default. A
common misconception is that regular object access
events provide this information.

Example: Detailed Event Tracking

Detailed Event tracking can include the following events:
#528 – Successful Login (The user authenticate to the system)
#592 – A new process has been created (application is launched)
#560 – Object Open (a file is requested)
#567 – Object Access (the file is modified and saved)
#564 – Object Deleted
#562 – Handle Closed (the file has been closed)
#593 – A Process Has Exited (the application was terminated)


Enabling Audit Policies
Object Access
Logon (Local and
Domain)
Privilege Use
Process Tracking


A Very Important Folder
(e.g. sensitive document on
a file server)


A Very Important Folder
(e.g. sensitive document on
a file server)
The folder contains files we
wish to monitor
(compliance, sensitive
information, etc.)


Detailed Tracking is
configured on the
resource itself


configured on the
resource itself
Security > Advanced


configured on the
resource itself
Security > Advanced >
Auditing Tab


configured on the
resource itself
Auditing Tab > Add


configured on the
resource itself
Auditing Tab > Add
Select the Account or
Group to be audited


configured on the
resource itself
Auditing Tab > Add
Group to be audited
Select the events to
audit (Read, Write,
Delete…)


configured on the
resource itself
Auditing Tab > Add
Group to be audited
Select the events to
audit (Read, Write,
Delete…)
Each user/group will
require additional
settings


Timestamp: 13-06-07 04:27:40


Timestamp: 13-06-07 04:27:40
Last Modify: 13-06-07 05:27:39


Timestamp: 13-06-07 04:27:40
Last Modify: 13-06-07 05:27:39

Filter who was logged
in during that time


Timestamp: 13-06-07 04:27:40

Last Modify: 13-06-07 05:27:39
User Logon ID: 0x43F744D


Timestamp: 13-06-07 04:27:40

Last Modify: 13-06-07 05:27:39


Excel Process ID: 2916


Timestamp: 13-06-07 04:27:40

Last Modify: 13-06-07 05:27:39



File Open Handle: 644


Timestamp: 13-06-07 04:27:40

Last Modify: 13-06-07 05:27:39




File (644) Modified at 05:27:39


Timestamp: 13-06-07 04:27:40

Last Modify: 13-06-07 05:27:39





File (644) closed


Timestamp: 13-06-07 04:27:40

Last Modify: 13-06-07 05:27:39





File (644) closed

Excel Process (2916) Terminated


Timestamp: 13-06-07 04:27:40

Last Modify: 13-06-07 05:27:39





File (644) closed

Excel Process (2916) Terminated

Matching Modification Times

Archiving Events (cont.)

Possible issues
Volume of events
(can reach several million events a day from a busy server)
Solution: Transfer logs to long-term storage (compressed, digitally
signed, etc.)
Lack of security policies to help and identify events and
processes to be audited (e.g. Messenger)
Solution: Define security policies to determine which processes and
their relevant events need to be logged on a regular basis.
The event logs are just a portion of the “chain of evidence”
Solution: Define auditing processes to ensure that all the required logs
are being gathered and associated (e.g. a unique ID or a time stamp).
For example: associate firewall logs through the Windows event logs
and to the database logs.

Know Your Event Log Limits

Size matters (and its never enough…)
Solution: For long term logging, use an external storage system.

Know Your Event Log Limits (cont.)

Log Analysis and correlation (especially when using
automatic systems like SEM and SIM) often result in a
large number of false positives.
Solution: Knowledge of the network and assets to refine alerts, ongoing
tuning
Logs are a “detective” measure and are not an IPS
(Intrusion prevention system) on their own
Solution: Vista has a partial solution. For complicated responses,
leverage external solution to gather and analyze logs
Not all events are logged on the domain controller. These
events require a log gathering process
Solution: Vista has presented a solution. Otherwise, use external log
gathering system.

Know Your Event Log Limits (cont.)

Security event logs monitor only the authentication and
authorization mechanisms of the operating system.
Solution: Most applications write (or should…) logs to the Windows event
log. These logs can be used to enhance the monitoring capabilities.
Custom application logs neglect to provide information
regarding the log details or the severity or of the event.
Solution: Educate your developers, develop an API, buy something
better…

Vista Event Log

More More
Event Categories
Sources

Vista Event Log

Redesigned

XML Based

Vista Event Log

Redesigned

XML Based

Simple to
Understand

Vista Event Log

Redesigned

XML Based

Simple to
Understand.

Vista Event Log

Redesigned

XML Based

Simple to
Understand..??

Vista Event Log

Redesigned

XML Based

Simple to
Understand….

Event Log Tasks (Vista)

Select an Event


Select an Event to
open the Wizard


Select an Event to
open the Wizard

The type of Event is
pre-selected (basic)


Select an Event to
open the Wizard


Select Action


Select an Event to
open the Wizard


Select Action

e-mail settings


Select an Event to
open the Wizard


Select Action

Launch a process


Select an Event to
open the Wizard


Select Action

Finalize Settings


Select an Event to
open the Wizard


Select Action

Finalize Settings

A New Task is Born…


Select an Event to
open the Wizard


Select Action

Finalize Settings

Task Created

Task is Visible in the
Task Scheduler


Select an Event to
open the Wizard


Select Action

Finalize Settings

Task Created

Task is Visible in the
Task Scheduler (new
Tasks Category)


Problem: Basic Task
Event Details are pre-
defined.


Problem: Basic Task
Event Details are pre-
defined.
The next example will:

• Trigger on successful logon events of a specific group

• Create a file with a list of users that logged on

• Highlight username with “Admin” string


Create a New Task


Create a New Task

Select the User Group


Create a New Task


Triggers Tab > New


Create a New Task


Trigger Task On an Event


Create a New Task



Switch from Basic to Custom


Create a New Task



and Create New Filter…


Create a New Task




Select Event Logs


Create a New Task




Select Event Logs (Multiple
Logs!)


Create a New Task




Logs!)

Select Events ID (Possible
Multiple IDs) and Keywords


Create a New Task
Logs!)
Multiple IDs)
The trigger is saved as
XMLQuery (Can be modified)


Create a New Task
Logs!)
Multiple IDs)
The trigger is saved as
XMLQuery (Can be modified)
The Task Action will be
“Select a Program”…


This VB script search for “Admin” string in the
logged user name and add a notes beside it.


The output of three different users logging to the machine…

Event Log @ Vista

New Event Viewer (interface)
Over 50 new Event categories
Over 2400 policies (over 1000 in W2K3)
XML based
Events are still written locally
Critical Events can be forwarded
Expanded to serve as single location for all
events (using Windows Remote Manager)
Events can launch system tasks

Resources

TechNet – Auditing Overview
(http://technet2.microsoft.com/windowsserver/en/library/768463f6-02b9-4e5e-af55-
29c089ade6381033.mspx?mfr=true)

EventID.net (http://www.eventid.net/search.asp)

Randy Franklin Smith’s Windows Security Log Encyclopedia
(http://www.ultimatewindowssecurity.com/encyclopedia.html)

Company:
Private Canadian company Toronto based
Providing Security consulting and networking solutions for over 10 years
Business model focused on delivering timely security information to all areas of an organization
(CEO down to administrator)
Dynamic, agile response to client needs
Experience with customers in multiple verticals
Experienced management team
Consistent Approach:
Provide “snapshot” security information for senior executives
Provide detailed “security to-do” lists for follow-up by onsite personnel
Proven & Scalable Solutions:
Phased Delivery method ensures client satisfaction
Successful deployments with large organizations
Clients need fewer in-house qualified security professionals
Minimize manual, mundane daily client tasks
Leverages both Proprietary and Industry Best-of-Breed Technologies
Extensible Framework:
Adheres to ISO 17799 Framework, Security & Industry Best Practices
The Sentry Dashboard is an enabler for any security subsystem
Can be adapted to present information from non-security sources (network availability and trending,
HR reporting, etc.)
Engages all areas of an organization, from Senior Executives and security officers, to hands-on
systems and network administrators

Understanding the Event Log

More Related Content

What's hot

Viewers also liked

Similar to Understanding the Event Log

Recently uploaded

Understanding the Event Log