Tag Archives: Jonathan Hassell

Patch Magic: When to Download a Security Fix

our beautiful site

Security isn’t exactly the most glamorous job in IT, but someone has to do it. After all, servers constantly face an onslaught of hazards, from viruses to worms to denial-of-service attacks, which can bring them — and your business — down in a flash. Software manufacturers, especially Microsoft, aren’t helping, finding vulnerabilities and sending out critical patches faster than security managers can deploy them. Which leaves IT departments in a quandary: update servers as soon as a critical patch comes out or wait until the patch is thoroughly tested? Choosing the former can cause applications critical to your business to stop running, but doing the latter, especially if you start falling behind, will leave your servers and network vulnerable to attack. Whether an IT shop deploys its patches manually or via an automated patch management system, the key to not be buried under a virtual mountain of updates is to have a consistent and well-documented update process. In addition, standardized and hardened server configurations have help security managers keep up. The onslaught of patches In 2007, Jennifer Albornoz Mulligan , an analyst with Cambridge, Mass.-based Forrester Research, took a survey of IT security decision makers about how they deal with their patch management issues. She estimated that Microsoft released 49 critical patches for Windows servers in 2006. That was up from about 30 in 2005 and about 20 in 2004. That translates to about one critical patch per week, all of which needed to be evaluated, tested, and distributed by IT security managers and administrators. Many respondents complained that they were falling too far behind. “Some were very frustrated because they hadn’t finished the previous month’s patching by the times the new ones came out,” she says. “Many are just on a treadmill that won’t stop, because they’re just constantly behind and can’t catch up.” Mulligan found that, on average, her respondents patched servers eight days after their companies’ self-imposed patching deadline passed. One of the reasons why these companies fell behind was that 77 percent of the respondents either didn’t have a testing environment or had one that only partially replicated their company’s production environment. Standardization helps What surprised Mulligan the most was that those businesses who had servers that were built to standardized specs, including hardening steps like shutting down services, deleting unnecessary IDs, and turning off unused ports, installed patches much faster than respondents that didn’t have that degree of control. “One of the companies I talked to had a 48-hour patch deadline,” she says. “They made it because they had very strict hardening and server configuration requirements.” Jonathan Hassell, president of the Scribner Technology Media Corporation and the author of a number of books on Windows, including the book Hardening Windows (Apress, 2005), thinks a company’s patching policies and procedures really come down to priorities. “Something to remember: security is a goal.  It’s not a state,” he says. “There is no panacea. It’s a process, with a lot of moving parts, dependencies, and cost.” Making the mountain into a molehill So how do you dig yourself out from the pile of patches? Here are some suggestions: Virtualization.  Because money is not always available to replicate the development environment, software like VMWare can help an administrator re-create a particular production environment on demand in order to test a patch. “Some of the most advanced clients I spoke with found it most helpful because it was cost-effective,” says Mulligan. Create and follow a documented security policy.  This doesn’t just pertain to a regular patching schedule and testing procedure. Hardening servers either manually or via standardized configurations are also a plus. “If you do a good job hardening your systems, you’ve turned off the services you don’t need,” says Mulligan. “So if there’s a patch for that service, it doesn’t matter, since the service is turned off.” Use automated patching systems.  Some particularly hands-on IT managers will insist on patching servers by hand. Hassell feels that’s a valid method, though he prefers automated tools. “It’s not necessary to hand patch them if you spend the time to craft a quality updating policy in whatever software you’re using.” Prioritize. Which applications are most critical to your business? Those may be the ones where you will want to do the most extensive patch testing. Internet-facing servers, for instance, may need to be patched first because they’re the most vulnerable to attack.

Patch Magic: When to Download a Security Fix

our beautiful site

Security isn’t exactly the most glamorous job in IT, but someone has to do it. After all, servers constantly face an onslaught of hazards, from viruses to worms to denial-of-service attacks, which can bring them — and your business — down in a flash. Software manufacturers, especially Microsoft, aren’t helping, finding vulnerabilities and sending out critical patches faster than security managers can deploy them. Which leaves IT departments in a quandary: update servers as soon as a critical patch comes out or wait until the patch is thoroughly tested? Choosing the former can cause applications critical to your business to stop running, but doing the latter, especially if you start falling behind, will leave your servers and network vulnerable to attack. Whether an IT shop deploys its patches manually or via an automated patch management system, the key to not be buried under a virtual mountain of updates is to have a consistent and well-documented update process. In addition, standardized and hardened server configurations have help security managers keep up. The onslaught of patches In 2007, Jennifer Albornoz Mulligan , an analyst with Cambridge, Mass.-based Forrester Research, took a survey of IT security decision makers about how they deal with their patch management issues. She estimated that Microsoft released 49 critical patches for Windows servers in 2006. That was up from about 30 in 2005 and about 20 in 2004. That translates to about one critical patch per week, all of which needed to be evaluated, tested, and distributed by IT security managers and administrators. Many respondents complained that they were falling too far behind. “Some were very frustrated because they hadn’t finished the previous month’s patching by the times the new ones came out,” she says. “Many are just on a treadmill that won’t stop, because they’re just constantly behind and can’t catch up.” Mulligan found that, on average, her respondents patched servers eight days after their companies’ self-imposed patching deadline passed. One of the reasons why these companies fell behind was that 77 percent of the respondents either didn’t have a testing environment or had one that only partially replicated their company’s production environment. Standardization helps What surprised Mulligan the most was that those businesses who had servers that were built to standardized specs, including hardening steps like shutting down services, deleting unnecessary IDs, and turning off unused ports, installed patches much faster than respondents that didn’t have that degree of control. “One of the companies I talked to had a 48-hour patch deadline,” she says. “They made it because they had very strict hardening and server configuration requirements.” Jonathan Hassell, president of the Scribner Technology Media Corporation and the author of a number of books on Windows, including the book Hardening Windows (Apress, 2005), thinks a company’s patching policies and procedures really come down to priorities. “Something to remember: security is a goal.  It’s not a state,” he says. “There is no panacea. It’s a process, with a lot of moving parts, dependencies, and cost.” Making the mountain into a molehill So how do you dig yourself out from the pile of patches? Here are some suggestions: Virtualization.  Because money is not always available to replicate the development environment, software like VMWare can help an administrator re-create a particular production environment on demand in order to test a patch. “Some of the most advanced clients I spoke with found it most helpful because it was cost-effective,” says Mulligan. Create and follow a documented security policy.  This doesn’t just pertain to a regular patching schedule and testing procedure. Hardening servers either manually or via standardized configurations are also a plus. “If you do a good job hardening your systems, you’ve turned off the services you don’t need,” says Mulligan. “So if there’s a patch for that service, it doesn’t matter, since the service is turned off.” Use automated patching systems.  Some particularly hands-on IT managers will insist on patching servers by hand. Hassell feels that’s a valid method, though he prefers automated tools. “It’s not necessary to hand patch them if you spend the time to craft a quality updating policy in whatever software you’re using.” Prioritize. Which applications are most critical to your business? Those may be the ones where you will want to do the most extensive patch testing. Internet-facing servers, for instance, may need to be patched first because they’re the most vulnerable to attack.

Wireless Networking Hazards to Avoid

our beautiful site

Who doesn’t love the convenience of an in-house wireless network? You can tote your laptop to a colleague’s office, a conference room, even to the cafeteria — as long as those places are within range of your system’s signal — and still get your email, retrieve documents on company servers and even access the Internet. And who hasn’t heard about the headaches inherent with all that openness? A few complaints involve performance: For instance, most networks have some “cold spots” where the wireless signal is weak or non-existent. But for most businesses, the biggest concern is security. Or, more precisely, the lack of it. Like cell phones, wireless networks rely on radio waves; like cell phones, they’re simply more vulnerable to certain security problems than their wired counterparts are. While security standards have grown increasingly more stringent in recent years, corporate wireless networks remain vulnerable to a variety of threats. Among them: Computer viruses and worms. Hacker intrusions. Nearby outsiders who hop, uninvited, onto your network, using your signal to access the Internet for free. (A few years ago, I had a contract job at a struggling company that didn’t have its own wireless set-up, but its employees could easily piggyback onto a neighboring business’s unsecured wireless network. Nobody was interested in their host company’s data; they just wanted to surf the Web for free. And they did. Regularly.) Protecting your wireless network starts with an obvious step: Invest in a firewall, a virus-scanning program, and intrusion-detection software. Use them at their highest-security settings. Update them regularly — automatically, if possible. And make sure your IT team is using the most recent security protocols (usually expressed as some combination of the number 802.11, followed by a letter), which are more secure than earlier iterations. Beyond that, avoiding these common mistakes can help strengthen your network’s security, keeping your information safe and your employees productive: Using easily cracked passwords. Too many organizations use group passwords that a fifth-grader could figure out. Common ones include: The company name or a slight variation, (such as “WidgetCorp”), a logical sequence of letters and numbers (such as “abcde12345”), one number repeated multiple times (such as “777777777”) or the company’s main switchboard number or mailing address. Experts say some businesses never even bother to change the wireless network manufacturer’s default password — which a savvy crook can find almost as easily as that street address or phone number. You’ve heard it before, but it bears repeating:  Opt for less-obvious passwords, both individually and as an organization. Don’t use names. Don’t use recognizable words — hackers typically have software programs that cycle through electronic dictionaries trying one possibility after another until they hit the right one. Use a seemingly random group of letters and numbers, but watch the length. If it’s more than about 10 characters, some people will write it down to remember it, possibly even posting it on or near their computers. That’s like putting a key to your house in an envelope marked “Key to the House” and leaving it right outside the front door. Leaving entry points vulnerable. Jonathan Hassell, an IT systems consultant based in Raleigh, N.C., says a wireless network’s weakest spots are the places where legitimate outside users can get into your systems. Those points — such as virtual private network (VPN) connections and remote-access servers — are also the places most likely to attract unwelcome visitors. Hassell, author of Hardening Windows (Apress, 2005) recommends having your IT team or a security specialist “harden” those points — that is, provide them with state-of-the-art protection against hackers, viruses and other external threats. And don’t forget that every computer on a network also serves as an access point. Encourage employees to turn off their machines whenever they’re not in use. Failing to set policies. The world’s best security measures won’t work if employees don’t cooperate. For instance: Wireless networks are so inexpensive and easy to use these days that in some growing companies, forward-thinking employees simply set up their own little networks for small-group collaboration. You need to consider whether such “private” networks are acceptable and, if so, determine whether they’re properly secured. It’s also important to establish rules about who can use your company’s main wireless network. For instance, do you want to provide visiting consultants and contractors with access? Finally, when you travel, pack the same precautions. Be especially careful about transmitting confidential information over a wireless network in a public place. Travel writer Christopher Elliott relates that while he was using a hotel’s wireless network, someone snagged his email account password and nearly succeeded in sending an obscene message to the 21,000 subscribers of his email newsletter. “It’s the last time I’ll send any sensitive data” wirelessly, Elliott wrote in describing the experience on a Microsoft-sponsored site for small businesses. Just as with cell phones, when you’re on a wireless connection in a public place, your best bet is to assume that somebody might be eavesdropping.