EMERGENCY NSM IN ACTION
I have had the good fortune to perform several incident response activities at several
huge corporations. One of the sites suffered systematic, long-term compromise
during a three-year period. Several colleagues and I were asked to figure out what
was happening and to try to cut off the intruder’s access to the victim company.
We performed host-based live response on systems the corporation suspected
of being compromised. The results weren’t as helpful as we had hoped, as live
response techniques largely rely on the integrity of the host’s kernel. If the victim’s
kernel were modified by a loadable kernel module root kit, we wouldn’t be able to
trust the output of commands run to gather host-based evidence.
Using this information, we began an “intruder-led” incident response. All of the
systems the intruder contacted were rebuilt and patched, and a site-wide password
change was performed. When the intruder returned, he couldn’t access those systems,
but he found a few others he hadn’t touched in round one. Following the
end of his second observed X session, we remediated the new list of compromised
systems. Once the intruder had no luck reaching any system on the client network,
we considered it more or less “secure.” I continued performing emergency NSM
for several months to validate the success of the incident response plan, eventually
replacing full content data collection with Argus.
The most useful emergency NSM data is session-based. Argus can be quickly deployed
on a FreeBSD-based system and placed on a live network without concern for signatures,
manning, or other operational NSM issues. Argus data is very compact, and its contentneutral
approach can be used to validate an intruder’s presence if his or her IP address or
back door TCP or UDP port is known. Beyond this point lies full-blown incident
response, which I leave for other books beyond the scope of this one.
BACK TO ASSESSMENT
We end our journey through the security process by returning to assessment. We’re back
at this stage to discuss a final NSM best practice that is frequently overlooked: analyst
feedback. Front-line analysts have the best seat in the house when it comes to understanding
the effectiveness of an NSM operation. Their opinions matter!
Too often analyst opinions take a back seat to developer requirements. I’ve seen many
NSM operations struggle to overcome developer-led initiatives. While developers are frequently
the most technically savvy members of any NSM operation, they are not in the
best position to judge the needs of the analysts they support. Analysts should have a way
to communicate their opinions on the effectiveness of their tool sets to developers.
The most important channel for communication involves IDS signature refinement.
Many shops task engineers with developing and deploying signatures. Analysts are left to
deal with the consequences by validating events. The signature might be terrible, alerting
on a wide variety of benign traffic. Managers should ensure that analysts have an easy way
to let engineers know if their signatures operate properly. A simple way to accomplish this
goal is to offer a special “incident” category for signature feedback. By validating events
with this unique value, engineers can quickly determine analysts’ satisfaction with rules.
Engineers should remember that rules that cause too many useless alerts actually harm
detection efforts. Analysts would be better served by more accurate alerts that represent
truly significant events.
Bejtlich, R. (2004). The Tao of Network Security Monitoring: Beyond Intrusion Detection. Addison-Wesley Professional; 1 edition.