Thursday, January 17, 2008

Which plug to pull?

For one reason or another I started thinking about pulling plugs tonight. I think this line of thought was actually inspired by Harlan's entry. As I was reading I started playing back some of the incidents I've responded to and I thought..."hmmmm now what factors go in to a decision to pull the plug, and which plug should be pulled".

Why do organizations rush to pull the power plug?
In my experiences it's due to a number of reasons - this is not exhaustive.

1) The environment is so dirty(lots of compromises) that pulling the plug is the safest move.

2) It's the traditional method, and it's been proven - so people are comforted by that fact.

3) Organizations haven't taken the time or effort to TRAIN their first responders or they just don't trust them enough.

4) Response time is so slow that the unfounded fear is that the volatile data will be lost before a trained responder can get to the system.

5) The environment is very sensitive and pulling the plug removes the possibility to lose sensitive data(more than they had already).

So then I started considering a few other points of interest. Suppose your network is monitored as in using netflow to collect "call records" or something more elaborate. Do you have enough information from a network log to remove the risk of losing data by pulling the network cable from the back of the affected system? Let's take a look at this shall we?

1) We can deduce which ports were open and those that were active until the network cable was pulled by evaluating network flow logs and system configuration after the fact.

If I have net flow logs that show traffic flowing to or from the system on say...port 445 I can say that port 445 was open, and listening and it had a connection to a remote host with IP a.b.c.d.

We can also reason that based on the system and the environment that certain ports are expected to be open. For instance, we know that a windows XP box will have a specific number of ports open and listening by default - unless there has been a configuration change to limit this or if software has been installed that changes this. In the case of the latter, we can obtain this information post mortem from the system or during an interview with a sysadmin.

2) If I pull the network cable I will lose data. This is true, but what am I losing? I will lose data from the output of maybe one tool that may or may not even return accurate information depending on the tool and if there is malware that prevents the accurate display of information. I may lose the specific point in time data related to the specific process that is running that is responsible for having an open socket and port. Have I lost the ability to analyze the executable? Have I lost the ability to analyze the system at a different point in time? If I have a Windows XP box on a domain can I expect the system behavior to be the same from day to day? Certainly there are variations that will occur (which domain controller authenticates the user for instance) but generally speaking the behavior of the system will be largely the same from day to day. Add some malware to the mix and what do you get? dynamic or static variance? By this I mean does the malware have a static footprint (it opens port 6669 and attempts to connect to that is the same between reboots, meaning that we have added a degree of variance but that variance will not itself change, or is it introduce a dynamic variance to the system (it chooses a different port each time and a different dns host between reboots), which is to say that it changes system behavior in a different way each time. This is tool marks all over again (opening a port and connecting to a dns host would be class characteristics, the specific ones would be individual characteristics). So to answer my own question have I lost the ability to analyze the system at a different point in time? No. Will system behavior be the same from day to day? Yes, this is due to the deterministic nature of computers.
Will the process stop running as a result of losing the network connection? Maybe, maybe not. But even if it does stop running can I determine this behavior of the malware after the fact? Yes I can.

What else do I lose? The one thing we lose without argument is the ability at that point in time to determine if sensitive data is leaving the network. Not if it has left or will leave, but if it is at that very moment in transit.

If we compare this to pulling the power cable, it seems like pulling the network cable is much more preferable and less damaging. So, let me codify this a bit.

Pull the network cable but not the power cable if:
  • Your environment has network logging at least at the session level.
  • The system can sustain the loss of the network cable being pulled.
Pull the power cable if:
  • Your environment demands this action.
  • You've collected live response data.

So to clarify..what am I saying? Pull the network cable instead of the power cable unless your environment demands otherwise.

What are people's thoughts on this?


Anonymous said...

When pulling the network cable, you would lose port and connection information. Blocking the computer's IP at the firewall sounds like a better alternative since the connections to the ports will remain...however, won't that disappear when the TTLs expire?

hogfly said...


Thanks for the comment. Blocking the IP at the firewall or router is definitely a good containment method.

I prefer a block over pulling any cable, but the intent here was to decide which plug to pull (power or data).

Keydet89 said...

Good post!

In my experience, organizations pull the plug simply because they have no other idea what to do. They have no plan for what to do when an incident occurs, and what is pertinent.

Visa PCI forensic audits are a great example. Many organizations (and I'm not talking the small restaurants and gas stations...) simply have no idea where the PCI sensitive data is processed or stored on their network. When something happens, they pull the plug, shut down power...again, because they don't know anything else. Fear takes over. However, the questions that need to be answered in a PCI forensic audit include, "was any data exposed?" How better to determine that than to have process information (including open file handles) and network information? It won't tell you if data was previously exposed, but it will give you an idea if data may have been exposed at the time the incident was discovered.

Why does this matter? In short, if your answer to the PCI questions is shrugging your shoulders, then you cannot prove that the data wasn't exposed, so you may be subject to fines and having to notify.

When firing their M-16s, Marines have immediate actions for jams, etc. These are things they are trained to do immediately, and they become almost subconscious. Sysadmins need to replace their "immediate actions" of yanking the plug with "capture data" first, then consider pulling the plug.

echo6 said...

Sysadmins need to replace their "immediate actions" of yanking the plug with "capture data" first, then consider pulling the plug.
LOL, the same could be said for some forensic analysts.