Security Adviser | Roger A. Grimes » TAG: User behavior

March 14, 2008 | Comments: (0)

To solve the unsolvable problem

TAGS: User behavior

At least once a week someone comes to me with an unexplainable, random problem that they begin to think might be malware-related. Some of the scenarios are almost laughable. Here's one I heard this week: "We upgraded the file servers for a particular application last week, and now we are having random printing problems. Do you think it might be a computer virus?"

They seemed surprised when I tell them I don't know of a malware program that causes random printing problems on upgraded server applications. What are they thinking? I guess security people are pretty good troubleshooters to ask during an "unexplainable, random problem" scenario. Security people usually have a strong understanding of host and network mechanics and years of experience. And unexplainable, random problems are some of the hardest in the computer world to troubleshoot.

So when I have a client or friend faced with a "random, unexplainable problem," here's what I tell them:

First, there is nothing random in the computer world. Ask any crypto programmer. They spend their lives trying to create realistic randomness but know it doesn't truly exist in the computer world. They can get to very good approximations of randomness, but true randomness does not exist. Computers can't do random. They are full of ones and zeros, positive and negative charges, and logic gates. They only do what they are told. It is always cause and effect. If it appears random, then you need to find out what specific set of conditions has to be true for the problem to manifest.

Next, when faced with the "unexplainable problem," the best thing you can do is to figure out what the problem isn't. You can do this by testing various scenarios that will either rule in or out a particular cause or symptom. You want to try things that separate problems into one type of problem versus another.

The idea is that you want to test scenarios that make big distinctions. It's like asking someone to guess a number between 1 and 100 using the smallest set of guesses possible. The first guess should be something like, "Is it above 50?" or "Is it below 50?" The idea is to rule out or in the biggest set of possibilities first. If the number holder said yes to the first question, the second question would be, "Is it above 75?" and so on. Do the same thing with your unexplainable problem.

For example, with a printing problem, here are some possible questions: Does it only happen to certain people or computers? Does it only happen to one application on the computer or all applications? Does it only happen to particular printers? Does it only happen during particular times of the day? Does it happen if the person prints locally or only over the network? Does it happen if you switch out printer models?

Once you've narrowed down the larger problem, start to test smaller and smaller operational scenarios. When faced with the unexplainable problem, you want to continue to rule in our out particular symptoms until you narrow down the exact problem. Once you have identified the exact problem, the solution is usually only minutes away.

Of course, anyone with any computer troubleshooting experience will always tell you to test what changed last (if that is possible). And if the end-user complaining says nothing changed recently, it's good to be skeptical. It's amazing how many end-users claiming "I didn't change anything" changed something major when their memory is refreshed a little.

I have some other hints: Troubleshoot along the OSI model. Don't forget to check physical connections. You'd be surprised how many unexplainable problems turn out to be cables that just went bad at the same time as a system got upgraded or how that little crimp in the network cable ends up causing sporadic problems, or only causes timeouts under heavier traffic loads.

I'm also a big fan of network sniffing. Download Wireshark and sniff a traffic session from something that is working correctly and the problematic workstation, and then troubleshoot the differences. Look for handshakes, re-transmits, and timeouts.

In the end the random, unexplainable problem is normally just a simple setting or misconfiguration mistake. And of course, it can't hurt to do a malware scan if just a particular workstation is involved. I don't normally suspect malware right away in most normal troubleshooting scenarios, but you never know ...

Posted by Roger Grimes on March 14, 2008 03:00 AM

January 25, 2008 | Comments: (0)

Control user installs of software

TAGS: User behavior

Learn how to verify the status of applications and data without wresting all control over what users put on their hard drives

I've written many times over the years, including as recently as last week, that letting users execute and install their own software will always allow viruses, worms, and Trojans to be successfully installed. Traditionally, I've recommended that users not have admin or root access, that they let system administrators choose what software is allowed and what is blocked. But this recommendation breaks down for several reasons.

First, it doesn't cross over to home computers. Most home users are end-users and system administrators, all in one, even though they're the ones most likely to install malware. Businesses, in general, are less likely to run malware than the average home user because businesses enforce computer security, deploy anti-malware programs, and so on.

Second, I can't think of a single end-user who likes to have someone else decide what they can and can't run and install. I've probably had more hate mail and comments on this than on anything else (other than when I foolishly insult Mac or Linux users). If end-users want to install the latest Windows Media Player codec to watch the newest Paris Hilton waste-of-AV-time video, why not? Who cares if the codec is a Trojan that wants to steal their identity, right? Freedom comes with a cost! I've even had respected InfoWorld colleagues take me to task on this point.

An expert solution
One solution is not to have someone more knowledgeable about nasty software decide whether a particular program or downloaded content is malicious, but to automate the process. I'm not just talking anti-virus programs, which look at only binary signature comparisons and sometimes use heuristics to detect specific behaviors. I mean client-side software examining the program's or content's entire binary (think: cryptographic hash) and making an intelligent, informed decision before the content is executed or loaded.

Several personal firewalls, including ZoneAlarm, will check to see if a local program requesting outgoing network access is normally approved by other users. This is closer to what we need, but it covers only network access and around 100,000 applications. It doesn't prevent local execution, but that's to be expected for a firewall product.

SignaCert, which I've reviewed before, is developing a global file hash database, through which it hopes to catalog every executable file in existence. SignaCert excels at scanning computers to find known and unknown programs, and it's in possibly the best position to contribute to (or lead) the greater vision.

The greater vision
The greater vision is that all computers run a client-side program, potentially embedded in the operating system, that measures the cryptographic hash of all programs and content being downloaded to the computer. Before the program is run or the content loaded, the hash is sent to a global database on the Internet for analysis. The database has a list of programs and content, as well as their related cryptography hashes. Additionally, each registered program has been ranked by security professionals as to the program's security, privacy, and operational methodology. There can be several main categories, each with varying levels of trust, that developers work with. Think of it as kind of like Common Criteria, but with a broader scope.

The idea is that the global database can act as each end-user's personal security advisor and recommend a go or no-go decision. A simple end-user message might say, "This program has been found to collect personal identifiable information, redirect Internet browser searches to paid locations, make potentially malicious modifications to your computer system, and send collected information over outbound network connections to multiple servers. Its legitimate intent cannot be confirmed. Most users have chosen not to install."

Another program, having the exact same behavior, might come from a trusted vendor and be recommended for installation. But at least the end-user would know that the program modifies their system in readily transparent ways. This might encourage legitimate vendors from slipping in "phone home" features without making users aware of why they're doing it.

Media content can be verified not to have known backdoors, malicious scripting, or other unexpected consequences. By default, unregistered programs and content would not run, or they would be subjected to additional scrutiny and controls (for example, sandboxing). Many programs are digitally signed today, but users still don't know what they do.

It is unrealistic for most end-users to be as knowledgeable as a 20-year computer security expert. So doesn't it make sense for us to help innocent end-users, who just want to do their jobs and have a little fun with their computers, make informed decisions?

Because ultimately, we don't want to stop end-users from installing and running any programs they want -- just the bad ones.

Posted by Roger Grimes on January 25, 2008 03:20 PM