SANS Digital Forensics and Incident Response Blog

Context-Specific Signatures for Computer Security Incident Response

The notion of signatures has a bad name in the world of information security, because it's often associated with the limitations of signature-based antivirus scanners. Similarly, much has been said about evading the signatures of network IDS tools. However, writing and deploying custom context-specific signatures during an information security incident helps assess the scope of the breach and later confirm that the situation was addressed.

Understanding the Signs of the Security Incident

Upon detecting the security incident, the organization should perform an initial analysis of the situation. The goals of this process include the identification of the signs of the attacker, malware, or other incident artifacts. These signs are sometimes called Indicators of Compromise (IOCs)-a term that was popularized in the field of computer forensics by Mandiant, who defined an IOC as "a Boolean decision tree that discriminates an indicator from a false-positive, theory from ground truth."

The signs of the security incident could be a set of registry keys associated with the malicious program, the files dropped by the intruder, the suspicious IP addresses flagged in the firewall logs, etc. You can identify these attributes through malware reverse-engineering, file system and network forensics, memory analysis, and so on.

The Need to Codify the Signs as Context-Specific Signatures

The initial analysis of the incident should help you determine what attributes to look for at the network and system levels to understand the scope of the incident. In other words: What other systems may have been affected? Knowing the scope is critical to being able to contain the situation. To accomplish this, you need a way of codifying the signs derived earlier, so you can look for them in an automated fashion.

Codifying the signs typically involves creating signatures of some form. "But wait!" you might exclaim, "Aren't signatures a poor way of identifying malicious artifacts?" True. We've all noticed how ineffective anti-virus tools can be when they rely purely on static signatures to spot malware. However, I am talking about creating signatures that are very specific to your organization at a particular moment in time; in other words: context-specific signatures. Such signatures might be useless for another enterprise, or in your organization two weeks from now. However, they can help assess the scope of the intrusion when responding to a particular incident.

Tools for Creating Custom Signatures

Anti-virus vendors generally don't let you create and deploy your own custom signatures using their scanning engines. Some IDS tools have a similar limitation. Not all is lost, though. Intrusion detection tools such as Snort make it fairly painless to write your own detection rules for the network. Also, you can use regular expressions when examining logs. And you can deploy login scripts to look for particular files, processes, mutex values, etc. at the host level.

Moreover, there are at least 3 free tools you can use to scan the file system of enterprise hosts for malicious artifacts using custom signatures. These are: ClamAV, YARA and Vscan. You can also use the free memory analysis tools Audit Viewer (with Memoryze) and Volatility to examine a system's memory for the signs of intrusion. The goal of using such tools is to scan systems across the enterprise to determine which of them might also be involved in the security incident.

What do you think about the effectiveness of context-specific signatures for incident response? Do you have additional tools or tips to recommend? Please leave a comment.

Lenny Zeltser focuses on safeguarding customers' IT operations at NCR Corporation. He also teaches how to analyze malware at SANS Institute. Lenny is active on Twitter and writes a security blog.


Posted April 12, 2011 at 7:06 PM | Permalink | Reply

CP Constantine

IDS signatures are nothing without context, and few real-world attacks trigger only a single signature. I've found that piping IDS logs into a SIEM, and matching for patterns of signatures, or signatures in context with other log sources, to be far far more valuable than what the IDS alone can provide in terms of context, and far better at prioritizing what to look at in a sea of IDS log entries. Additionally, by going for particular patterns of signatures firing, there's far less need to ''tune' IDS (a task I've always found tiresome and rarely approached with any real of methodology to it).

Posted April 13, 2011 at 11:27 PM | Permalink | Reply


Great post and thanks for the mutex link! I'm also really interested in network based IOCs. I just discovered vortex recently which saves the contents of TCP flows, and can be used as the base of an NRT IDS. Vortex doesn't come with any signatures and leaves it all up to the user.
Charles Smutz gave a nice intro to vortex on his blog, but I think some more examples of vortex would be a great blog post if anyone is up for it. howto