His point is an excellent one. Don’t listen to these folks; their pitch is unhelpful and fatalistic. It is possible to run a tight ship and dramatically reduce the likelihood of a breach; it is not inevitable that you will be hacked.

In our view here at Lithik, the keys are discipline and architecture. Disciplines like keeping your patches absolutely up to date–squeaky clean. Like running internal security audits or hiring them out, then actually acting on what you find. Not only to clean up what you discover, but also to change the way you do things to avoid getting in a “dirty” situation in the first place. Proactive.

And architecture. We have developed a simple perimeter network architecture that we believe provides dramatically better protection than anything else under ten times the price. See my article A Simplified Firewall Architecture for Combating Malware on this site for details on how we put together a powerfully secure perimeter from simple, off-the-shelf parts.

Go read Jeff’s article. Then, the next time you hear a convincing, buzzword-compliant pitch from some bigwig at a major security firm, take their words with a grain of salt.

The situation he describes is a perfect example of why we at Lithik Systems are recommending architectural protections to block the outbound connection from this kind of malware that makes it so deadly. Antivirus and firewalls usually can’t detect these things, which means you can’t keep them from getting in. But you do have a shot at keeping yourself safe if you can keep the infection dormant. Check out our article A Simplified Firewall Architecture for Combating Malware to see how.

The kind that puts banks your size out of business.

Is there anything you can do other than worry? Isn’t this stuff so complicated only grad students in computer science can understand it? People say that nothing is truly secure—isn’t that true?

You can do something about it, because hackers have adopted a relatively uniform mass-production approach to attacking computers. And yes, you can understand it.

How Malware Works

Hackers don’t pick your name out of a hat and then decide to attack you; that’s so 1999. Their desire to make a profit has driven them to use highly efficient and highly effective techniques designed to maximize the number of breached systems rather than maximizing their ability to breach a specific target. Their chosen approach is actually quite clever. Here’s how it rolls out:

1. A hacker penetrates a legitimate web site and modifies it so that a visiting web browser also pulls data from the hacker’s web site. The Google Anti-Malware Team recently found 3 million such URLs in a survey of Google’s stored copies of web sites.
2. A normal person visits one of these infected web sites, causing the web browser to also make a request to the hacker’s web site. The hacker’s web site determines which operating system and which browser the innocent web surfer is using, then sends back a series of specially crafted HTML, PDF or other file types that contain exploit data for commonly found missing patches. An exploit is typically a pattern in the returned data that causes the targeted software to misbehave in some way due to a bug introduced accidentally by the program’s author when he wrote it. The exploits are specifically aimed at the user’s operating system and browser in order to maximize the likelihood of a breach.
3. If the user’s computer is running some amount of unpatched software, and if at least one of the attacker’s chosen exploits matches up exactly with one of the user’s missing patches, then the hacker’s malicious pattern of data causes the user’s buggy program to actually execute software the hacker himself wrote and included as part of the malicious data pattern.
4. Typically the first thing the hacker’s software does is to issue more requests to hacker web sites, downloading and installing more malicious software.  It is rare to be infected by a single virus; malware usually arrives more as a malicious throng than a single stealthy intruder.
5. Once the hacker’s programs are installed on the user’s computer, his software runs and begins to carry out his wishes. Sometimes this means sending Spam e-mail messages to millions of people.  Other times it may mean spraying a specific web site with huge amounts of bogus web requests, a so-called Denial of Service attack. But the scenario that terrifies us is the one where the software on the infected machine makes a network connection to one of the hacker’s servers that doesn’t download software, but instead stays connected. The purpose of this long-term connection is instead to provide two-way communication. This gives the hacker a direct path from his server on the outside right through your firewall, a so-called backdoor into the heart of your company’s computer network.

Once inside, the hacker can do whatever he’d be able to do if he had free reign of your office. He can search through computer files, he can listen for passwords, he can record information displayed on customer account screens. He can also probe other machines on your network looking for more unpatched systems. Note that this is no longer an impersonal piece of automation running; now you have a real, live hacker rummaging through your data looking for something he can sell. And if it was that easy to get inside in the first place, it’s usually even easier to get access to the machines that contain all your customer data and ship it off to Russia. Or China. Or Cleveland.

According to the Verizon 2010 Data Breach Investigations Report, the U. S. Secret Service reports that, although insider attacks are up 26% over last year, 96.5% of all stolen customer records occurred through external attacks. 95% of those external attacks were attributable to malware, the kind we just described. 80% involved malware that was explicitly designed to provide remote access to the hacker, the kind that lets him steal all your customer data.

Traditional Defenses

Most anti-malware strategies involve trying to stop it from infecting you in the first place. Reputation-based browser features compare the link you clicked on against a database of sites that have been reported to contain malware, popping up a warning if it finds a match. So-called UTM (Unified Threat Management) appliances or next-generation firewalls look inside the web browser data stream searching for data patterns that look like exploits, or they examine the entire returned web page, making sure it adheres strictly to the HTML standard. Sometimes they even can figure out what web application you are running, tailoring their activities to the specific site or function.

The best known defense, though, is anti-virus. A few years ago, the leading anti-virus systems would catch 99% or more of all malicious software.  Today, the best anti-virus systems detect and block perhaps half of all infections, but if an infected web site launches twelve exploits at you, and if, say, four of them match up with patches you are missing, then you’d still have a probability of 1 – 0.5⁴ = 94% of being infected because of that one click.

It may not be the best known, but the most effective defense against malware in common use today is simple. Keep your systems patched! This has gotten much easier since Microsoft introduced Automatic Updates ten years ago. Unfortunately, the summer of 2009 saw Adobe break Microsoft’s long run as King of Vulnerable Software. Even more unfortunately, Adobe and the other commonly attacked desktop software vendors have not come close to matching the effectiveness of Microsoft’s efforts to provide patching tools (Automatic Updates and WSUS) and patch scanning tools (MBSA). See my article Keeping Windows Patched for more on this topic.

A Simplified Firewall Architecture for Combating Malware

It is certainly painful to have to deal with an infected machine. In most environments, the machine must be reformatted and reinstalled by hand, a job which can take anywhere from half a day by an experienced IT professional to as long as two days if a lot of software installation and reconfiguration must be performed. Using a disk imaging system can bring that time down to 20 minutes, but such a solution has its own costs. But the cost of recovering an infected machine never exceeds a thousand dollars or so. The real cost is in the risk of breach. That is where we should be putting our effort—making it as difficult as possible for an infected machine to establish a backdoor connection.

The funny thing is, this is the part that isn’t all that hard. The last few years have seen an explosion in the growth of cloud-based security products, especially filtering web proxies. A web proxy is a special server that acts as a mediator between a web browser and a web site. The addition of filtering capabilities, including all those features listed above for advanced firewalls, makes this a very attractive service. But we at Lithik Systems believe that the greatest benefit of such a service comes from what it allows you to do to your firewall configuration.

The reason the hacker’s malware can build that backdoor connection so easily is that nearly everyone has their firewall configured to allow outbound web browser connections to an unlimited number of destinations. If the firewall allowed web browsers to only go to a short list of places, the backdoor could never be set up. Many if not most corporate firewalls are configured to allow e-mail traffic only to a short list of e-mail servers. The same is true of many other services. If all Internet traffic originating from behind the firewall was only allowed to go to a fixed list of destinations, no backdoors could ever exist. This is easy except for web traffic, and if a web proxy service is used, web traffic can be controlled in exactly the same way.

You may say, though, that a backdoor can indeed exist. Even though it would be tricky, even though the malware would have to somehow figure out that you were using a web proxy, and even though it would have to figure out where it was and how to authenticate with it, the malware could go through the web proxy. That’s why it’s important that you choose a service that has a really good filter. That’s also why you probably shouldn’t simply install a cheap, non-authenticating web proxy server just outside your firewall. Future-proof your solution now.

But wait, there’s more.

Utilizing the above approach can eliminate (or nearly eliminate) the likelihood of an outsider stealing your data. But once your firewall is configured with no unlimited destinations in any rules at all, you have a new option in front of you. If the firewall is then set up to trigger an alarm whenever any kind of traffic is blocked trying to go to an unauthorized destination, you have an IDS (Intrusion Detection System) that can almost perfectly detect external breaches. An alarm means that the offending machine is infected. Now, it could also mean that someone just misconfigured some application, or someone just installed a program that didn’t know about the web proxy and tried to auto-update itself, but those situations will only happen when you should expect them, and the cause should be obvious. But if your firewall sends you a text on your cell phone when no IT people are making any changes, you almost certainly have an infected machine.

Cost-Benefit Analysis

Costs:

• $5 per month per desktop computer for a top quality web filtering service
• $50 per desktop for a permanent license to a good remote disk imaging system so you are never motivated to avoid reinstalling an infected machine
• Time and effort to configure the new setup

Benefits:

• A good filtering proxy will substantially reduce the number of infections you incur
• No fancy firewall features are required
• Infected machines can be cleaned in about 20 minutes
• Infected machines are brought to your attention immediately
• Patch management becomes easy (this is a side benefit of using a disk imaging system)
• A breach involving information theft is nearly impossible

Take Action

The above approach can dramatically reduce your risk of a serious breach.  The cost is moderate, and the side benefits are attractive. Do not put this off; talk about it with your IT staff and with your senior management, then make a decision. Choose wisely.

Our total capital expenditure, not counting licenses for the public servers themselves, amounts to less than $4,000. Our total monthly expense for data services dedicated to supporting the public servers is $150 for 2U of rack space in a secure colocation facility. We’re spending between 5% and 10% of what our customers spend for nearly the same feature set. We have

• Two complete sites, one in the secure colo and the other in a locked cabinet in an office with a 24×7 security alarm including sensors on doors and ultrasonic motion detectors
• A complete VMware virtualization environment at each site
• Locked down administrative access to all servers
• 24×7 monitoring of all servers, both physical and virtual
• Daily snapshot backups of all virtual machines, archived and 100% automated
• Daily automated backups replicated to the opposite site with 80:1 compression

We also get most of the benefits of a virtualized server environment, including the ability to

• bring up a new server, patch it, harden it, then connect it to the public network, all in minutes rather than days
• move a public server from one site to another in under an hour
• restore a virtual machine from an archived backup in under a minute
• tune virtual machine features such as CPU, RAM and disk storage to precisely match the needs of each server

We do not have automatic fail-over of servers, a very nice feature that only comes with redundant ESXi servers as well as paid versions of VMware vSphere. So far, the alarms, multiple sites and automated backups have been enough. Also, the servers in the office piggyback on the office environment, including power, security, and Internet connectivity.

Our two sites are essentially identical, so the rest of this article will describe only one site.

The Machines

We wanted to spend as little money as possible, but we also wanted enterprise level reliability and performance. So we chose a server model known to be rock-solid reliable that was also on the VMware HCL (Hardware Compatibility List), then pumped the machines up with the features we needed. Each site consists of two servers, each an older 1U Dell PowerEdge 860. One runs the free version of VMware ESXi; the other runs Ubuntu Linux 10.04 LTS. Each machine has 3 gigabit network interfaces and a pair of terabyte SATA drives in hardware RAID 1. The ESXi server has a quad-core processor and 8GB of RAM. The Ubuntu machine has minimal CPU and RAM, but both machines have plenty of disk for storing lots of virtual machine images and backup images. The Dell 860′s have dual Broadcom gigabit Ethernet ports, but they don’t support jumbo frames (9000-byte Ethernet frames), so we added Intel PRO/1000 PT single port server adapters to each machine to carry the large NFS packets needed for decent throughput.

The ESXi and Ubuntu servers each have a single connection to a local switch for public Internet traffic. The other two ports are connected by direct cables, server-to-server, to carry 1) NFS traffic, allowing the Ubuntu server to act as a NAS for VMware VMFS storage, and 2) VMware remote management traffic via SSH port forwarding through the Ubuntu server.

Secure Management Access

Routing all VMware management traffic through the Ubuntu server means we don’t have to expose any vulnerable VMware management ports to the public Internet.  Instead, we use SSH directly to the Ubuntu server, but with port forwarding enabled to the ESXi management ports, then we run the vSphere client directly on our laptops. This way, all management traffic travels through an encrypted SSH tunnel that only allows authentication by SSH key. Our company policy requires that all such keys on laptops be stored on encrypted hard drives, meaning that a stolen laptop doesn’t compromise access to our public servers. Since we use laptops with wireless networking, we can manage our server infrastructure from anywhere, and with uncompromising security while doing so.

The SSH server on the Ubuntu machine is locked down according to published best practices. No root logins are allowed at all, only SSH Protocol 2 is allowed (version 1 has uncorrectable vulnerabilities), and authentication is only allowed via 1024 bit or longer SSH keys.  We believe that exposing a password-authenticated service to the public Internet is just asking for trouble, seeing as you can expect a constant stream of password-guessing probes from bad guys. We also use iptables on Ubuntu to close any other ports that might otherwise be open. We allow pings and key-authenticated SSH; nothing else.  And nothing is exposed on the ESXi servers at all except for the intentionally configured public-facing ports of the virtual servers.

Service Resiliency

We enabled SSH administrative logins on ESXi using the unsupported Tech Support Mode that is intended only for customer service. Doing so allows us to use an open source VCB-like (VMware Consolidated Backup) tool that takes snapshots of running virtual machines and stores them in sparse virtual disk images on the NFS server. The ghettoVCB script can only run in the command line directly on the ESXi server, thus the need for enabling SSH. A new version is out that instead uses the standard VMware command line interface, but we haven’t installed it yet.

We are experimenting with automated replication of these backups between sites using rsync. Our current approach is to synchronize the latest snapshot of a virtual machine from one site directly over a copy of the previous day’s snapshot stored on the other site, thus taking advantage of the redundancy avoidance feature of rsync. This makes it feasible to synchronize a couple of hundred gigabytes of backups each night without really sending all that much data across the network. Current measurements indicate that this approach provides approximately 80-to-1 compression over sending the entire file directly.

Restoring a server or moving it to another site from a backup is simple. Since all backups are stored on the NFS servers, VMware can be configured in a minute or two to boot directly from any backup, which would subsequently serve as a virtual machine image. For better performance, or to preserve the backup, the VMware GUI or command line can be used to copy the archived image from the NFS server to the ESXi server’s internal disk, where it can then be booted directly. Having multiple, archived boot-compatible backups at each site provides great flexibility in choosing recovery methods.

One virtual server at each site runs monitoring software (we use OpenNMS, but Nagios would work just as well) that watches virtual and physical servers at both sites. If a server is down for more than a few minutes, an e-mail or text message is sent to the support group, initiating a recovery effort in as short a time as possible.

Try It, You’ll Like It

We have been extremely pleased at the results we have obtained from the above public server architecture. In fact, the only desired improvements we have been able to come up with are 1) bigger machines, and 2) adding remote management cards to each server, connected for security reasons only to the adjacent server. The advantages of server virtualization have been widely published, so with price out of the way, there should be nothing stopping you from jumping in with both feet.

So then, why is it that 90% of the time we here at Lithik Systems perform IT security audits, we discover hundreds, thousands, or even tens of thousands of patches missing from Windows, Office, Adobe, Java and other programs? It has been amply publicized that the vast majority of successful security breaches, that is, breaches that result in actual theft of proprietary information, occur through two avenues: visiting infected web sites and opening infected e-mail messages. Yet we routinely run into organizations, even organizations with CIOs and IT security staff, that don’t keep their systems up to date.

Excuses

The typical reaction of our customers, when faced with the evidence of their bad patching habits, is to apologize. “We’d love to be up to date, but it’s just such a huge job,” they say. “It’s our policy to patch, but we’ve been so busy recently that we just haven’t had the time.” Patching systems does take time, a lot of time, because even with automation, patches don’t always stick, and each failed patch means someone has to research the problem and, through trial and error, try to get it fixed. We’ve seen Windows installations that wouldn’t accept certain patches for months or even years until the machine was finally re-imaged, which often means a half of some tech’s day reformatting the broken machine, reinstalling Windows, reinstalling all the desktop and business apps, and bringing the configuration up to corporate standards. It’s a nightmare of a job.

WSUS (Windows Server Update Services), a free tool from Microsoft for deploying Windows and Office patches, is very popular and does a good job of minimizing Internet bandwidth use because, rather than having each desktop computer download each patch individually from Windows Update, WSUS downloads one copy of each patch from Microsoft, then distributes them across the internal LAN. It also comes with some nice deployment and status tools, allowing you to decide which patches should be applied and which should be held back (hint: They should all be applied. Always). But just like a 12-year-old boy, it doesn’t always tell the truth. Why is a mystery, but just be aware of the fact that WSUS lies, then use a patch scanner to give you the real skinny on which patches are actually missing.

Sometimes patches break critical applications. A recent client found that running Adobe Reader version X caused a business application used by a dozen or so of his users to fail, while version 9.1 worked just fine. One or two experiences like that and an IT person becomes gun-shy, never knowing which patch might break something, raining down wrath from irate users that just want to be able to do their jobs. So rather than risk being chewed out, he starts taking the “safe” way out. Safe for him, that is. Dangerously risky for the organization.

Build Your Own Windows Patch Management System

If all you want to do is roll out Windows and Microsoft Office patches, the options are pretty good. Microsoft Baseline Security Analyzer (MBSA) is an excellent patch scanning tool that quickly and accurately reports on missing patches and other security issues in Windows and Microsoft Office. WSUS is also useful, being a good soldier on the front lines, applying patches automatically while keeping your Internet connection from becoming overloaded. But to deal with the inevitable patches that don’t “take”, I like to use something that acts less like a lawnmower and more like a scalpel. WuInstall is a free tool that will install all missing Windows or Office patches on a specific machin or only the patches you specify. Tie this together with a login script or deploy it remotely using a program like PsExec that lets you push a command to a Windows machine across the network and you have a system that, either automatically or manually, cleans up the bits left behind by WSUS.

And servers? Patch them with WuInstall at night, then reboot them with PsExec. Put it in a script and run it with Windows Scheduled Tasks and now your server patches are 100% automated without disrupting business.

Not a bad system. All free software, near-complete automation. Too bad it won’t do Adobe patches.

Third Party Apps

So what can we do about third party desktop apps such as Adobe Reader, Adobe Flash, Adobe Air, Oracle (formerly Sun) Java, or other common desktop programs? WSUS and MBSA don’t deal with them at all. It’s no longer safe to just ignore them, because Adobe won the Number One Hacker Target title from Microsoft in the summer of 2009. Leaving your Adobe Reader installations at versions 7, 8 and 9 could end up costing your company millions of dollars—$6.6 million on average for the typical security breach, to be specific. You could buy patch management software such as Shavlik (the original), Lumension (formerly PatchLink), Secunia or others, but that costs money, and you may not currently have the budget for it. Or you could engage a third party service such as ours to do the whole job, but we charge for our services, too. Isn’t there a cheaper way?

Flying Blind

Here’s one way to patch your third party apps without spending a dime, but it’s not for the squeamish or faint of heart. It involves forcing out third party application updates but without the benefit of a software inventory of exactly what’s installed on each machine. WPKG is an open source system (that is, it’s free) that can be set up to automatically keep each desktop in your organization synchronized with a central repository of patch updates for a wide variety of third party desktop applications. The WPKG software discovers the currently installed version of each program to see if an update is warranted, but I’m not comfortable without a separate monitoring system that tells me if the patch application program is working properly. There are, of course, open source systems out there that will maintain a software inventory for you (OCS Inventory NG comes to mind). But this whole approach is starting to look pretty complicated, especially when you consider that it’s all in addition to the WSUS/MBSA/WuInstall/PsExec system for Windows updates.

The Imaging Solution

There is one clean, clean, clean way to update your machines, but it also has costs as well as some pitfalls. Remote imaging tools such as Symantec Ghost, Acronis, Altiris Deployment Solution, Microsoft RIS (Remote Installation Services) and others allow an IT administrator to make a single “gold copy” of a desktop computer, then push that image out to every desktop in the organization. It’s not as simple as it sounds, though, as similarity of hardware platforms is critically important, as is the amount of bandwidth available between your image server and the target desktop. But when it works, it’s sweet—run Windows Update once to a pristine machine, apply the latest Adobe and Java patches, then use the imaging tool to create a new gold copy on your fileserver. Then push the magic button and all your desktops are fresh and squeaky clean, up to date with Microsoft and all third party apps.

This approach also has a very important hidden benefit—what we at Lithik Systems call “malware shedding.” If a desktop becomes infected with a noisy virus such as those that pop up advertisements for fake antivirus software or certain unmentionable products, you know it right away. Or if a lazy hacker infects a lazy IT administrator’s desktop with an old virus allowed by a missing old patch, the antivirus system is likely to complain quickly and loudly. But what if the hacker is smart and subtle? What if the attack is of the zero-day variety, meaning that no antivirus system out there has ever heard of it, and no patch for the exploited bug has ever been released? Who can possible defend against such an attack? And what if the attack is of the “rootkit” variety that buries itself so deep in the operating system that no antivirus system has a prayer of ever finding it, even if it eventually becomes well-known?

Well, that’s where “malware shedding” comes in. If you re-image your desktops every month, say, on the evening of Patch Tuesday, every rootkit and every bit of malware will be wiped off your network, no matter how tenacious the rootkit is, and no matter how clever the hacker was. They’ll all be gone, because every single Windows desktop has been wiped, reformatted and reinstalled. This feature is extremely valuable.

Imagine also what happens when, some other time during the month, you get one of those calls from a user saying, “My computer keeps popping up ads for designer watches,” or “My computer is acting, well, strange.” “Have no fear,” you say, “take a 20-minute break and I’ll make your computer sparkly clean.” Tell the imaging tool to remotely re-image the user’s computer and the infection vanishes. No diagnosis is necessary; just use the nuclear option on every problem as your first step and you’ll be right 90% of the time.

Other costs of using imaging include the redesign and conversion effort required to move every user’s desktop and My Documents folders over to a nearby fileserver. You should already be doing this anyway so that user files are backed up with your server’s other files, but it’s an absolute prerequisite of the imaging approach. A wipe-and-reinstall will wipe out not only malware, but also any files saved or changes made to the local disk.

“But hey,” you ask, “what about monitoring?  What about your software inventory?  Isn’t that important?” Well, sure it is, but you only need to check one machine.  Go to Control Panel -> Add/Remove Programs and check the versions by hand. On just that one machine.  Or go to Secunia.com and run their free Online Software Inspector. It will scan your computer, telling you about any applications that are out of date, whether Microsoft or otherwise. It’s just like a professional patch management solution, except that it’s free and you only have to run it on one machine. Actually, it is a professional patch management solution. A really nice one, too.

A Bit of Common Sense

Now that you know how hackers find and capture their prey, you can come to some conclusions that make life a little less painful. Here are a few “therefores” that we should be able to count on:

• Not all machines are created equal. Given that attackers use web browsing sessions and e-mail sessions to infect computers, a server should never become infected because it should never run a web browsing session and it should never run an e-mail client. Keep that in mind and don’t do those things on your servers. This is important because it is much harder to recover from a server infection than from a desktop computer infection.  Much, much harder. It probably means rolling back to a backup, which probably means days of lost work, which may mean lost business.
• Some software purchases should be easier to justify than others. Paying $40 a desktop for permanent imaging system licenses could save you many times that much money in saved staff time, both because of accelerated IT diagnosis and rectification, and because of reduced downtime for the desktop PC user.
• You can’t tell if you’re secure unless you can measure it. Always use a reporting/scanning tool (MBSA, Secunia, etc.) to check your work.

Don’t be like all the others—be the outlier that actually keeps your systems patched. Do this and you’ll also be the outlier that never gets hacked. Well, probably never, anyway.

Click here for the slides.

If the idea of configuring Windows Group Policy makes you break out in a sweat, be afraid no longer. We’ll go step-by-step through the process so that even a relative neophyte can get good results.

GPMC

GPMC (Group Policy Management Console) is an excellent tool for configuring and managing Group Policy. If you don’t already have it installed, you can get it from here. Fire it up by clicking Start, selecting Run…, then typing gpmc.msc and clicking OK.

Navigate through the domain tree in the left pane to Forest (for your domain), Domains, then open your domain, then open Group Policy Objects. You should find at least two GPOs (Group Policy Objects) there, among them being Default Domain Controllers Policy and Default Domain Policy. Click on one of these policies to open it in the right pane. Select the Settings tab to display the rules that make up the policy. Click on show all in the upper right corner to expand the rule hierarchy. Look through these policies to see if you already have rules governing Automatic Updates. If so, you can modify them in place, but we will proceed assuming a clean slate.

Create GPOs

Right-click on Group Policy Objects in the left pane and select New. Assign a name like Automatic Updates-Desktops and click OK. Now right-click your new policy in the left pane and select Edit. This will start up the Group Policy Object Editor.

In the left pane, drill down to Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update. All Automatic Updates settings will appear in the right pane. As you click on each one, a description of the item will appear adjacent to the list. We won’t set every value, but we will set most of them. Open a setting by double-clicking its entry to open a configuration window. Each configuration window also has an Explain tab to help you understand the meaning of each aspect of the setting.

Let’s walk through the first one. Double click Configure Automatic Updates. Select the Enabled radio button. Set the first pull-down to 4 – Auto download and schedule the install. Set the install day to 0 – Every day. Set the scheduled install time to whatever you prefer. Finally, click OK to save the settings and close the box.

Here’s how I typically set it up:

• Configure Automatic Updates
  • Enabled
  • Configure automatic updating: 4 – Auto download and schedule the install
  • Scheduled install day: 0 – Every day
  • Scheduled install time: 11:00
• Specify intranet Microsoft update service location
  • Disabled
• Reschedule Automatic Updates scheduled installations
  • Enabled
  • Wait after system startup (minutes): 5
• No auto-restart with logged on users for scheduled automatic updates installations
  • Disabled
• Automatic Updates detection frequency
  • Enabled
  • Check for updates at the following interval (hours): 4
• Allow Automatic Updates immediate installation
  • Enabled
• Delay Restart for scheduled installations
  • Enabled
  • Wait the following period before proceeding with a scheduled restart (minutes): 5
• Re-prompt for restart with scheduled installations
  • Enabled
  • Wait the following period before prompting again with a scheduled restart (minutes): 480
• Allow non-administrators to receive update notifications
  • Enabled
• Enabling Windows Update Power Management to automatically wake up the system to install scheduled updates
  • Enabled

A few notes on the above values: You’ve got to let Automatic Updates reboot the computer; time and time again I’ve seen installations go literally months without applying patches because a user doesn’t want to be bothered with maintaining his machine. That’s OK; we’ll do it for him. Don’t check for updates more often than 3 or 4 hours; Microsoft says it can cause problems, and I, for one, don’t need any more problems with Windows than I already have. The 480 minute re-prompt number works out to 8 hours; I figure if someone actually doing their job sees a notice, they don’t need to be nagged again. Let it update once they’ve gone home. The power management setting is mostly wishful thinking on my part. Maybe someday I’ll go around and set up Wake-on-LAN in the BIOS on all those machines.

That was a lot of work, but there’s still plenty to do. Create a nearly identical GPO called Automatic Updates-Servers. The only change I make is to set the Configure Automatic Updates value to 3 – Auto download and notify for install. This prevents the possibility of a server rebooting while in use, disrupting work flow and generally wreaking havoc, but it also prevents the server from staying up to date unless you put forth an effort to keep it so. Hint: A particularly easy way to complete 90% of the work on your second GPO is to duplicate, then rename, the first one.

You can now close the Group Policy Object Editor.

Tie GPOs to Machines

So far, nothing we have done has affected any machine, but that’s about to change. What we’d like to see is for the server policy to apply to all of our servers and for the desktop policy to apply to everything else. The first step in making that happen is to define which machines are servers.

Open up Active Directory Users and Computers. If you can’t find it under Start -> Administrative Tools, then go to Start -> Run, enter dsa.msc and click OK. Navigate in the left pane down through your domain to the Computers folder. Right-click on the Computers folder and select New -> Group. Name the group Servers, leave the scope and type as a global security group, then click OK. It should show up in the list in the right pane.

Double-click your new group and select the Members tab. Add each server, one-by-one using the Add button and making sure the Select this object type field contains the word Computers. You can change it by clicking the Object Types button. Click OK when complete, then close the Active Directory Users and Computers window.

Next, we tie the Automatic Updates-Servers GPO to our new Servers security group. Back in GPMC, select the servers GPO and click on the Scope tab. In the bottom window, click the Add button and type Servers into the window, then click OK. Your security group should now be listed in the Security Filtering table. Highlight the other entry in the table (Authenticated Users) and click Remove, then OK. Now servers and only servers will be able to use the Automatic Updates-Servers GPO.

Last but certainly not least, link your new GPOs to the domain. In the left pane of GPMC, locate your domain name; it should be directly under the folder called Domains. Right-click your domain and choose Link an Existing GPO. Highlight both of your new GPOs with shift-click then click OK.

You are now in business. Your policies are complete and in place.

Check Your Work

If you log on to a domain member machine and look at the Automatic Updates page of the control panel, all the settings should be grayed out, but should match the values you set in your policies. If they’re not grayed out, you can wait, or you can give your policies a push.

Group policy flows gradually to domain member machines. They update at reboot time, but sometimes it takes more than one reboot for new policies to take effect. If you are impatient, or if a machine seems to get stuck, you can hurry along the process by running the command gpupdate /force from within a command window on the stuck machine. That, and maybe a reboot, usually get things moving along.

Another way to check is by examining the Windows Registry. Nearly all Group Policy operates by forcing certain registry settings on member computers, which then modify the computer’s behavior. Enter the following in a command window on any computer:

reg query hklm\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v AUOptions

and it should display the value 0×3 on servers and 0×4 on all other machines. You can run all your queries from one machine if you prepend each query target with its IP address or hostname, as follows:

reg query \\hostname\hklm\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v AUOptions

If the value is not found, try the gpupdate trick or a reboot. If it is found but does not match what you expected, make sure your Servers security group contains the right machine names; also make sure it is properly linked to the server GPO.

Maintaining Patched Systems

Your GPOs will do a reasonably thorough job of keeping your systems up to date, but you still have work to do. Put Patch Tuesday on your calendar—Microsoft publishes new security updates on the second Tuesday of every month. Your desktops should automatically update themselves within a day or two, but you’ll have to patch the servers yourself. On each one, either go to Start -> All programs -> Windows Update, or find the yellow shield in the systray (the row of tiny icons in the lower right corner of your screen) and apply the patches that should be downloaded and ready to install.

I also recommend checking the patch state of each machine with MBSA, the Microsoft Baseline Security Analyzer (of which the latest version, currently 2.1.1, is available here). MBSA can scan a single machine, all machines on your domain, or a LAN segment. It displays quite a bit of information, but the most critical is the list of missing patches. If a machine is chronically behind, it may be more than just group policy slowness. Many malware infections disable automatic updates, so a reformat and reinstall may be in order.

Congratulations!

Your machines are patched. You have taken a critical step that every security policy framework and every set of security regulations requires. And you have eliminated much of your vulnerability to the most popular current malware attacks. And you are no longer a Group Policy newbie!

AutoRun and the companion feature AutoPlay are components of the Microsoft Windows operating system that dictate what actions the system takes when a drive is mounted. The main purpose of AutoRun is to provide helpful actions and capabilities when removable media or network shares are mounted. When such a device is mounted, the autorun.inf file from the media is parsed. This file specifies which commands the system should run. Many companies use this functionality to automatically start up their installers when a CD-ROM is inserted, but attackers can also use it to run data extraction sessions or automatic installations of malware.

AutoRun and AutoPlay can be friendly features, but they are almost never necessary in an enterprise environment.  The security risk typically far outweighs any benefit.

All AutoRun/AutoPlay features are controlled by values stored in the Windows registry. There are a number of ways to set these values, including

• Group Policy
• Double-clicking a .REG file containing registry settings

Disabling AutoRun Using Group Policy

If you think that Windows Group Policy would be the most convenient and thorough way to distribute such a policy, you’d be partly right. The only gotcha is that a number of people report that it doesn’t always get every machine. I’d recommend both belt and suspenders—use a GPO to catch future machines, but set each existing machine by hand to make sure none fall through the cracks today.

Before configuring Group Policy, you must ensure that one of the following updates has been applied to each of the machines you intend to configure. Note that only one update applies to each machine.

• Update for Windows Server 2003 for Itanium-based Systems (KB967715)
• Update for Windows Server 2003 x64 Edition (KB967715)
• Update for Windows Server 2003 (KB967715)
• Update for Windows XP x64 Edition (KB967715)
• Update for Windows 2000 (KB967715)
• Windows Vista-based and Windows Server 2008-based systems must have update 950582 (Security bulletin MS08-038) installed to take advantage of the registry key settings that disable AutoRun.

This update will create a new registry entry, HonorAutorunSetting. Without the update, autorun.inf gets read even with AutoRun disabled, but simply does not execute any AutoPlay commands inside. This still allows attacks to be made using autorun.inf, and HonorAutorunSetting should be set to 1 to disable this. The default is 1 after the patch is applied.

To disable all AutoRun features in Windows Server 2003, Windows XP Professional and Windows 2000,

• Click Start, click Run, type gpmc.msc in the Open box, and then click OK. If you don’t yet have GPMC installed, do so first.
• Choose an appropriate Group Policy Object in the left pane (or create a new one and attach it in the appropriate place), right-click it, and select Edit.
• Under Computer Configuration, expand Administrative Templates, and then click System.
• In the Settings pane, right-click Turn off Autoplay, and then click Properties. Note: In Windows 2000, the policy setting is named Disable Autoplay.
• Click Enabled, and then select All drives in the Turn off Autoplay box to disable Autorun on all drives.
• Click OK to close the Turn off Autoplay Properties dialog box.

Windows will propagate the group policy settings to all machines controlled by the edited Group Policy Object. Once the settings have been applied to a computer, it must be rebooted before the changes take effect.

Disabling AutoRun Using a Registry File

Create a file called autorun.reg containing the following lines.  Some of the lines here are long; make sure you don’t break them in the middle somewhere when you cut and paste the text below.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"

[-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2]

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"HonorAutorunSetting"=dword:00000001
"NoDriveAutoRun"=dword:03ffffff
"NoDriveTypeAutoRun"=dword:000000ff

On each computer to be updated, browse to this file and double-click it. The computer must be rebooted for the changes to take effect.

• Making them hard to guess,
• Never writing them down,
• Limiting the scope of passwords, and
• Limiting the ability of an attacker to make repeated guesses.

Password Complexity

A recent study on password memorability and security uncovered two surprising results:

• The most important factor in the security of passwords is consistency—implementing technical controls to enforce password quality.
• So-called “passphrase” passwords are equal in quality to completely random passwords, yet are no more difficult to remember than any other user-chosen password.

Good passwords (those that are least vulnerable to password cracking attacks) utilize the full spectrum of allowable characters (Capital and lower case letters, numbers and symbols) and are long enough to force password crackers to use their slowest “brute force” technique.

Memorable Passwords

“Passphrase” passwords meet both of these requirements. To create one, just choose a memorable sentence and make it your password. Windows considers the space character to be a special character, so setting your password to “I love the Buckeyes!” meets the Windows password complexity requirement, gives you a password 20 characters long, and declares your allegiance just as well as “goBUCKS!” without falling to a password cracker in the first two seconds.

If your computer system limits you to relatively short passwords (say, 8 or 10 characters), or if you are a two-finger typist, take a simple sentence, assemble the first letters from each word in the sentence (as with an acronym), including appropriate capitalization and punctuation, then modify the new password slightly using numbers or special characters. For example, the phrase, “Obama declares nuclear war; details at 11” might be entered as “Odnw;d@11” which looks like a random password, yet is easy to remember. Similarly, the phrase, “It’s noon and I am hungry” could be typed in as “It’s12&Iah.” Unlike random passwords, passwords of this style are not any harder to memorize than shorter ones.

Length is Key

The power tools used by the bad guys can make quick work of password hash files these days, but choosing a password at least 15 or 16 characters long can move the advantage back to your side.

Rainbow tables can crack any password hash up to the length limit of the table in a very short time. Since these tables grow exponentially large with the password length, there are probably few or no existing rainbow tables (yet!) for passwords longer than 15 or 16 characters.

Additionally, traditional Windows password crackers such as John the Ripper typically only crack the LAN Manager hash, a relatively insecure password storage method that can only handle passwords 14 characters long or shorter. Choosing a 15-character password forces the hacker to resort to the more esoteric and less computationally efficient NTLM (MD4) password hash algorithm. Knowing this, you can make the bad guy’s job a whole lot harder by not storing the LAN manager hash of your password in the first place.

Password Scope and Availability

Even with an excellent password, however, an attacker can still break in if he has the opportunity (and patience) to make a hundred billion guesses at your password. It is also critically important to:

1. Limit the number of failed password attempts, or at least limit the rate, and
2. Log repeated failures so that action can be taken.

Similarly, choosing excellent passwords has little value if you use the same password for your business VPN and your Facebook or Amazon account. A hacker who manages to gain access to all of Amazon’s account holders is very quickly going to see if the user foxk@lithik.com with the password H@rd2gess has VPN access to lithik.com with username foxk and the same password. This type of attack is easily automated across thousands of stolen passwords.

Thin client sales pitches frequently include claims saying they can’t be hacked. They don’t have hard drives, so how could they? Besides, you can always push the reset button and—voilà—the software is booted from a clean copy, erasing any filth that may have found its way into memory.

Even so, I always recommend that our clients choose the version running Linux or some oddball embedded OS like VxWorks or QNX. I do this because although I frequently quote the famous security paradigm, “security by obscurity is no security at all,” I know that obscurity often does add to security—sometimes quite substantially.

Thin clients running Windows CE or Windows XP Embedded need to be updated every month, just like XP or your servers. Patch Tuesday applies both to the OS and to Internet Explorer, which is always the web browser in Windows-based thin clients. Go ahead and look in the manual for your thin client management software; network-wide updates are supported and recommended, but they usually leave out the dire threats and arm-waving you get when security folks talk about Windows patches. That’s too bad, because the same IE bug you just patched on all your XP machines is probably in all your CE and XPE thin clients, too. Thin clients may not have hard drives, but they do have memory-based filesystems that can store malware and run it, at least until you reboot. By then the damage may be done and the malware may have jumped to servers that do have hard drives.

But the fun doesn’t stop there! Show me a thin client browser and I’ll show you a device that runs JavaScript for sure, and probably Java and Adobe Flash as well, technologies that fall into a category known as mobile code. Claims that these environments are safe because they run in a protective “sandbox” are only partly true.  All software has bugs, even sandboxes.  A thorough security design requires measures that can protect against bugs that haven’t been found yet.  Thus the principle of defense in depth or security in layers is undoubtedly the most important threat mitigation tool in defending against the unknown.  Thin clients are great, but they’re only one layer.

So, what to do? There are some steps you can take. The following list is not exhaustive, because the author is not omniscient. But it’s a start.

• Choose Linux-based or RTOS-based thin clients over those running Windows CE or XP Embedded.
• Keep your thin clients up to date with the latest firmware available. If you do use Window-based devices, this means every month.
• Restrict the use of mobile code. If you need it for your business applications, configure the browser to only allow it from a select list of servers.
• If your thin client vendor hasn’t given you the ability to restrict mobile code, configure your firewall to do it instead.
• If your firewall won’t let you control mobile code, configure it to restrict all web browsing to a list of approved sites. This is called a white list.

Applying these methods to a thin client environment will certainly decrease the risk of infection.  But it must be said that there is really no guaranteed safe way to give your staff unlimited freedom to browse the Internet with all the bells and whistles enabled.  Well, at least not unless you figure out a way to move them outside your firewall while they do it. If you think of your business environment as a surgery room in which every item introduced from the outside represents a potential threat, you will understand the importance of continued vigilance to avoid contamination. Thin clients are indeed way more secure than desktops. It’s just that the Internet is anything but sanitary and nothing is perfectly safe.