The routine goes something like this. First a breach of security occurs somewhere in the enterprise, it could be something as small as a single computer getting infected or it could be a massive data loss. It seems like that's a wide range of events, but often the reaction in an enterprise is the same. The IT executives have a meeting to determine fault and then the analysts and engineers are given the task of making sure that that particular incident never happens again. The analysts and engineers then reply with budget requests for new software and hardware from their favorite vendors. Unfortunately the end result is generally that money is spent and security is only moderately improved, if at all.

In the midst of reacting, everyone forgets that technology doesn't configure itself and that the weakest link are the people. Instead of ramming in the latest and greatest in technology, we should be leading our company to review, create (if necessary) and rewrite our security policies. Without a policy, security tools are like unguided missiles that we hope hit their target.

An example of security without a policy would be configuring a firewall without a policy as to what should be allowed or not allowed. Obviously, anyone can configure such a firewall, but what will the result be? Will they simply deploy an Adaptive Security Appliance (ASA) with a default configuration, or will they lock things down to where ordinary business traffic is impeded? An even better question is will they do it the same on the next 20 firewalls configured? Even if it's configured "correctly", what happens when someone in the business questions why something is or isn't blocked and asks for an exception?

Unfortunately one study on data leakage, commissioned by Cisco, showed that at least 23 percent of respondents worked for a company without written security policies. The study went on to say that 77% of IT professionals believe that their company policies on security need improvement or updating. That leaves a lot of unguided missiles flying around while the bad guys are getting more and more precise.

So how does one help get their company from being a statistic to being on the path to a secure infrastructure? Well the first step is probably the hardest, you have to convince the company that there is a problem and get buy in from the executive suite. Without an executive champion, any work on the security policies would be the equivalent of the tail wagging the dog and probably will end up in a dusty binder somewhere or archived in your company's e-mail server. Executives are busy and have a lot of things to worry about so make sure to present the security policy review in business benefits such as compliance, reduced risk, and process improvement.

Once you have a project champion, it's time to review what you currently have in place. Look at what is working, what needs changed or improved and what is missing. Some of the basic policies to look for include:

• Employee Acceptable Use Policy
• Partner Acceptable Use Policy
• Administrator Acceptable Use Policy
• Password Policy
• Security Response Policy
• Security Responsibility Policy

The next step is to work with your champion and other stakeholders to assign levels of importance and risk to various systems and parts of the network. For example, the e-mail system might be high priority and high risk, but a digital signage application might be medium priority and low risk. The risk is based on what could happen if the system was compromised or its data lost or stolen. Priority helps to rank systems based on how fast they need to be restored after an incident. Together the priority and risk rankings will help frame your company's policies and how money will be prioritized for implementing security measures.

Once you have your team together and have all of your policies in place, you're not done. Just like the Cisco PPDIOO model for implementing network projects, security policies require constant monitoring, review and incremental improvements. Each incident provides an opportunity to review what worked, what didn't and how the policies can be changed to make better outcomes in the future. In addition, changes to the network or to the protected systems should trigger a review of security to make sure that the original security measures are still relevant and accurate.

How do you keep your company's security policies up to date? How do you enforce them? Share your experiences, tips, tricks and war stories in the comments below. Want to see more about Cisco's suggestions for security policies, then click here.