To decrease security risk, most companies try to do too much. They have dozens of "top priority" security projects, few of which they ever complete and even fewer that are done well. The irony: Little of that activity addresses the threats most likely to compromise an enterprise.

The No. 1 defensive measure any company can take is to prevent unauthorized programs from running on any computer. Most often, bad guys break into companies through holes in unpatched software -- and when they do, they almost always end up running hacking tools. Prevent those hacking tools from running and you'll reduce risk by 99 percent.

The best way to do that is to use an application control program, aka whitelisting software. Basically, you allow only those programs on the list to run and block everything else.

I realize we live in the consumerization era, where you're supposed to be able to download apps and subscribe to cloud services to your heart's content. But at a certain point -- especially if your company has high-value information worth stealing -- you have to ask yourself: Do I or don't I want to stop attacks?

Here's my own personal cliché about whitelisting: The single best thing you can do to prevent hacking is to use whitelisting programs. If you can't, then you have to do everything else. And everything else will not work.

Clearing the whitelist hurdleWhitelisting programs are notoriously hard to deploy in a corporate environment. Most people and most cultures won't stand for being told what they can and can't run. Management must truly understand that only whitelisting can shut down hacking. Without total support from management, you won't get a whitelisting project off the ground.

At least, you won't be able to get it deployed across the company. But as a sort of pilot program, you can deploy whitelisting on your company's servers, which change rarely in comparison to the average user's computer. Most infrastructure servers (file servers, DNS, Active Directory, and so on) are great places for whitelisting proof-of-concept projects.

Start the whitelisting program and snapshot the host. The whitelisting program will create all the rules necessary to allow the software on the current computer to run. Then enable whitelisting protection, but in audit mode only. Let it run for a week or longer and see what shows up in the logs as items the whitelisting software would have blocked. Update your rules to take into account the new stuff you found, then enable the full force of the whitelisting program.

Yes, you'll encounter a few bumps in the road and learn a few lessons, but you'll be on the path to truly secure computing while everyone else is twiddling their thumbs and wondering why they continue to be hacked.

The hard part: Updating the listYou'll need an approval committee that reviews new software addition requests. If you want a sustainable whitelisting initiative, that committee should be built for speed. If you can't approve most new requests within one or two days, don't start a whitelisting program. In fact, you'll need an effective fast-track process where someone can review and approve software on the spot -- or at least within one or two hours.

If you can respond with speed and prove it over and over, most of the people who claimed they were going to hate whitelisting will become fans.

Most -- but not all. Some will insist that the ability to try new software has become essential to productivity and they should be free to experiment however or whenever they like. In certain environments, that may be true.

But if you work in an organization that's been the victim of a breach or other major hack, I bet you'll find allies -- because whitelisting is the only preventive measure that truly works.