Saturday, January 17, 2009

Four things to do with computer forensic tools (besides forensics)

When staffing an internal computer forensics capability for an organization, management needs to determine how to balance capacity with demand. At the extremes, you either have a backlog of cases waiting on available investigators, or investigators waiting on requests for support.

Even under the best of circumstances, the investigative caseload won’t follow a regular schedule and some amount of downtime is inevitable. Forensic analysts will need to spend some of that time putting together hash sets, updating scripts, evaluating new tools and doing all of the other arcane tasks that go along with keeping pace with the changing needs of the function. But for an IT risk manager, if you can tap into it, unused forensic capacity is an asset that can be extremely helpful in other contexts as well. Here are just a few examples:

1. Identify the prevalence of sensitive information on end user systems. Because they’re fast, thorough, minimally disruptive and often support remote data capture, forensic tools can help determine the “hit rate” of confidential documents across a randomly selected cross-section of the end user environment.
2. Measure the compliance rate against system usage policies. A scan of Internet usage can show the proportion of systems accessing content that poses a risk to the organization and/or its users. Over time, the amount should decrease if the training and awareness efforts are having an effect.
3. Estimate the amount of data at risk that is not being backed up. Depending on the architecture, this may be a bit more difficult to determine. A comparison of data files created or edited locally that are outside of backup routines will give a good sense of the amount of work lost each time a hard drive crashes, or a laptop is stolen.
4. Identify the level of unauthorized configuration changes. How long is the screen saver timeout supposed to be? What applications or changes are not allowed on a standard system build? This is less of an issue in organizations where IT has locked down the desktop. But where this is a contested issue, actually quantifying the impact can show the best tradeoff between control and usability for a given department or organization.

It goes without saying that nobody likes to be investigated. If the purpose, scope, approach and usage of this information isn’t spelled out in advance (i.e. good-faith random anonymous survey, not a warrantless wiretap) and communicated with the proper level of support, it’ll be the last time you get to try using forensic capabilities to tune security policies and practices.

But let’s face it – all of the critical data in any business either originates or is viewed from an end user system, which is often the least-defended part of the environment. Attackers realize this, and end user systems will always be a popular target. Unless you know what your exposure is, you won’t have a good understanding of what your policies and protection capabilities should be.

No comments: