cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Community Helping Community

Building Strong Security Policies

2463
Views
0
Helpful
0
Comments
Cisco Employee

7-Security-Policy-Development.jpgWhat 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:

http://www.sans.org/resources/policies/#template

Cisco has a Security Policy Builder tool at: http://www.ciscowebtools.com/spb/

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.

CreatePlease to create content
Content for Community-Ad
FusionCharts will render here