Hardening Network Infrastructure. Bulletproof Your Systems Before You Are Hacked.

It cannot be stated enough that security is a process, not a goal. There is no endgame in hardening your environment; rather, you will be constantly updating and changing your security policies to address new threats that exist against your network infrastructure and new technologies that expand and change your network infrastructure.

Your security policy is a living document and, as such, should adapt to the changing needs of your organization. As best practices change, your policy needs to be checked against the best practices to make sure it is up to date. You should review your policy against each vendor s recommendations as well as check the SANS (www.sans.org) and CERT (www.cert.org) resources for tips, practices, and security updates and alerts that you can incorporate into your policy.

When you review your security policy, you want to focus on the following objectives:

• Is your security policy being adhered to?

• Does your security policy address all known threats to your environment?

• Do you have adequate prevention and enforcement of your security policy?

Is Your Security Policy Being Adhered To?

On the surface, this task may seem pretty simple to address: if your security policy isn t being adhered to, it may be time for some serious enforcement, such as employment termination. However, the situation probably requires a more detailed examination to determine why the security policy isn t being adhered to instead of just a knee-jerk reaction of This is what we said to do, now do it. There are a number of reasons why your security policy might not be adhered to:

• Lack of knowledge This is the old I didn t know situation. People may not know that a policy is in place that they need to adhere to. You can address this through education and training. Although classes are certainly an effective method of informing your users, you can employ additional training methods to further cement the users understanding of what the security policy is. When you have a new employee, you should make sure that part of their employment indoctrination covers the aspects of your security policy that apply to them. In addition, you should ensure that an explanation of the security policy is a component of their annual review to reinforce their knowledge of old policies and introduce them to any new or changed policies. Another very effective form of education (at least from a legal standpoint) is the use of banners. For example, you can have a banner that pops up when a user logs on or accesses the Internet explaining the acceptable-use policy, including a link to the actual full-text policy on your intranet. You could also have a banner that pops up when a user accesses their e-mail detailing the acceptable-use policy for e-mail, including a link to the actual full-text policy on your intranet. Banners and messages of the day (MOTD) make it very difficult for someone to claim they didn t know about a certain policy, especially if they had to click to get past that information. Finally, make sure you use e-mail and intranet websites to inform your users of the security policies they need to be aware of. Ignorance can only be an excuse if you give your users the opportunity to be ignorant about the subject.

• Policy interferes with business processes This is the most difficult situation to address because it generally becomes a very politically charged issue. Because your security policy is often at odds with the easiest way to do something, people may decide to simply not follow the policy. In some cases, this is going to require upper management support and strict enforcement of the policy to effectively force the users to adhere to the policy. In other cases, the policy will have to be changed, sometimes providing weaker security in the process, so that the policy truly matches the work environment and what is being done there. For example, you might really want to use only 3DES encryption for increased security, but due to export regulations, you may have to run DES encryption at some locations. Pick your battles and be willing to compromise on issues that require it.

• Policy is ineffective This is a case of a policy sounding really good on paper, but in practice it falls short of the expectations. Consequently, your security policy will need to be reevaluated to ensure it meets the expectations set forth in the design phase. An example of this might be a security policy that requires a certain type of VPN software to be used, even though not all operating systems in use support that type of VPN software. This problem commonly occurs when policies are tested by administrators using administrator-level accounts. Make sure your policies are always tested by all the types of users the policies are supposed to apply to.

A policy that isn t being adhered to is simply a waste of time and resources because it merely provides a feel-good measure with no tangible benefit. However, this does not mean you should simply change or remove any policies that aren t being adhered to. Review the reasons why the policy isn t being adhered to and make the appropriate adjustment. Sometimes this will simply involve educating your users. Other times it may require you to implement some kind of control that enforces the policy. In other cases, you may have to change the policy to better fit the business process, or you might need to change the policy because, in practice, it fell short of expectations. For example, if you have a password policy that requires a minimum of eight characters using uppercase letters, lowercase letters , and numbers , and you find that your users aren t adhering to the policy, don t just remove the password policy completely. Take a look at whether you simply need to educate your users. If so, take care of that so your users start doing what is expected of them. This might even require you implementing software that enforces the policy and requires your users to select an appropriate password.

Does Your Security Policy Address All  Known  Threats  to  Your Environment?

It sometimes seems that certain vendors have new security bulletins on a daily basis, even though this is not the case. Although it is common to point to Microsoft as the biggest culprit here, the truth of the matter is that every single vendor has security bulletins that they release, and you only need to watch the SecurityFocus BugTraq mailing list (http://www.securityfocus.com/archive/1) to realize this. The most difficult part of writing an effective security policy isn t defending against the threats you know about but rather trying to defend against the threats you do not yet know exist. For example, you cannot possibly know what vulnerabilities might be discovered for the various services and applications your network infrastructure equipment runs; however, if your security policy requires that all unnecessary services be disabled, you can effectively protect yourself from exploits directed at those services.

In July of 2003, Cisco announced a security vulnerability (Cisco IOS Interface Blocked by IPv4 Packets) that affected virtually every version of IOS prior to 12.3. This security vulnerability would block an interface, preventing it from sending and receiving any data. The vulnerability was based on the interface receiving traffic with protocol types of 53 (SWIPE), 55 (IP Mobility), 77 (SunND), and 103 (Protocol Independent Multicast “ PIM). Keep in mind that these are not port numbers, but protocol numbers. Although I had heard of some of these protocols, I had never actually seen them in use anywhere I had worked. Ever. In fact, after reading the RFCs and related documentation about these various protocols, I can think of very, very few environments where they would likely be needed. And yet I had never thought to disable those protocols at my border routers for sure, and my interior routers in most cases ”and, frankly, apparently most everyone else had never thought of this either. Consequently, many tens of thousands of systems were vulnerable to an exploit for protocols that in 99.999 percent of the cases no one actually used. The lesson to be learned here is simple: If you don't need something, turn it off. This is the most effective method of protecting yourself from future exploits.

Although protecting from unknown future exploits by disabling unnecessary services is key to ensuring that all known threats are addressed by your security policy, you also have to protect against those new threats that come out for the services you do require. In an almost-perfect world, the only vulnerabilities would be against services that we do not use or do not need. Unfortunately, security threats exist against protocols such as SSH (which you should require in your environment) that force us to address them to ensure that our systems are not left vulnerable.

As we have discussed, SSH provides encryption of data, which makes it an excellent candidate for providing remote management capabilities for your devices. This doesn't mean that SSH is not vulnerable to being exploited, however. For example, in September of 2003, Cisco released a security bulletin detailing vulnerabilities in the SSH server software of a number of network devices. Even so, given that SSH is more secure than Telnet will ever be, it doesn't make sense to disable SSH in your environment because the net effect would be to weaken your overall security posture ”even more than the vulnerability does. As of November, all affected systems had a corresponding fix or workaround that should have been applied. See Cisco Document ID 45322 for further information regarding the status of this issue.

The most effective method to recognizing and addressing new threats is to keep your pulse on the industry and be aware of what is happening. By that I mean you have to make every effort to be as personally informed about the discovery of new threats, patches, and upgrades as you possibly can. A number of resources are available to assist you in this endeavor:

• BugTraq BugTraq is a mailing list maintained by SecurityFocus (http://www.securityfocus.com/archive/1) that tracks bugs and vulnerabilities for virtually every product and vendor on the planet. Subscribe to this mailing list.

• NTBugTraq Modeled after BugTraq, NTBugTraq according to its website (http://www.ntbugtraq.com/) is a mailing list for the discussion of security exploits and security bugs in Windows NT, Windows 2000, and Windows XP plus related applications. Subscribe to this mailing list.

• Full Disclosure Run by Netsys, Full Disclosure is a mailing list that grew because of the perception that other mailing lists delay information until the vendors have had a chance to build a response, thus delaying the ability for you and me to know about potential threats. Although there is much bluster and hot air behind this, there is a grain of truth to it. Also, be aware that unlike the other mailing lists I have mentioned, this one is not moderated . On the surface that may sound like a good thing ” open access to information without any interference ”but in practice it sometimes means that you don t always get accurate information, and you might even find yourself receiving attachments or links to harmful data in addition to witnessing a significant amount of flame wars between Linux and Microsoft purists . Use caution if you decide to subscribe to Full Disclosure. You can subscribe to this mailing list at http://lists.netsys.com/mailman/listinfo/full-disclosure.

• Vendor mailing lists Many of your vendors have mailing lists or notification processes to inform their customers of new security-related issues.

• The CERT Coordination Center Located at http://www.cert.org, the CERT /CC serves as a central information-reporting center and clearinghouse of security-related information (see Figure 13-1). You should make it a habit to check this website regularly. Personally, I check it a couple of times a day for new events and information.

  Figure 13-1: The CERT website s main page

• Virus software vendor websites Many virus-scan vendors maintain websites with up-to-date information regarding new viruses and worms. Because so many of these programs can affect your network infrastructure, you should make it a point to check your favorite virus software vendor s website a few times a day. Personally, I check with Symantec at http://www.sarc.com/ (shown in Figure 13-2) and Network Associates at http://www.nai.com/us/security/vil.htm.

  Figure 13-2: Symantec main page

Here s a daily checklist of information sources:

1. Monitor BugTraq and NTBugTraq mailing lists.

2. Monitor vendor mailing lists.

3. Check www.cert.org for any new advisories.

Do You Have Adequate Prevention Mechanisms and Enforcement of Your Security Policy?

We all know the adage that an ounce of prevention is worth a pound of cure. Your security policy is no different. You have two angles from which to approach prevention ” preventing threats and preventing noncompliance with your security policy.

The best security policy is one that focuses on preventing exploits from occurring, not simply defining what the threats are or what to do once an exploit has occurred. You can ensure your security policy focuses on preventing threats by ensuring that when you identify a threat, you also identify how to protect against that threat.

You will also want to prevent your security policy from not being adhered to. In many cases, you can prevent noncompliance by implementing the appropriate hardware and software. For example, if you have a password security policy that requires certain password characteristics, you can implement software that ensures that all user passwords adhere to the policy you ve defined.

Like prevention, there are two angles to enforcement. The first is to ensure that your security policy enforces the recommendations it makes. You can do this by adopting procedures, software, and hardware that force whatever your recommendation is to occur. For example, if you require that only IPsec VPNs can be established, you can enforce this by ensuring that all your VPN concentrators only support IPsec VPN connections. This, in turn, forces the users to adhere to the policy, whether they want to or not.

The second aspect of enforcement is a much more political situation in that it defines what the response will be for violations to the security policy. You absolutely must involve your human resources and legal departments in these discussions because, in almost all cases, you will be dealing with personnel issues. You must ensure your users sign the security policy at employment and review time to verify that the users understand what is expected from them and what acceptable use is as defined by the policy. This is where your legal department plays a major role in ensuring that the policies are legally enforceable and do not expose your company to litigation. Once the users understand the security policies and expectations, you need to have a method of addressing security policy violations with some kind of punitive enforcement. Common methods of enforcement include verbal or written warnings, incident records attached to employee personnel files, wage garnishment, suspension, and even employment termination in the most egregious of offenses . For example, attempting to run a port scan on your network may justify a simple warning in either verbal or written form, whereas surfing porn sites should be grounds for immediate employment termination.

I worked for an employer who had an employee who liked to surf porn. This individual worked the night shift and also had a habit of showing the porn to other members of the staff. This was, obviously, a bad thing. Once this was discovered, we recommended that the individual be immediately terminated from employment. For reasons that to this day I still don't understand, the employer chose not to do this. Because of the legal liabilities related to a sexual harassment lawsuit, the IT department consequently drafted a document that stated that the company did not adhere to the IT recommendation and therefore IT was not liable for any future liabilities that might result from this individual's action. Although this might seem like overkill, we thought that in light of the severity of the policy violation, it was necessary.