Yet another strategy for reducing risks is to disable JavaScript when it's not needed. Unfortunately, JavaScript makes the World Wide Web go around and disabling it completely will significantly interfere with most websites. Many browsers allow JavaScript to be disabled or enabled on a per-zone/per-site basis. Browser add-ons such as Firefox's NoScript offer an interesting way to control malicious JavaScripts but may require a level of decision expertise that end-users don't possess.

Disable JavaScript in applications where you don't need it. For example, any of the exploits against Adobe Reader would not be successful if its default JavaScript functionality was disabled, either manually or by using a registry edit. Unfortunately, Adobe Reader updates have a history of re-enabling the JavaScript functionality.

Some people recommend using less-attacked software, and there is some validity to this approach. However, if your software selection becomes popular, it will be attacked. But the bigger problems are operational issues, supportability, installation, and control of less-popular programs. Most companies would be better off concentrating resources into what they know and support. In reality, most of the "more secure" alternatives actually have at least as many security holes as the "less secure" products they are replacing. And while obscurity is a valid defense (I often promote it), it shouldn't be your only weapon.

Another way to decrease security risk is to significantly limit where users are allowed to browse the Internet, if at all. Remember, most malware and malicious hacker attacks begin from compromised legitimate websites that the user trusts. If you use this method to cut down on risk, the end-user should have a highly restricted list to the bare minimum necessary to support the company. If you can't prevent access to popular social media sites, you're not getting a lot of bang for the buck.

A lot of readers ask me if virtualizing the user's browser session will help. It can, but it isn't the panacea that most security defenders think it will be. Most of a virtualized application's protection comes from the ability to reset the app to clean state whenever it is restarted or when the end-user suspects a malicious action has occurred. However, in every real-life virtualized environment I've seen, both admins and end-users typically extend as far as possible the time between resets, which defeats the purpose. Even if you reset the virtualized app every day, it takes only minutes for malware to steal passwords and run other scams.

Of course good, updated antimalware defenses are needed. I may not be a huge fan of the increasingly less-accurate antivirus software, but it's worth installing and using in most scenarios. They may not be 100 percent accurate, but they catch bad elements.

I am a strong advocate of security-domain isolation, restricting workstations and servers so that they connect to only what they need. It can be accomplished using myriad methods, including routers, firewalls, VLANs, IPSec, and other avenues of logical separation.

Lastly, implement improved end-user education. Thoroughly train your end-users on how to detect and prevent the most popular attacks, such as compromised legitimate websites, fake antivirus programs, malicious software installs, phishing attacks, and so on.

If you have no choice but to allow all end-users elevated access, you've lost a significant wall of defense. Still, with the tactics I've shared, you have ways to carry on the fight against malware and malicious attackers.