Building An Information Security Policy Part 2: Hardware and Software

In my previous blog, I outlined how understanding the roles of network devices is important for building an effective security policy. In this post, I will cover considerations when selecting hardware and software for network devices.

After an organization has identified device roles and features, the next step to building a secure network is selecting the right hardware and software. Effective configuration and deployment of network elements is dictated by required functions and permitted traffic flows, which in turn drive the choice of hardware and software. Device capabilities should not define the security policy, although they may enhance it. Choosing products that don’t meet security policy needs is a sure way to limit its effectiveness.

Knowing what you need is critical. However, one major influence on security policy is business return on investment. When possible, consider migration strategies that make use of existing infrastructure to support newer features and a more secure design. Always consider relocation of hardware to different areas of the network, or simply upgrading a device by adding additional memory to accommodate new software versions.

When selecting new hardware, plan for future growth in terms of device capacity (bandwidth), performance (processor, memory), load balancing/redundancy capabilities, and flexibility (static form factor vs. expansion slots for additional modules).

Set realistic performance goals to ensure stability and predictability and choose the best way to implement them. For example, features such as crypto are implemented in special hardware. It may be acceptable to use software-based encryption for device management, but this won’t be scalable for VPN gateways.

A good design should facilitate change management and to maintain simplicity, devices selected should have some uniformity in the way they are managed and configured. This is an issue to consider -- along with potential interoperability issues -- when deciding on single-vendor vs. multiple-vendor solutions.

[Read why information security professionals should take the time to teach their friends and neighbors about security best practices in "Be The Security Good Samaritan."]

Hardware configurations also will be influenced by software in terms of features supported, as well as processor and memory requirements. When selecting software, in addition to providing the required functionality, consider the following:

•Standards-based versus vendor proprietary features

•If certified products are required, is the vendor involved with certification efforts and committed to keeping certifications up to date?

•Does the software provide for system hardening and performance optimization (e.g. control-plane policing and system tuning parameters) and system/feature failover options?

•Understand performance trade-offs when enabling several features applied to the same traffic flows. Multiple devices may be required to provide all feature requirements.

•Is the vendor committed to secure coding practices and responsive to addressing vulnerabilities?

Once software has been selected, procedures for the monitoring of deferrals (cases in which software can be deferred if it has specific defects identified by the vendor) and Product Security Incident Response Teams (PSIRTs) must be in place. Instability and security vulnerabilities in software will reflect badly on security policy if there are no upgrade and mitigation strategies in place.

When hardware and software selection maps to security policy objectives, the next step is to start configuration and deployment. In my next post, I will discuss how to deploy a secure network using physical and logical segmentation techniques, reinforcing the concept that security should be integrated at all layers of a network design.