Determining which vulnerabilities to address first
Patching your systems
Looking at security in a new light
After you complete your tests, you want to head down the road to greater security. However, you found some security vulnerabilities. (Hopefully not too many serious ones, though!) Plugging these security holes before a hacker exploits them is going to require a little elbow grease. You need to come up with your game plan and decide which security vulnerabilities to address first. A few patches might be in order, and possibly even some system hardening. You might want to reevaluate your network design and security infrastructure as well. I touch on some of the critical areas in this chapter. You might also want to refer to the fine book Network Security For Dummies by Chey Cobb. Chey does a great job of covering each of these topics in depth.
It might seem that the security vulnerability to address first would be obvious, but it's often not black and white. When reviewing the vulnerabilities that you find, consider the following variables:
Whether the vulnerability can be fixed
How easy the vulnerability is to fix
How critical the vulnerable system is
Whether you can take the system offline to fix the problem
Time, money, and effort involved in purchasing new hardware or software or retooling business processes to plug the holes
In Chapter 16, I cover the basic issues of determining how important and how urgent the security problem is. In fact, I provide real-world examples in Table 16-1. You should also look at security from a time-management perspective and address the issues that are both important (high impact) and urgent (high likelihood). You don't want to try to fix the vulnerabilities that are just high impact or just high likelihood. You might have some high-impact vulnerabilities that, likely, are never exploited. Likewise, you probably have some vulnerabilities with a high likelihood of being exploited that, if they are exploited, won't really make a big difference in your business or your job. This type of human analysis and perspective will keep security professionals employed for some time to come!
Focus on tasks with the highest payoff first — those that are both high impact and high likelihood. Ideally, this will be the minority of your vulnerabilities. After you plug the most critical security holes, you can go after the less important and less urgent tasks when time and money permit. For example, after you plug such critical holes as SQL injection in Web applications and missing patches on important servers, you might want to reconfigure your tape backups with passwords, if not strong encryption, to keep prying eyes away in case your backups fall into the wrong hands.
Do you ever feel like all you do is patch your systems to fix security vulnerabilities? If you answer yes to this question, good for you — at least you're doing it! If you constantly feel pressure to patch your systems the right way but can't seem to find time — at least it's on your radar. Many IT professionals and their managers don't even think about proactively patching their systems until after a breach occurs. If you're reading this book, you're obviously concerned about security and are hopefully way past that.
Note
Whatever you do, whatever tool you choose, and whatever procedures work best in your environment — keep your systems patched! This goes for servers and workstations as well as operating systems and databases.
Patching is unavoidable. The only real solution to eliminating the need for patches is developing secure software in the first place, but that's not going to happen any time soon. A large portion of security incidents can be prevented with some good patching practices, so there's simply no reason not to have a solid patch management process in place.
If you can't keep up with the deluge of security patches for all your systems, don't despair; you can still get a handle on the problem. Here are my basic tenets of applying patches to keep your systems secure:
Make sure all the people and departments that are involved in applying patches on your organization's systems are on the same page and follow the same procedures.
Have formal and documented procedures in place for these critical processes:
Obtaining patch alerts from your vendors
Assessing which patches affect your systems
Determining when to apply patches
Make it policy and have a procedure in place for testing patches before you apply them to your production servers, if that's possible. Testing patches after you apply them isn't a big deal on workstations but servers are a different story. Many patches have "undocumented features" and subsequent unintended side effects — believe me, I've experienced this before. An untested patch is an invitation for system (and job) termination!
The following sections describe the various patch deployment tools you can use to lower the burden of constantly having to keep up with patches.
I recommend a robust patch automation application — especially if you have
A large network
A network with several different operating systems (Windows, Linux, NetWare, and so on)
More than a dozen computers
Be sure to check out these patch-automation solutions:
BigFix (
www.bigfix.com)Shavlik Technologies NetChk (
www.shavlik.com)Ecora Patch Manager (
www.ecora.com/ecora/products/patchmanager.asp)ScriptLogic Patch Authority Ultimate (
www.scriptlogic.com/products/patchauthorityultimate)Windows Server Update Services from Microsoft (
www.microsoft.com/windowsserversystem/updateservices/default.mspx)
The GFI LANguard (www.gfi.com/lannetscan) product that I use in this book can check for patches to apply and deploy.
Tip
Watch the other major vulnerability assessment tool vendors, such as Qualys. They are starting to integrate logic in their programs to deploy patches that address the vulnerabilities their products find — a process called vulnerability management.
After you patch your systems, you have to make sure your systems are hardened from the other security vulnerabilities that patches can't fix. I've found that many people stop with patching, thinking their systems are secure, but that's just not possible. Throughout the years, I've seen network administrators ignore recommended hardening practices from such organizations as the National Institute of Standards and Technology (NIST) (http://csrc.nist.gov/publications/nistpubs/index.html) and the Center for Internet Security (www.cisecurity.org), leaving many security holes wide open. However, I'm a true believer that hardening systems from malicious attack is not foolproof, either. Because every system and every organization's needs are different, there is no one-size-fits-all solution, so you have to strike a balance and not rely on any single option too much.
Tip
Chey Cobb's Network Security For Dummies contains many great resources for hardening various systems on your network.
This book presents hardening countermeasures that you can implement for your network, computers, and even physical systems and people. I find these countermeasures work the best for the respective systems.
Implementing at least the basic security practices is critical. Whether installing a firewall on the network or requiring users to have strong passwords — you must do the basics if you want any modicum of security. Beyond patching, if you follow the countermeasures I document, add the other well-known security practices for network systems (routers, servers, workstations, and so on) that are freely available on the Internet, and perform ongoing ethical hacking tests, you can rest assured that you're doing your best to keep your organization's information secure.
A review of your overall security infrastructure can add oomph to your systems:
Look at how your network and building are designed. Consider organizational issues, such as whether policies are in place, maintained, or even taken seriously. Does management have buy-in on information security and compliance, or do they simply shrug the measure off as an unnecessary expense or barrier to conducting business?
Map your network by using the information you gather from the ethical hacking tests in this book. Updating existing documentation is a major necessity. Outline IP addresses, running services, and whatever else you discover. Draw your network diagram — network design and overall security issues are a whole lot easier to assess when you can work with them visually. Although I prefer to use a technical drawing program, such as Visio, to create network diagrams, such a tool isn't necessary — you can sketch your map on a napkin!
Note
Be sure to update your diagrams when your network changes.
Think about your approach to correcting vulnerabilities and increasing your organization's overall security. Are you focusing all your efforts on the perimeter and not on a layered security approach? Think about how most convenience stores and banks are protected. Security cameras focus on the cash registers, teller computers, and surrounding areas — not just on the parking lot or entrances. Look at security from a defense in-depth perspective. Make sure that several layers of security are in place in case one measure fails, so the malicious attacker must go through other barriers to carry out a successful hack attack.
Think about security policies and procedures at an organizational level. Document what security policies and procedures are in place and whether they're effective. Look at the overall security culture within your organization and see what it looks like from an outsider's perspective. What would customers or business partners think about how your organization treats their sensitive information?
Looking at your security from a high-level and nontechnical perspective gives you a new outlook on security holes. It takes some time and effort at first, but after you establish a baseline of security, it's much easier to manage new threats and vulnerabilities.