Secure Networks: How To Develop An Information Security Policy

A security policy is the foundation of a secure network, but it must balance security with business needs. Here are some guidelines for successful security policy development.

Natalie Timms

January 23, 2014

3 Min Read
Network Computing logo

Security is often referred to as an overlay to a network topology. While security methods provide protection for access and infrastructure, these methods should be the result of a carefully defined security policy. An effective security policy integrates well-known protection methods into a network in a way that meets both security standards and the goals of the entity being secured.

An information security policy builds the foundation for a secure network, but it must be seen as valuable to an entity. The selling point for a security policy is showing how it maps to key business drivers such as:

•Improved efficiency through streamlined security processes that reduce operational expenses in terms of time, money and personnel.

•Increased productivity through well-defined and applied policies that correctly balance the level of access with perceived risk.

•Better agility, allowing for efficiency with respect to the implementation of compliance and regulatory objectives, migration strategies and risk mitigation techniques.

The deployment of network security features is the result of the approved security policy. Here are some important considerations that should be taken into account in security policy development:

•Remember that each entity will have its own objectives. To win support, a security policy's benefits must be apparent to each specific entity.

•It's critical to understand what you are trying to secure and why; if you don’t understand the underlying network, how can you secure it? Network addressing schemes, choice of routing protocol, and correct mapping of physical connections, such as switch ports to logical configurations, are basic components that must be understood.

•Clearly define network objectives in terms of business requirements and goals, for example: Performance and availability, including SLA requirements, capacity and potential growth, and efficient bandwidth usage; audit and logging requirements; monitoring/troubleshooting, including cost of downtime and acquisition of management tools; and provisioning model (for example, consider the need for multiple levels of control and change management processes.)

•Identify the type and levels of security required. Consider regulatory compliance requirements such as SOX and HIPAA.

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

•Identify applicable network best practices, both general and industry specific, such as IETF RFCs (1918, 3330, 2827, 3704), ISO frameworks (27001, 27002), and COBIT IT security standards.

•Integrate tools and technologies that can be mapped to a business objective. Areas to consider include authentication and encryption requirements for confidentiality, bandwidth management, application-level security, and multi-vendor versus single-vendor designs.

While security policy may be seen as the blueprint for applying protection over the network topology, in actuality it facilitates a layered view, allowing security to be integrated into the network by identifying key areas of a network design such as:

•Network devices, their placement, roles and capabilities.

•Software and hardware requirements for feature support, capacity, maintainability and migration strategies.

•Logical views mapped to physical plans.

•Addressing and identifiers used for identification of policy elements.

•Routing and forwarding methods for efficiency and applicability.

I plan to drill down into these areas in terms of secure design in upcoming blog posts.

About the Author(s)

Natalie Timms

nullNatalie Timms is the former program manager with the CCIE certification team at Cisco, managing exam curriculums and content for the CCIE Security track, and was responsible for introducing Version 4.0 of the exam. Natalie has been involved with computer networking for more than 20 years, much of which was spent with Cisco in various roles: field sales specialist, product manager and software engineer. Natalie has contributed at the IETF standards level and has written many white technical papers and is also a Cisco Press author. Natalie is a US patent holder and has a CCIE Security Certification as well as a BSc in Computing Science and Statistics from Macquarie University in Sydney, Australia. Natalie moved to the US in 1995 and after meeting her husband in the local Cisco office, has called Seattle home.

Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like

More Insights