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.