Problem solve Get help with specific problems with your technologies, process and projects.

Security Policies

This chapter presents a way for you to decide what your security goals are and establish, implement and enforce the security rules that will help you achieve them.

The following excerpt is from Chapter 2, Security Policies, of Web Security Field Guide, written by Steve Kalman and published by Cisco Press.

Justifying security

Security is expensive. Before allocating funds, senior management will want to know what they are buying, what it will protect and what alternatives they have. This section presents the tools you need to answer those questions.

Security defined

The following is a good definition of security:
"Tools and techniques that prevent unauthorized people or processes from doing anything with or to your data, computers or peripherals."

Security is not a firewall or cryptography or a virus scanner; although, they are all components of a security solution. It is a process that examines and then mitigates the risks that arise from your company's day-to-day activities.

Kinds of security risks

Risks come in a wide variety of forms. Here are some examples:

  • Loss of assets (theft)
  • Service disruption (business interruption)
  • Loss of reputation (disparagement)
  • Expenses of recovery (profitability impact)

Shareholders expect managers to protect or enhance the value of the company. Security breaches that affect any of these items violate shareholders' expectations.

Note: Another kind of risk is just now emerging: the risk of running afoul of the law. Many new laws include punitive measures (usually fines). Three examples from the United States are Graham-Leach-Billey, which affects U.S. financial institutions and requires disclosure of privacy policies to customers; the Health Insurance Privacy and Portability Act (HIPPA), which restricts disclosure of health-related data along with personally identifying information; and the Electronic Communications Privacy Act (ECPA), which specifies who can read whose e-mails under what conditions.

Knowing the enemy

A common security mistake is to assume that attacks always come from outside your organization. Many companies do the technological equivalent of digging a deep moat around the organization and filling it with hungry alligators, then leaving the interior doors unlocked.

You might like to assume that hackers are nearly all pimply-faced, teenagers. This just isn't so. A few artists can find security flaws in systems and exploit them. Some of those talented -- but -- misguided individuals codify their exploits into scripts and release them on the Internet where a subclass of hackers, known as Script Kiddiez, try to use those scripted exploits. The bad news is that there are a lot of those "Kiddiez." However, the very fact that they are scripted attacks makes them easy to detect and often fairly simple to defend against. (See Chapter 11, "Maintaining Ongoing Security," for details.) Your ID Badge gets you in through the front door and into your work area. It also prevents you from going where you are not allowed. As a society, we've had hundreds of years of experience designing physical security systems (which still get breached, by the way).

Computers have been with us for only a few decades; computer networks even less time. A CSI/FBI study (conducted annually, available at states that more than half of all intrusions are by insiders. Security professionals have to work a lot harder to protect their organizations against this class of intruders. By and large, they are more sophisticated computer users. Even worse, they already have valid credentials that allow them access to the network. You have to apply the restricted-area-badge concept to your internal networks, as well. Many of the chapters in this book are specifically aimed at protecting against this internal user threat. Chapter 6, "Enhancing the FTP Server," is a prime example. In it, you learn (among other things) how to encrypt FTP logins so that insiders cannot listen in and steal other users' credentials.

>> Read the rest of Chapter 2, Security Policies.

This was last published in June 2003

Dig Deeper on Web application and API security best practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.