Fundamentally, computer security is a series of technical solutions to non-technical problems. You can spend an unlimited amount of time, money, and effort on computer security, but you will never quite solve the problem of accidental data loss or intentional disruption of your activities. Given the right set of circumstances - software bugs, accidents, mistakes, bad luck, bad weather, or a motivated and well-equipped attacker - any computer can be compromised, rendered useless, or worse.
The job of the security professional is to help organizations decide how much time and money need to be spent on security. Another part of that job is to make sure that organizations have policies, guidelines, and procedures in place so that the money spent is spent well. And finally, the professional needs to audit the system to ensure that the appropriate controls are implemented correctly to achieve the policy's goals. Thus, practical security is really a question of management and administration more than it is one of technical skill. Consequently, security must be a priority of your firm's management.
This book divides the process of security planning into six discrete steps:
Security needs planning
Creating policies to reflect your needs
Audit and incident response
This chapter covers security planning, risk assessment, cost-benefit analysis, and policy-making. Implementation is covered by many of the chapters of this book. Audit is described in Chapter 10, Auditing and Logging, and incident response in Chapter 17, TCP/IP Services through Chapter 26, Computer Security and U.S. Law.
There are two critical principles implicit in effective policy and security planning:
Policy and security awareness must be driven from the top down in the organization. Security concerns and awareness by the users are important, but they cannot build or sustain an effective culture of security. Instead, the head(s) of the organization must treat security as important, and abide by all the same rules and regulations as everyone else.
Effective computer security means protecting information. All plans, policies and procedures should reflect the need to protect information in whatever form it takes. Proprietary data does not become worthless when it is on a printout or is faxed to another site instead of contained in a disk file. Customer confidential information does not suddenly lose its value because it is recited on the phone between two users instead of contained within an email message. The information should be protected no matter what its form.
A computer is secure if it behaves the way that you expect it will.
There are many different kinds of computer security, and many different definitions. Rather than present a formal definition, this book takes the practical approach and discusses the categories of protection you should consider. We believe that secure computers are usable computers, and, likewise, that computers that cannot be used, for whatever the reason, are not very secure.
Within this broad definition, there are many different kinds of security that both users and administrators of computer systems need to be concerned about:
Protecting information from being read or copied by anyone who has not been explicitly authorized by the owner of that information. This type of security includes not only protecting the information in toto, but also protecting individual pieces of information that may seem harmless by themselves but that can be used to infer other confidential information.
Protecting information (including programs) from being deleted or altered in any way without the permission of the owner of that information. Information to be protected also includes items such as accounting records, backup tapes, file creation times, and documentation.
Protecting your services so they're not degraded or made unavailable (crashed) without authorization. If the system is unavailable when an authorized user needs it, the result can be as bad as having the information that resides on the system deleted.
Making sure that the system behaves as expected by the authorized users. If software or hardware suddenly starts behaving radically differently from the way it used to behave, especially after an upgrade or a bug fix, a disaster could occur. Imagine if your ls command occasionally deleted files instead of listing them! This type of security can also be considered as ensuring the correctness of the data and software you use.
Regulating access to your system. If unknown and unauthorized individuals (or software) are found on your system, they can create a big problem. You must worry about how they got in, what they might have done, and who or what else has also accessed your system. Recovering from such episodes can require considerable time and expense for rebuilding and reinstalling your system, and verifying that nothing important has been changed or disclosed - even if nothing actually happened.
As well as worrying about unauthorized users, authorized users sometimes make mistakes, or even commit malicious acts. In such cases, you need to determine what was done, by whom, and what was affected. The only way to achieve these results is by having some incorruptible record of activity on your system that positively identifies the actors and actions involved. In some critical applications, the audit trail may be extensive enough to allow "undo" operations to help restore the system to a correct state.
Although all of these aspects of security above are important, different organizations will view each with a different amount of importance. This variance is because different organizations have different security concerns, and must set their priorities and policies accordingly. For example:
In a banking environment, integrity and auditability are usually the most critical concerns, while confidentiality and availability are the next in importance.
In a national defense-related system that processes classified information, confidentiality may come first, and availability last.
 In some highly classified environments, officials would prefer to blow up a building rather than allow an attacker to gain access to the information contained within that building's walls.
In a university, integrity and availability may be the most important requirements. The priority is that students be able to work on their papers, rather than tracking the precise times that students accessed their accounts.
If you are a security administrator, you need to thoroughly understand the needs of your operational environment and users. You then need to define your procedures accordingly. Not everything we describe in this book will be appropriate in every environment.
Security professionals generally don't refer to a computer system as being "secure" or "unsecure." Instead, we use the word "trust" to describe our level of confidence that a computer system will behave as expected. This acknowledges that absolute security can never be present. We can only try to approach it by developing enough trust in the overall configuration to warrant using it for critical applications.
 We use the term unsecure to mean having weak security, and insecure to describe the state of mind of people running unsecure systems.
Developing adequate trust in your computer systems requires careful thought and planning. Decisions should be based on sound policy decisions and risk analysis. In the remainder of this chapter, we"ll discuss the general procedure for creating workable security plans and policies. The topic is too big, however, for us to provide an in-depth treatment:
If you are at a company, university, or government agency, we suggest that you contact your internal audit and/or risk management department for additional help (they may already have some plans and policies in place that you should know about). You can also learn more about this topic by consulting some of the works referenced in Appendix D, Paper Sources. You may also wish to enlist a consulting firm. For example, many large accounting and audit firms now have teams of professionals that can evaluate the security of computer installations.
If you are with a smaller institution or are dealing with a personal machine, you may decide that we cover these issues in greater detail than you actually need. Nevertheless, the information contained in this chapter will help guide you in setting your priorities.