NCSAM Tip #21: Building Strong Security Policies

October 31, 2011 - 2 Comments

What good does a firewall, IPS sensor, encryption device, and your favorite security product and tool do if you do not have guidelines, policies, and best practices on how to effectively configure and use them? Building strong security policies is crucial for any organization. These policies should be strong, yet realistically flexible to accommodate ever-changing requirements. Policies communicate not only a standard but also an agreement on what should be the best practice for a specific situation (in this case, related to security). Policies must be detailed, yet easy to understand, and must also balance enforcement and productivity. A security policy is useless if it impedes productivity. During the security policy design stages, you should define the reasons why such a policy is needed. Also define the stakeholders, contacts, and their responsibilities. In addition, you should discuss how to handle violations to such a policy. Depending on the size and goals of your organization, you may document the security policies in one large document or several small ones. Note: In most cases, smaller documents are easier to maintain and update, rather than having bibles for security policies that no one can read or keep up-to-date. Occasionally, certain policies are appropriate for every site within your organization; others may be specific to certain environments. In addition to policies being strong and flexible, they must be enforceable. An organization can have many different policies depending on its applications and systems. Some policies are implemented because of regulatory compliance to standards like Sarbanes-Oxley and the Health Insurance Portability and Accountability Act (HIPAA) of 1996. The following are some of the most common policies in every organization:

  • Physical security
  • Information protection
  • Perimeter security
  • Device security
  • Acceptable use of specific applications and systems
  • Remote access
  • Wireless security
  • Data center security
  • Extranets and demilitarized zones (DMZ)
  • Patch management

The following are examples of other policies:

  • Lab security
  • Acceptable encryption protocols
  • Network admission control
  • Identity management

Trust is the main subject in many policies. Many say that policies will not be written if you trust everyone to do the right thing. Ideally, you want to trust all resources, but that is unrealistic. Even defects in software and hardware are risks that you do not want to take by trusting everything that is not human. Different types of people (like your staff, guests, and contractors) should be trusted at different levels. Ensure that the level of access commensurate with the level of trust. SANS has several security policy templates that you can download at Cisco has a Security Policy Builder tool at Some people think of security policies as long documents that merely define what level of access systems and people have. However, policies include all of the previously mentioned items and topics, such as:

  • Baseline router configuration parameters
  • Guidelines for forwarding e-mails to external addresses
  • Configuration management procedures and change control

Configuration management procedures and change control is a hot topic when planning incident response procedures. Security changes are defined as changes to network equipment that might impact the overall security of the network. Remember that these policies have to be flexible enough to accommodate the changes that staff members make to respond to security incidents and outbreaks. All security teams (such as InfoSec, CSIRTs, and so on) should review the list of business and technical requirements in order to identify specific network configuration or design issues and meet security needs. Patch management is also a hot topic today. Always ensure that the current software revision levels of network equipment, desktop machines, and servers are up-to-date with security patches and hotfixes. Update security policies regularly or on an as-needed basis. At a minimum, schedule an annual review to ensure that security policies do not become obsolete because of technological changes and demands. Also, include a provision for ad-hoc updates when higher-priority changes are needed. It is recommended that you engage subject matter experts (SME) when reviewing existing policies because you should consider several factors in addition to those included during the initial development. SMEs can provide valuable input into changes in technology and best practices that may need to be incorporated into the specific policy. Security violations, deviations, and relevant audit information should also be reviewed when considering an existing policy. You can use various techniques when planning, developing, and updating security policies. Always take the following basic idea into consideration: the policy must primarily reflect what is good for the security of the organization as a whole without limiting productivity.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. It’s been said that a security policy is only as good as the paper it is written on. That is a saying for a reason! But defining, implementing and monitoring and changing the policy over time to meet needs as they evolve is easier said than done.

    1. IT security has historically been viewed as the “department of no”, but in today’s business environment, that must and can change as productivity is the name of the game. It starts with a good policy that has buy-in from business users – otherwise the policy will be viewed poorly and users will look for ways around it.

    2. In addition to obtaining feedback from the business before implementing a policy, organizations should implement technology and a process to enforce and manage the security policy over time. Managing the policy over time is a key point here because as Omar states in his blog that the IT environment and business requirements are constantly changing. And this is where it really gets tough.

    3. Today’s IT environment is extremely complex. Since I work for AlgoSec, a network security policy management vendor, I’ll use an example that we see often. Any IT professional working for a large organization who has tried to change a rule in a firewall knows what a nightmare that is. Just understanding what to touch and how – without introducing new security risk or business disruption – can take hours or days of manual work. The majority of firewall breaches are actually caused by misconfigurations, not firewall flaws. This is a case where there a policy was established at one point and technology is in place, but it isn’t managed well over time. This is where automation comes in.

    Many organizations are challenged with manually managing firewall policies and documenting change requests, whether for compliance reasons as Shaul discusses in his comment, reducing risk or for optimized firewall performance and IT productivity. Automating firewall management enables them to gain significantly improved visibility so they can proactively improve, optimize and document changes to ensure an effective policy lifecycle.

    While I’ve used the example of managing firewall policies, this concept of managing policies over time extends to many other areas of security.

    Sam Erdheim

  2. This tip is gold but CISO’s for medium to large size organizations are facing the nightmare of trying to ensure that their firewall and network security administration teams meet compliance requirements at all times and for each and every network and security configuration change.

    Firewall administrators are required to manually test each configuration change against a complex security policy guidelines document and make sure that no internal or external regulatory compliance standard is breached. The more compliance policies the organization has, the more time it takes, and it’s harder to be accurate. Firewall administrators also need to ensure that no configuration change creates potential network downtime.

    Both of these tasks require time and experience. Surveys show that a single configuration change can take anywhere between 30 minutes up to days to be completed successfully. The larger the organization, the higher the number of configuration changes per week and the number of experienced security administrators required to handle them.

    The landscape becomes exponentially complex for organizations of the following nature:

    – 10’s to 100’s of firewalls to be managed
    – Firewalls from different vendors each with its own management GUI and behavior nuances
    – 100’s of configuration changes per week
    – Many Internal and external regulation compliance policies like PCI DSS, SOX, HIPAA, ISO 27001 etc…
    – Multiple data centers
    – Firewall administrators in different data centers across different time zones
    – Firewall administrators from different nationalities and different cultures
    – Firewall administrators of varied experience levels
    – Firewall administrators with various fatigue levels throughout the week

    It’s a management chaos for the CISO who needs to ensure 100% compliance at all times, for all configuration changes, by each and every of the organization’s firewall administrators.

    CISO’s and organizations striving to address this challenge must implement change automation solutions that take all of these factors into account and provide the “safety net” which allows CISO’s to sleep like a baby, at least most nights.

    This subject matter is close to my heart because I see how organizations fail to employ a structured approach to address compliance issues, and basically wait for a breach or network downtime to happen before they take action.


    Disclosure – I work for a network security company called Tufin Technologies which provides firewall operations, compliance and change automation solutions.