15.2 Understanding Network Security Risks | The Practice of Network Security: Deployment Strategies for Production Environments

If a new security policy is being enabled within an organization, it is not only the end users who will need to be trained; network and system administrators will have to be trained as well. Because administrators are a vital component of strong network security, they should be trained to incorporate security as part of their daily routine.

NOTE

End users can be forgiven for ignorance about matters of security, but administrators cannot. To that end, it is important that all systems administrators understand the philosophy behind the company security policy, and what constitutes good security practices.

Security should be a basic tenet of every equipment or software evaluation that is performed. Software upgrades should be subjected to security testing, in addition to the regular testing, and the security impact of network changes should be evaluated alongside performance and redundancy considerations.

Some basic considerations that should be part of an evaluation of any device being added to an enterprise network include:

Methods of access and administration : Is there a secure way to connect to the device for administrative purposes? If there are multiple ways, can insecure methods be disabled?
Default accounts : What default accounts are on the device? Those should be recorded and changed, or deleted.
System monitoring : What methods are available to monitor the health of the device, and any anomalous behavior? Are those methods secure?
Logging : What logging facilities are in place? Will they work with the existing monitoring system?
Redundancy : What type of redundancy is available for this device and is redundancy important for this device?
Vendor reputation : What reputation does the vendor have for security and responding to security incidents? Security incidents are a fact of life for all vendors ; how they react is important.
Device security history : Look through online security databases. What types of security incidents have been reported for this device? Have there been multiple security holes?

There are undoubtedly other security needs that are organization specific, and this list is not intended to be comprehensive. Instead it is a starting point to help each organization build a list that meets its needs.

Just answering these questions is not enough. A thorough, methodical security evaluation should be performed on all new equipment being considered for deployment on the network. In other words, try to hack the box.

In a lab environment that mimics the corporate network, try to use the same tools an attacker would to break into the device. Ideally, the device being tested should be submitted to a security evaluation for a week. That should give administrators plenty of time to launch password attacks and DoS attacks, sniff traffic, and try the other attacks covered in Chapter 3.

It is important that the tests be methodical. Again, this is a lab environment and should be treated as such. A standard security test plan should be in place. The security test plan should describe how the attacks work, what the purpose of each attack is, and what information can be gained from a successful attack. Not all attacks will be appropriate for all devices, so several security test plans should be in place for each type of network device that will be tested.

The results of each attack should also be recorded. If a password-cracking attempt is successful after three days of trying, that should be noted. Bear in mind, if an attack is successful, that does not mean that the device should be removed from consideration for network deployment ”it is simply a data point.

After the security audit has been completed for a network device, there are several options. If this is an evaluation of multiple products, the results should be shown to the individual vendors. The vendors will undoubtedly have best-practice configurations that are recommended for security; if these were not followed for the first test, a second test should be performed using them. ^[1]

^[1] Of course, asking for this information up front can save a lot of time.

If the second test, using the vendor's recommended best practices for security, has similar results or results that are only marginally better, the device should be removed from consideration for deployment. Oftentimes, a test like this may uncover security holes of which the vendor was not aware. If that is the case, the security audit will help the vendor fix bugs in the code, making an overall better product.

This type of security should be applied not just to network devices and software, but network protocols as well. An organization considering deploying routing protocols such as Intelligent Scheduling and Information System (ISIS) or Multiprotocol Label Switching (MPLS) will want to perform similar security audits on these protocols to determine what the security weaknesses are.

The difference is that when a new protocol is being deployed it is generally done on existing equipment, rather than on new equipment. For that reason it is even more important that an organization be willing to work with vendors to patch any security holes that are found.

Protocol security evaluation is often a confusing topic. How does an administrator determine if there are security holes in a specific protocol, rather than in a network device, or software? The answer remains mostly the same. Many of the same guidelines can easily be applied to a protocol. When it comes time to perform a security audit on the protocol, the tests should be based on known security holes in similar protocols. If an organization is auditing a new routing protocol, then tests used to evaluate a BGP or OSPF implementation can often be used.

What is important is an understanding of the protocol, and what it is trying to accomplish. If a protocol is supposed to be designed to allow a user to securely connect to a server, an evaluation should be designed to test whether or not a username and password can be sniffed or decrypted. In short, administrators have to think like an attacker would. If someone were attempting to find out information about the network, how would that person attempt to exploit the protocol?

15.2.1 Ongoing Security Evaluations

Evaluations, whether of hardware, software, or protocols, should not just be conducted prior to deployment. A routine should be established to conduct security evaluations of existing network infrastructure on a regular basis.

A security evaluation is separate from the network monitoring that happens on a daily basis. Security evaluations generally occur in two forms:

Simulating a real attack
Testing equipment in the lab

The first test should be an assault on the network in a manner that simulates a real attack. Attempt to access servers, shutdown routers, or gain access with an unauthorized machine.

Simulated attacks should be conducted with no warning, giving the administrative or security staff a chance to respond in their usual manner. If the simulated attack is successful, it should be quickly noticed and dealt with.

If the attack were successful, the compromised device should be re-evaluated to determine its weaknesses and how best to correct them. The same type of evaluation should be applied to security staff if they fail to notice the attack.

Failure on the part of the security staff to stop an attack in progress should be taken very seriously. Determine why the attack was not noticed, and what steps can be taken to make sure the problem does not recur. These steps may involve additional training or improved monitoring processes. If repeated simulated attacks go unnoticed, steps also may involve the termination of employees who fail to notice the attacks.

The second type of ongoing security evaluation goes on in the lab. Network devices should be re-evaluated on a regular basis to determine if there are new security holes that can be exploited. This type of evaluation is more than checking security databases, which should also be done on a regular basis. Instead, the goal of this evaluation is to test the equipment in the lab, using the latest security tools available. New tools for testing network security, or to exploit weaknesses, are being developed all the time. Some of these tools will be useful to incorporate as part of a standard security evaluation. Devices already on the network will not have been subject to evaluation by those tools, which may be able to detect new security holes.

To make sure that all network equipment is subject to assault by the latest tools, schedule re-evaluations at regular intervals for each device or program in use on the network. The tests do not have to be run every month, but there should not be more than a six-month interval between tests.

Secure evaluation and re-evaluation of network equipment can help ensure that an organization's network is running at peak security performance, especially when combined with periodic attack simulations.