6 Security Mistakes Your Management & Security Pros Are Making

By Roger A Grimes Sep 14th 2012
The same security missteps play out again and again. Why can't management focus on the practices that actually lower risk? On the flip side, computer security engineers must know their priorities and work down the list -- now.


One of the joys of being a traveling consultant is I get to see what does and doesn't work across a wide range of products and companies. Guess what? The same issues pop up again and again.

Here are the three most common big mistakes I see senior management make regarding computer security. Some are errors of omission, others of commission. All of them tend to have severe consequences.

One of the joys of being a traveling consultant is I get to see what does and doesn't work across a wide range of products and companies. Guess what? The same issues pop up again and again.

Here are the three most common big mistakes I see senior management make regarding computer security. Some are errors of omission, others of commission. All of them tend to have severe consequences.

1. Buying vendor hype without testing
Almost every computer security product promises the world: Zero false positives! 100 percent accuracy! Hackers banished forever! Those of us in the field know such claims can't be met -- at least not in any practical way. The cost would be impossibly high.

For antimalware software to reliably detect 100 percent of all malicious apps, for example, it would take the product 10 times longer to scan, it would slow down your system even more than it already does, and you'd have to put up with an incredible number of false positives. The accuracy level today seems to be the best we can get without reducing our PCs to a crawl and generating excessive false alerts.

Faced with hyperbolic claims, senior IT management needs to behave like Doubting Thomas and challenge vendor assertions. When the sales pitch reaches a crescendo, say two simple words: "Show me." Make the vendor install the product for an extended test. Tell your vendors ahead of time that that your team is known for making the vendor to prove its claims in a real-world testing scenario.

Proof-of-concept testing tends to get a few results. First, it makes the vendor put up or shut up. Second, everyone gets to see how it works in a real-world environment. Third, the testing phase tends to build good vendor relationships. Everyone gets to learn about each other, friendships form, and a better outcome is more likely.

2. Focusing on the wrong priorities
This is my pet peeve. It's rare I find a customer who actually focuses on the cause of the biggest problems. For example, when a company's security is compromised, in most cases an end-user was tricked into running a Trojan or exploited via unpatched software. That's the case for 99.9 percent of all exploits. Yet almost every shop I visit has poor end-user education and poor patching. Usually the stuff that's most exploited (like Java) ends up last in line for patch updates.

I get invited to help install PKIs, network access control products, intelligent firewalls, and a bunch of other items that rarely have a big impact on the security of the environment. The customer spends hundreds of thousands -- if not millions -- of dollars on a huge, "advanced" rollout that probably won't net much bang for the buck.

If you're a CIO or CSO, do you know for sure what's causing the greatest number of exploitations in your environment? Do you have metrics to back it up? If so, are you committing the right amount of money and other resources to address the biggest problems in your environment? If not, what's stopping you?

3. Not accounting for drift
Consistency is the bane of hackers. Drift is how far off from the original configuration a computer or device has become. Less drift equals a lower security risk.

If I were ever a CSO again, I'd make most of my monthly metrics report about drift. How many end-user computers are running apps neither installed nor approved by IT? How many computers didn't get fully patched this month? How many servers are no longer configured the way we originally configured them? How many IP addresses aren't managed? The list goes on. The more IT stays on top of these factors, the lower the risk.

What can you do about these mistakes? For starters, it can't hurt to print out this article and "accidentally" leave a few copies around the office.

The incentive is weak: No one gets credit for a breach not occurring.

Now let's examine the three biggest mistakes computer security engineers commit -- and have to answer for when they deal with senior management. You'll notice a resemblance between the above and what follows. No coincidence there; the issues are similar, though they differ in the details.

Let's take a look at the problems.

1. IT security's misplaced focus
Rarely is the entire IT team focused on preventing the malicious causative agents that allow exploitation to happen. In part that's because the incentive is weak: No one gets credit for a breach not occurring, although if your ducks are in a row, you might avoid blame if the bad guys wreak havoc.

In fact, fighting malicious hackers and malware requires a sustained effort. It's war, so you need to approach the task with a battle mentality. A good general evaluates all the threats in the battlefield, assigns priorities, and attacks the biggest ones first. In the IT security world, it seems as if we all acknowledge the biggest threats, then fight side skirmishes and wonder why we aren't winning the battle.

What is the biggest threat? In most environments, it's people running software they shouldn't, such as Trojan horse programs. They visit a website they trust and get prompted to run or install an innocent-looking agent that turns out to be malicious. Or they get a realistic-looking phishing email that tricks them into running a program or revealing their logon credentials.

If this is the case in your environment -- and it probably is -- you need to start by updating your end-user education material. Does your end-user education curriculum tell your users they're most likely to be infected by visiting a website they trust? Does it tell them to never click on a link sent by an external vendor asking them to verify their logon credentials? Does it tell them that fake antivirus software abounds and show them a picture of what their legitimate antivirus program looks like? Do you run tests that gauge users' reaction to simulated real-world threats with "phish-me" type programs?

Maybe -- but more likely, your end-user education program (if you have one) is still responding to last decade's threats, such as computer viruses, rogue email attachments, macro viruses, and the hazards of "untrusted" websites. Most end-user education programs tend to be a side job for one employee. If senior management and IT engineers put the right amount of resources into end-user education, the department would probably be bigger and have more overall sway in the IT environment.

Whatever your biggest exploitation problem, focus there. Spend the money, resources, and human capital needed to tackle your largest roadblock first and work your way down this list. Communicate the biggest threats to senior management, and fight those battles in the trenches week after week. Most important, tell your users to never hesitate to call IT security if they think they've done something wrong or potentially risky -- and assure them that they won't get in trouble for being proactive.

2. Inconsistent patching
I've yet to run a patch-checking program on a computer that was fully patched. I frequently go to companies and hear all about their wonderful, automated, timely patch management systems. Then, when I audit the first computer, it's missing patches. Usually they've patched Windows and its applications, but not all the browser plug-ins. Java and Adobe Acrobat Reader are notorious for falling behind, but it isn't just them. On servers, I frequently find outdated server management software, known-to-be-vulnerable versions of backup services, and myriad unnecessary programs (if you don't need it, get rid of it).

To put it bluntly, patching sucks in so many shops. I'm not talking just being a little tardy with patching, but being years out of date. In fact, the majority of exploited, unpatched software has had vendor updates freely available for one or two years.

How to fix it? Start by finding out if your patch management system even checks for all the patches. Most don't. You can prove it by going to any workstation or server and listing every program installed on it, then checking a CVE database to see what versions are vulnerable. You'll need to do this manually, because even my absolute favorite patch-checking program, Secunia CSI, doesn't list everything despite covering more than 10,000 programs.

The first few computers you check will require a few hours of homework. But pretty soon, you'll build a quick cheat sheet of the most common applications and their appropriate versions. Or start easy and make sure every computer in your environment running Java or Adobe Acrobat Reader has the latest version and enable auto-updates, if appropriate. At least get those patched (or removed altogether if not needed). Then you can move on to less popular programs.

3. Proactive monitoring
It's also very rare that any organization has deployed comprehensive event monitoring. Or it's enabled only on servers or domain controllers. Now remember, I just said that most attacks happen on the end-user desktop. So, uh, shouldn't those computers be among the most heavily monitored?

Event log management is horrible in most environments. The biggest threat is socially engineered Trojans, but most event log management programs are implemented so generally that there's hardly any value. They focus on dozens, if not hundreds, of other events that don't address the No. 1 problem.

Start by asking what needs to be monitored to detect malicious attacks. In many cases, that would be unexpected program execution, such as a Trojan horse program or a worm. For this sort of monitoring, I prefer to use whitelisting or application control programs. You can run most of them on one or more reference computers, and the software will usually do the software inventory and make the rules. Thereafter, the idea is to block unknown software, although that may be impractical in this day and age. Instead, you can use your whitelisting program to alert users to all the unrecognized executables.

The biggest problem in IT computer security isn't that the bad guys can attack us a thousand different ways, although that's inarguably true. No, the real problem is that we don't prioritize and focus appropriately. I hope the two parts of this article will be a wakeup call.

Almost every computer security product promises the world.