By Adam Dodge 

We generally treat problems with information technology as singular events. If a hard drive fails, we replace it. If a port on a router stops working, we switch to another port (or replace the router if it is a large enough problem). In other words, when something with technology goes wrong we tend to simply replace or fix the problem without thinking about how the problem might have affected other parts of the organization.

Generally, this type of reactive response to a singular event is a good thing. It allows organizations to quickly recover from problems and get operations back up and running with a minimum of downtime. The problem is that, since Information Security has grown out of IT in many organizations, security incidents are also treated as singular events. Organizations tend to replace or repair a compromised machine quickly with the belief that it was the only machine affected.

The danger here, of course, is that once an unauthorized individual has access to a machine inside the network, this intruder can then launch attacks against any computer the compromised machines can access. Therefore, to assess the damage of the security breach to the organization fully, we must look at several things.

First, we need to look at the compromised machine. Look at what the computer was running, where it was vulnerable. This can help you find out how the breach occurred. Then we need to consider what information the computer contained. With many states enacting breach notification laws, it is important to make sure the organization is fully aware of what information is at risk.

One important point is to search for any “hacking” tools that might still be on the computer. This can not only help us understand how the intruder was able to gain unauthorized access, but also help us find out if any other computers are susceptible to the same tools. Most organizations today run one or perhaps two main operating systems across all computers. While a homogenous OS environment has many benefits, if a security vulnerability is left open, all of the organization’s computers might be at risk.

This brings us to the second factor we need to look at, what computer systems are network reachable by the compromised system. This question could yield as few as zero machines or as many as every system in the organization. It all depends on the network structure of the organization. However, once we have the list of reachable machines we can begin finding out how far the breach penetrated the organization.

While the size of the list of possibly compromised computers might vary, we can narrow this list even further by ruling out machines that most likely were not affected. To do this we should look at the tools or methods used to compromise the initial computer. Did this breach target a vulnerability in Windows? Were additional Windows “hacking” tools discovered on the computer? If so, it would be practical to limit the scope of the investigation to only those Windows computers in the organization that are affected by these tools and this vulnerability. Also, checking network/firewall/IDS logs, if they exist, can help us determine what traffic originated from the compromised machines and where this traffic was headed.

The last step in this process is to repeat steps one and two if any additional computers are found to have been compromised. Different computers can often be gateways to different parts of the organization’s network. If nothing else, each additional computer compromise found will mean additional information that might have been exposed to this unauthorized individual.

The drawback in the process is that it takes time. The beauty of fixing problems as if these problems are singular events is that the organization can fix the problem(s) and have things back to normal quickly. However, doing so with Information Security incidents overlooks the fact that a single security breach exposes much more than the computer initially compromised. Without looking into how deep the breach penetrates into the organization, we can never be sure that the risk has been mitigated even after the initial computer is patched.

To recap the steps:
1. Examine the initial computer to determine what information was exposed and how the breach occurred. (Including looking for “hacking” tools on the breached computer)
2. Determine what machines the breached computer can connect with and put together a list of machines that might have been affected as well.
3. For each of the machines on this list repeat the first two steps until the organization has a good understanding of the scope of the security breach.

About the Author Guest Blogger

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Don't know where to start?

Check out Security Catalyst Office Hours to meet your peers and celebrate the good, help each other, and figure out your best next step. We meet each Friday… and it’s free to attend.