Server Log Files Do Not Always Have the Answer

In today’s world, security information and event management (SIEM) systems are hot technology. Some people deploy them because of compliance needs, others because they need access to data to troubleshoot problems. SIEM systems themselves are useless without sources of data and most of them connect to server log files and other network devices. The problem is that there are limitations with server log files when it comes to usability analysis.

Server Log Files Do Not Always Have the AnswerA good example of this is Ransomware. It is a big issue at the moment and most IT managers want to detect and get rid of it as soon as possible. This can be challenging when you have hundreds if not thousands of users on your network.

Once Ransomware gets into a network it starts to encrypt files and every time it moves from a directory to another, it leaves an instruction note within a text file that leads to a website or TOR network site. If an event can be triggered when these files are created then it would be an excellent start. However, as you can see in this sample event, no IP address is shown for the problematic device that is spreading the malware. This makes it difficult to block the device from accessing the network.

Event Type: Success Audit
Event Source:  Security
Event Category:  Object Access
Event ID:     560
Date:  2/24/2015
Time:    12:40:46 PM
User:  WIN2003DATABASE\Administrator
Computer:  WIN2003DATABASE
Description:
Object Open:
Object Server:  
Security
Object Type:  File
Object Name: C:\Downloads\test.txt
Handle ID:   5128
Operation ID:  {0,2612512}
Process ID:  4
Image File Name: WIN2003DATABASE$
Primary User Name:
Primary Domain:  WORKGROUP
Primary Logon ID:  (0x0,0x3E7)
Client User Name: Administrator
Client Domain: WIN2003DATABASE
Client Logon ID: (0x0,0x2708B4)
Accesses:   SYNCHRONIZE
ReadAttributes
Privileges: –
Restricted Sid Count: 0
Access Mask: 0x100080

Some people suggest setting up SPAN or mirror ports which are excellent data sources. The problem is that you may need to work through millions of packets to find useful information. Make no mistake about it, packet analysis can reveal crucial detail like IP addresses as you can see in the image below.

Server Log Files Do Not Always Have the Answer

You could now use log data and information from your Windows log to build a complete picture. While this might be an option for a small network with a few clients, it does not scale well. The next option to consider is a system like LANGuardian which does the packet analysis for you. It analyses the packets as they come in from a SPAN or mirror port and it extracts the important metadata. Metadata would include things like IP addresses, filenames and actions.

Server Log Files Do Not Always Have the Answer

Server Log Files Do Not Always Have the Answer

Systems like the LANGuardian can then export this information via SYSLOG or other formats to other network management systems which can then take an action.

Server log files do not always have the answer but there are other sources of data on your network.

Thanks to NetFort for the article.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: