SHORT-TERM INCIDENT CONTAINMENT
Short-term incident containment (STIC) is the step taken immediately upon confirmation
that an intrusion has occurred. When a system is compromised, incident response
teams react in one or more of the following ways.
1. Shut down the switch port to which the target attaches to the network.
2. Remove the physical cable connecting the target to the network.
3. Install a new access control rule in a filtering router or firewall to deny traffic to and
from the target.
Any one of these steps is an appropriate short-term response to discovery of an intrusion.
I have dealt with only a handful of cases where an intruder was allowed completely uninterrupted
access to a victim as soon as its owner recognized it was compromised. Most
sites want to interrupt the intruder’s access to the victim. Note that I do not list “shut
down the server” as an acceptable STIC action. Yanking the power cable or shutting down
the system destroys valuable volatile forensic evidence.
Initiating STIC gives the incident response team time and breathing room to formulate
a medium-term response. This may involve “fish-bowling” the system to watch for
additional intruder activity or patching/rebuilding the victim and returning it to duty. In
both cases, emergency NSM plays a role.
EMERGENCY NETWORK SECURITY MONITORING
While STIC is in force and once it has been lifted, the NSM operation should watch for
additional signs of the intruder and implement enhanced monitoring. In cases where
round-the-clock, wide-open full content data collection is not deployed, some sort of
limited full content data collection against the victim and/or the source of the intrusion
should be started. As we saw in earlier chapters, the only common denominator in an
intrusion is the victim IP. Attackers can perform any phase of the compromise from a
variety of source IPs. Once a victim is recognized as being compromised, it’s incredibly
helpful to begin full content data collection on the victim IP address. Having the proper
equipment in place prior to a compromise, even if it’s only ready to start collecting when
instructed, assists the incident response process enormously.
Emergency NSM is not necessary if a site already relies on a robust NSM operation. If
the organization collects all of the full content, session, alert, and statistical data it needs,
collection of emergency data is irrelevant. In many cases, especially those involving highbandwidth
sites, ad hoc monitoring is the only option. Once a victim is identified, ad hoc
sensors should be deployed to capture whatever they can.
It’s amazing how many organizations muddle through incident response scenarios
without understanding an intrusion. It’s like a general directing forces in battle without
knowing if they are taking the next hill, being captured by the enemy, or deserting for
Canada. Emergency NSM is one of the best ways to scope the extent of the incident, identify
countermeasures, and validate the effectiveness of remediation. How does a site really
know if it has successfully shut out an intruder? With NSM, the answer is simple: no evidence
of suspicious activity appears after implementation of countermeasures. Without
this validation mechanism, the effectiveness of remediation is often indeterminate.
I volunteered to start emergency NSM. The client provided six Proliant servers,
on which I installed FreeBSD 4.5 RELEASE on each system. I placed each of the
new sensors in critical choke points on the client network where I suspected the
intruder might have access. I started collecting full content data with Tcpdump
and statistical data with Trafd.27 (Back then I was not yet aware of Argus as a session
data collection tool.)
Shortly after I started monitoring, I captured numerous outbound X protocol
sessions to hosts around the globe. The intruder had compromised numerous
UNIX systems and installed entries in their crontab files. These entries instructed
the victims to “phone home” at regular intervals, during which the intruder would
issue commands. In one of the X sessions, I watched the intruder for 53 minutes.
He moved from system to system using valid credentials and built-in remote
access services like Telnet and rlogin. He unknowingly led me to many of the systems
he had compromised.