Enterprise Software

Using risk management to develop a corporate security policy

Insurance companies use risk management to set rates and control how insurance policies are written. You can use the same basic techniques to create effective security policies for your network. Here's how.

I used to work for a large insurance company that always tried to educate its employees about risk management (from an insurance perspective, not from an IT perspective). Insurance companies have risk management down to a science. They know the odds of various types of disasters occurring and what they need to charge customers based on those odds. They also know exactly how much they need to charge customers who have previously filed claims in order to recoup the cost of paying those claims. Often, such techniques can be used in creating corporate disaster recovery plans.

Traditionally, disaster recovery plans have addressed issues such as getting all of the systems back online after a natural disaster. However, during the last few years, there's been an overwhelming trend to treat security incidents like other types of disasters. Companies are starting to add security breach contingencies to their disaster recovery plans, and risk management techniques play a major role in the development of a corporate security policy.

What's risk management?

Before I explain how you can apply risk management to your corporate security policy, I want to take a look at the basics of risk management. The risk management process involves answering four simple questions:

  • What assets do you have that are worth protecting?
  • What are the known threats to those assets?
  • What can you do to keep those threats from actually occurring?
  • What type of damage control can you perform if one of the risks to your assets does occur?

In the sections below, I'll address each of these questions and explain how they apply to creating a corporate security policy.

What assets are worth protecting?

When it comes to the assets that are worth protecting, your mind probably immediately jumps to your company's hardware inventory. Answering this question, however, can be a bit more difficult than copying an inventory sheet.

You'll need to ask yourself another question: What will you use this security policy for? Ideally, a corporate security policy should serve two functions. First, it should educate the company's employees as to what is expected of them regarding cybersecurity (prevention). Second, it should be a guide that dictates the appropriate response to a variety of security incidents.

To accomplish these two goals, you need to limit your policy to a manageable size. If you're trying to educate users on security strategies, keep the documentation short and simple. Users will usually ignore anything that's over a couple of pages long or that's overly complex.

So let's return to the original question: What asserts are worth protecting? You'll probably want to list everything the IT department owns, just so that you're covered legally. (Some companies go so far as to list the software manuals among the assets. The reasoning is that someone could potentially find a software weakness by studying the manuals, but I'm not sure how much I buy into that theory.) Along with your hardware inventory, there are other types of assets you'll need to consider. For example, a security policy might include assets such as users' passwords, digital certificates, and backup media.

What are the known threats to your assets?

Now it's time to list the events that could threaten your assets and therefore compromise your organization's security. As I mentioned, you should list passwords as an asset worth protecting. If you want to get technical, the real asset is your data. Since authentication credentials are the gateway to your data, they should also be treated as an asset that needs protecting.

So what are the known threats to passwords? The obvious answer is that hackers have all sorts of fancy password-cracking utilities. But let's not stop there. Another threat to passwords is disclosure by the users. For example, we've all seen users write down a password that's difficult to remember and tape it to their monitor.

I've also seen an employee give his password to another employee who was having trouble printing under his own account due to a login script error. I've even heard employees give their passwords to help desk staff over the phone (a no-no in itself) in an office environment where dozens of other people could easily overhear the conversation.

Clearly, passwords can be disclosed by users with no malicious intent. The resulting damage, however, can be just as serious as if the security breach were malicious. Therefore, when making your list of known threats against your assets, try to be creative and think of both malicious and casual threats.

What can you do to keep those threats from actually occurring?

A risk management security policy focuses on prevention and response. Because some incidents just can't be prevented, it's crucial to establish a response plan for handling your identified threats.

Although the risk management process might be new to you, you've undoubtedly seen the prevention portion implemented in security policies. Every time you see a policy that says passwords must be at least eight characters long and must be changed every 30 days, you're looking at preventive steps designed to avert a security incident.

It seems logical that if your goal is to prevent a security incident, you should make your policy as restrictive as possible. Excessively restrictive policies, however, can backfire. You can easily create a policy that is so restrictive that employees can't properly do their jobs.

Here's a classic example of security policies running amuck: When I worked for the U.S. military, my security clearance was so high that I could get access to just about anything I wanted. However, getting access wasn't always as simple as asking for it. Typically, there was extensive paperwork that had to be filled out in order to justify my need for access. If a particular unit was having a problem, it sometimes had to wait for a very long time to get help because of the lengthy security review process. By the time the necessary permission was granted, the unit's system might have been down for a week or two.

Another example of having excessive security backfire is requiring passwords that are too complex. For example, imagine that in the interest of having secure passwords, you required a 100-digit, random-character password that had to be changed every seven days. Nobody could possibly remember such a password. It's inevitable that users would write the passwords down, thus completely undermining the security that you're trying to implement.

One last example has to do with physical security. In a former job, my boss replaced the lock on the server room door with a card reader. You had to swipe your badge through the card reader to gain access to the room. The policy stated that whenever multiple people needed to enter the room, they had to do so individually, each allowing the door to completely shut before the next person could swipe his or her badge.

The company had a large IT department, and most of the members of the administrative staff went in and out of the server room dozens of times each day. It didn't take everyone long to realize that the card reader was a real pain. Soon, the policy was followed only when the boss was around. Whenever he was out of the office or in a meeting, the door was usually propped open. So much for security.

What type of damage control can you perform?

The answer to this question will vary widely from company to company, depending on the level of security that's practical to maintain. For example, what happens if one of your users accidentally discloses a password to another employee? In some organizations, this wouldn't be a big deal, and the official response would be to do nothing.

However, I've worked as a contractor for companies whose official response was to fire both employees, run an audit report to scan the network for all file and database modifications that occurred since the time of the compromise, and then restore those files and databases from a backup that was made prior to the incident.

In a way, I can understand this procedure, since it guarantees the integrity of the data. At the same time, though, restoring a backup is resource-intensive. It also means that you'll lose any data that was added to the system since the backup was made. In all but the highest security environments, the cost of such an operation far exceeds the risks of not reverting to a previous version of each file.

Inevitably, someone in your company will accidentally disclose a password, and it's best to know how to deal with the problem before it happens. But remember that passwords are only a tiny fraction of your organization's overall security policy. You need to develop policies and procedures for any asset (real or virtual) that's worth protecting.

An ounce of prevention…

Although there's technically no right or wrong way to create a security policy, the risk management process has real merit. Insurance companies make billions of dollars every year by using a similar process. Applying such a process to your own organization can greatly increase your chances of preventing or quickly recovering from a security incident.

Editor's Picks

Free Newsletters, In your Inbox