Security, et al

Security standards and auditors make much of reviewing logs for malicious activity and I am constantly asked for event signatures indicative of intrusions or even more simplistically some ask “What are the top Event IDs for intrusion detection?”  Ah, if it was only that easy.  Movies make it look that way, the protagonist furiously defends the network while a computer voice stridently calls out “intruder, intruder”. 

But in the real world, if the computer can detect an intruder it takes immediate preventive steps instead of simply logging the intrusion or helplessly calling out “intruder”.  For instance if an attacker tries to discover an account’s password through repeated logon attempts, the system locks out the account.  On the other hand, if a disgruntled employee copies sensitive data to flash drive, to the operating system it looks like any other day of normal usage.  An authentic user accessing authorized data.  If the system is logging anything at all, there will just be an audit trail of successful access attempts. 

It’s not impossible to use logs to detect some intrusions and malicious activity but the first and foremost return on investment from logging is an audit trail that can be used to detect high impact changes in security stance, investigate incidents, perform impact analysis, take action against offenders and learn how to prevent repeat attacks in the future.  Moreover, a properly deployed audit system serves as an effective deterrent control against insider abuse.  All of this can be accomplished by enabling logging on monitored systems and implementing a log management solution with high integrity deployment characteristics.

But to get more than change detection and audit trail usage from your logs you must go upstream from the logging function and get the cooperation from system administrators to configure and operate systems in such a way that certain foreseeable types of malicious activity will recognizable to your log management solution.

Take security log integrity in Windows as a simple example.  Windows provides strong protection against tampering with the security log.  Unless the operating system is down and you have physical access to the system you basically have to be an administrator to erase the security log.  (It’s very difficult even with administrator authority to modify event records in the security log – you need a program like the old WinZapper.)  Windows graciously logs a specific event ID (517 on Win2003 and 1102 on Win2008) whenever the log is cleared so it makes sense to generate an alert whenever security logs are cleared as a deterrent to rogue administrators trying to cover their tracks or as a way of detecting an intruder doing the same.  But if your administrators are in the habit of clearing the log when diagnosing system problems, your alert rule will generate false positives.  Therefore, in addition to reactive log management you must proactively get administrators to comply with a policy to never clear security logs and allow old events to die a natural death as records are purged.

While the previous case demonstrated an example of procedural measures implemented upstream from the log management process, detecting the spread of file based malware requires you to work with system administrators to setup system objects ahead of time for the purpose of helping the log management solution distinguish between normal file access and malicious.  Here’s the premise: you want to detect malware that has made it through your preventive controls like antivirus.  Most malware either spreads by injecting itself into files of affected file types (i.e. word documents or image files) or looks for files that it can send back to its nefarious operator. 

So, we set up the equivalent of a trip wire for unsuspecting malware or outside intruders to trigger.  (In this example I’ll stick with the Windows and Active Directory environment but the concepts would be applicable to other platforms.) To do this we work with various system administrators to create “honeypot” folders on servers throughout the network.  In these folders we put a collection of files with all the common file types including Office documents, image files (e.g. JPG, GIF), PDFs and others that have been targeted by malware.  Ideally we name these honeypot folders with just one or a few easily recognizable folder names.  We grant everyone access to these folders and enable file system auditing so no matter what user is the victim, the malware will have access to folder in order to trigger the tripwire.  If we want to detect malware that is spreading itself or simply corrupting data, we limit file system auditing to WriteData and AppendData.  On the other hand if we also hope to detect malware that is stealing data we would also enable auditing of ReadData. Then back at our log management solution we would enable alert rules when file system audit events (event ID 560 on Windows 2003 and 4663 on Windows 2008)  arrive which identify one of our honeypot folders as having activity.  To prevent false positives some training and reminders may be necessary for end-users so that they understand these folders (especially those on file server shares) have nothing useful for them and are there for “system” purposes. 

These 2 examples demonstrate you can take a foreseeable type of malicious activity and implement procedures or system objects that make it possible to detect activity that would normally blend in with the background noise of everyday, legitimate usage.  The downside of course is that you require cooperation from folks who are upstream from the log management solution.  Depending on the capabilities of your log management solution, you may be able to discover malicious activity without implementing upstream tripwires using a final method: anomalous changes in activity levels. 

Some types of malicious activity cause a spike in audit events that can be detected if your log management solution has sufficient real-time analysis capabilities.  My favorite example is the disgruntled insider who intends to post thousands of documents to a site like Wikileaks.  The user likely already has access to the sensitive documents in question so there may be little or no failed access attempts to alert you to what is happening.  Instead, file system auditing, if enabled, will generate successful read attempt events for each file accessed.  However, if a typical day in the life of the angry employ involves accessing just a handful of documents and now he or she suddenly accesses many times that amount, a feature rich log management solution should be able to keep a rolling average of normal Read events on sensitive folders for each user and detect a spike like this.  At that point there is sufficient cause to generate and alert and devote some security staff time to determining the cause.  With anomalous activity level detection, some thresholds can be generalized and baked into the log management solution but others would need at least some amount of customization by the organization such defining folders or servers that are considered sensitive. 

As you can see, detecting intrusions and abuse with logs is possible but it requires a variety of analysis techniques.  Likely you will need the cooperation of system administrators upstream from your log management system in order to setup procedural or system level tripwires.  Finally your log management solution’s ability to analyze large amounts of data detect sudden changes in activity levels for a given system or user can be very effective in alerting you that something is afoot. 

Hello Randy, in an environment with "Audit access to global system objects", we have millions of 560 errors in the Security log. In looking at the fields, it appears that it is services.exe that is querying (every 10 seconds or so), for a CurrentControlServices\...\ObjectName.

The sub-key ObjectName does not exist! Any access attempt generates a 560 event. It's not a authorization failure, but a existential failure.

What is possessing our services.exe???