Chapter 5. Organizational Security Policy And Prevention

At A Glance

This chapter addresses security policy from the bottom up and the top down; everyone in the organization has some role to play in ensuring the security of computers, networks, and data. Supplementary management checklists to this chapter have been provided at the end of Part 3.

Security in a Working Organization

Security is not free. The more elaborate your security measures become, the more expensive they become. Systems that are more secure may also be more difficult to use, although this need not always be the case. Security can also get in the way of “power users,” who wish to exercise many difficult and sometimes dangerous operations with-out authentication or accountability. Some of these power users can be politically powerful within your organization. Alternatively, some organizations may feel that any security measures are too costly and will try to conduct business without taking the time to assess the true costs of implementation and the potential losses from a negligent attitude. A series of checklists has been provided at the end of Part 3 which outline steps that may be taken, at various levels, to ensure that the computing environment is as safe as possible, given certain constraints on time, personnel, and financial resources.

After you have completed your risk assessment and cost-benefit analysis, you will need to convince your organization’s management of the need to act upon the information. Normally, you would formulate a policy that is then officially adopted. Frequently, this process is an uphill battle. Fortunately, it does not have to be. The goal of risk assessment and cost-benefit analysis is to prioritize your actions and spending on security. If your business plan is such that you should not have an uninsured risk of more than a certain monetary amount per year, you can use your risk analysis to determine what needs to be spent to achieve this goal. Your analysis can also be a guide as to what to do first, and then second, and can identify which things you should relegate to later years.

Another benefit of risk assessment is that it helps to justify to management that you need additional resources for security. Most managers and directors know little about computers, but they do understand risk and cost/benefit analysis. If you can show that your organization is currently facing an exposure to risk that could total a certain monetary amount per year (add up all the expected losses plus recovery costs for what is currently in place), then this estimate might help convince management to fund some additional personnel and resources.

On the other hand, going to management with a vague “We’re really likely to see several break-ins on the Internet after the next CERT/CC announcement” is unlikely to produce anything other than mild concern (if that).

The Role of Security Policy

Policy helps to define what you consider to be valuable, and it specifies what steps should be taken to safeguard those assets.

Policy can be formulated in a number of different ways. You could write a very simple, general policy of a few pages that covers most possibilities. You could also craft a policy for different sets of assets: a policy for e-mail, a policy for personnel data, and a policy on accounting information. A third approach, taken by many large corporations, but applicable to organizations of all sizes, is to have a small, simple policy augmented with standards and guidelines for appropriate behavior. We’ll briefly outline this latter approach, with the reader’s understanding that simpler policies can be crafted; more information is given in the references.

Policy plays three major roles. First, it makes clear what is being protected and why. Second, it clearly states the responsibility for that protection. Third, it provides a ground on which to interpret and resolve any later conflicts that might arise. What the policy should not do is list specific threats, machines, or individuals by name—the policy should be general and change little over time.

Standards

Standards are intended to codify the successful practice of security in an organization. They are generally phrased in terms of “shall.” Standards are generally platform independent, and at least imply a metric to determine if they have been met. Standards are developed in support of policy, and change slowly over time. Standards might cover such issues as how to screen new hires, how long to keep backups, and how to test UPS systems.

For example, consider a standard for backups. It might state:

Backups shall be made of all online data and software on a regular basis. In no case will backups be done any less often than once every 72 hours of normal business operation. All backups should be kept for a period of at least six months; the first backup in January and July of each year will be kept indefinitely at an off-site, secured storage location. At least one full backup of the entire system shall be taken every other week. All backup media will meet accepted industry standards for its type, to be readable after a minimum of five years in unattended storage.

This standard does not name a particular backup mechanism or software package. It clearly states, however, what is to be stored, how long it is to be stored, and how often it is to be made.

Consider a possible standard for authentication: Every user account on each multi-user machine shall have only one person authorized to use it. That user will be required to authenticate his or her identity to the system using some positive proof of identity. This proof of identity can be through the use of an approved authentication token or smart card, an approved one-time password mechanism, or an approved biometric unit. Reusable passwords will not be used for primary authentication on any machine that is ever connected to a network or modem, that is portable and carried off company property, or that is used outside of a private office.

Guidelines

Guidelines are the “should” statements in policies. The intent of guidelines is to interpret standards for a particular environment—whether that is a software environment or a physical environment. Unlike standards, guidelines may be violated, if necessary. As the name suggests, guidelines are not usually used as standards of performance, but as ways to help guide behavior.

Here is a typical guideline for backups:

Backups on Unix-based machines should be done with the “dump” program. Backups should be done nightly, in single-user mode, for systems that are not in 24-hour production use. Backups for systems in 24-hour production mode should be made at the shift change closest to midnight, when the system is less loaded. All backups will be read and verified immediately after being written.

Level 0 dumps will be done for the first backup in January and July. Level 3 backups should be done on the 1st and 15th of every month. Level 5 backups should be done every Monday and Thursday night, unless a level 0 or level 3 backup is done on that day. Level 7 backups should be done every other night except on holidays.

Once per week, the administrator will pick a file at random from some backup made that week. The operator will be required to recover that file as a test of the backup procedures.

Guidelines tend to be very specific to particular architectures and even to specific machines. Guidelines also tend to change more often than do standards, to reflect changing conditions.

Some Key Ideas in Developing a Workable Policy

The role of policy (and associated standards and guidelines) is to help protect those items you (collectively) view as important. They do not need to be overly specific and complicated in most instances. Sometimes, a simple policy statement is sufficient for your environment, as in the following example.

The use and protection of this system is everyone’s responsibility. Only do things you would want everyone else to do, too. Respect the privacy of other users. If you find a problem, fix it yourself or report it right away. Abide by all applicable laws concerning use of the system. Be responsible for what you do and always identify yourself. Have fun!

Other times, a more formal policy, reviewed by a legal professional and various security consultants, is the way you need to go to protect your assets. Each organization will be different. There are some key ideas to your policy formation, though, that need to be mentioned more explicitly.

Assign an owner

Every piece of information and equipment to be protected should have an assigned “owner.” The owner is the person who is responsible for the information, including its copying, destruction, backups, and other aspects of protection. This is also the person who has some authority with respect to granting access to the information.

The problem with security in many environments is that there is important information that has no clear owner. As a result, users are never sure who makes decisions about the storage of the information, or who regulates access to the information. Information (and even equipment!) sometimes disappears without anyone noticing for a long period of time because there is no “owner” to contact or monitor the situation.

Be positive

People respond better to positive statements than to negative ones. Instead of building long lists of “don’t do this” statements, think how to phrase the same information positively. The abbreviated policy statement above could have been written as a set of “don’ts” as follows, but consider how much better it read originally:

It’s your responsibility not to allow misuse of the system. Don’t do things you wouldn’t want others to do, too. Don’t violate the privacy of others. If you find a problem, don’t keep it a secret if you can’t fix it yourself. Don’t violate any laws concerning use of the system. Don’t try to shift responsibility for what you do to someone else and don’t hide your identity. Don’t have a bad time!

When writing policies, keep users in mind. They will make mistakes, and they will misunderstand. The policy should not suggest that users will be thrown to the wolves if an error occurs.

Furthermore, consider that information systems may contain information about users that they would like to keep somewhat private. This may include some e-mail, personnel records, and job evaluations. This material should be protected, too, although you may not be able to guarantee absolute privacy. Be considerate of users’ needs and feelings.

Concentrate on training and awareness

You would be wise to include standards for training and retraining of all users. Every user should have basic security awareness education, with some form of periodic refresher material (even if the refresher only involves being given a copy of this book!). Trained and educated users are less likely to fall for scams and social engineering attacks. They are also more likely to be happy about security measures if they understand why they are in place.

A crucial part of any security system is giving staff time and support for additional training and education. There are always new tools and new threats, new techniques, and new information to be learned. If staff members are spending 60 hours each week chasing down phantom PC viruses and doing backups, they will not be as effective as staff given a few weeks of training time each year. Furthermore, they are more likely to be happy with their work if they are given a chance to grow and learn on the job, and are allowed to spend evenings and weekends with their families instead of trying to catch up on installing software and making backups.

Have authority commensurate with responsibility:

The first principle of security administration:

If you have responsibility for security, but have no authority to set rules or punish violators, it is likely that you will have to take the blame when something big goes wrong.

This Part includes checklists for managers and personnel who will be responsible for security. Important elements to any organization’s security plan are covered including: communication, awareness, training, and appropriate funding to support the plan.

Be sure you know your security perimeter

When you write your policy, you want to be certain to include all of the various systems, networks, personnel, and information storage within your security perimeter. The perimeter defines what is “within” your control and concern. When formulating your policies, you need to be certain you include coverage of everything that is “within” your perimeter or that could enter your perimeter and interact with your information resources. In earlier years, many organizations defined their IT security perimeter to be their walls and fences. Nowadays, the perimeter is less concrete.

For example, consider the following when developing your policies:

o Portable computers and PDAs can be used to access information while away from your physical location. Furthermore, they may store sensitive information, including IP addresses,

phone numbers, and passwords. These systems should have minimum levels of protection, including passwords, encryption, and physical security markings. Users should have additional training and awareness about dangers of theft and eavesdropping.

o Wireless networks used on the premises or otherwise connected to site resources may be connected to by outsiders using directional antennas or simply parked in a car outside the building with a laptop. Wireless networks should be configured and protected to prevent sensitive material from being observed outside, and to prevent insertion of malicious code by attackers.

o Computers used at home by the organization’s personnel are subject to penetration, theft, and the accidental insertion of malicious code. They may also be used contrary to organizational policy (e.g., to run a business, or host a web server with questionable content). The policy needs to make clear how these machines are to be used, protected, and audited.

o Media is dense and portable. If someone makes a CD or DVD of the company financial records to use at a remote site, what happens if the media is stolen or misplaced? Policies should govern who is allowed to take media off-site, how it is to be protected (including encryption) and what is to happen if it is lost or stolen. They should also detail how and when previously used media will be destroyed to limit its potential exposure.

o What are the policies governing people who bring their own PDAs or laptops on site for meetings or simply while visiting? What are the rules governing their connection to site networks, phone lines, printers, or other devices?

o What concerns are there about shipping computers or storage devices offsite for maintenance. What if there is sensitive material on disk? What about leased equipment that is returned to the owner?

o If business partners or contractors have access to your equipment, at your site or at theirs, who guards the material? How is it kept from unwanted contamination or commingling with their own sensitive data?

o What policies will be in place to govern the handling of information provided to your organization under trade secret protection or license? Who is responsible for protecting the information, and where can it be kept and stored?

o What policies govern non-computer information processing equipment? For instance, what policies govern use of the printers, copiers, and fax machines? (Sensitive information on paper is no less sensitive than online.)

Thinking about all these issues before a problem occurs helps keeps the problems from occurring. Building sensible statements into your security policy help everyone to understand the concerns and take the proper precautions.

Pick a basic approach to security issues

Decide if you are going to build around the model of “Everything that is not specifically denied is permitted” or “Everything that is not specifically permitted is denied.” Then be consistent in how you define everything else. The first choice might be most consistent with a relatively open environment, such as a university, while the second case would be more consistent with a commercial institution, such as a bank.

Defend in depth

When you plan your defenses and policy, don’t stop at one layer. Institute multiple, redundant, independent levels of protection. Then include auditing and monitoring to ensure that those protections are working. The chance of an attacker’s evading one set of defenses is far greater than the chance of his evading three layers plus an alarm system.55

Ensuring Compliance and Security Audits

Formulating policy is not enough by itself. It is important to regularly determine if the policy is being applied correctly, and if the policy is correct and sufficient. This is normally done with a compliance audit. The term audit is overloaded, often used to mean (at least), a financial audit, an audit trail (log), a security audit of a system, and a compliance audit for policy.

A compliance audit is a set of actions carried out to measure whether standards set by policies are being met and, if not, why. Standards normally imply metrics and evaluation criteria that can be used by an auditor to measure this compliance. When standards are not met, it can be because of any of a combination of::

1. Personnel shortcomings

2. Insufficient training or lack of appropriate skills

3. Overwork

4. Malfeasance

5. Lack of motivation

6. Material shortcomings

7. Insufficient or inadequate resources

8. Inadequate maintenance

9. Overload/overuse

10. Organizational shortcomings

11. Lack of authority/responsibility

12. Conflicting responsibilities

13. Unclear/inconsistent/confusing tasking

14. Policy shortcomings

15. Unforeseen risks

16. Missing or incomplete policies

17. Conflicting policies

18. Mismatch between policy and environment

What is key to note about this list is that the vast majority of causes of policy problems cannot be blamed on the operator or administrator. Even inadequate training and overwork are generally not the administrator’s choice. Thus, a compliance audit should not be viewed (nor conducted) as an adversarial process. Instead, it should be conducted as a collaborative effort to identify problems, obtain and reallocate resources, refine policies and standards, and raise awareness of security needs. As with all security, a team approach is almost always the most effective. When managed properly, your personnel can embrace good security. The key is to help them in doing their tasks rather than being “on the other side.”

The Problem with Security Through Obscurity

In traditional security, derived largely from military intelligence, there is the concept of “need to know.” Information is partitioned, and you are given only as much as you need to do your job. In environments where specific items of information are sensitive or where inferential security is a concern, this policy makes considerable sense. If three pieces of information together can form a damaging conclusion and no one has access to more than two, you can ensure confidentiality.

In a computer operations environment, applying the same need-to-know concept is usually not appropriate. This is especially true if you should find yourself basing your security on the fact that something technical is unknown to your attackers. This concept can even hurt your security.

55 See "The 12 Layer Matrix: Building a Cyber-Fortress (2003)" by Tom Kellermann at:

http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/SearchGeneral?openform&E-Security/E-Finance&Tools

Consider an environment in which management decides to keep the manuals away from the users to prevent them from learning about commands and options that might be used to crack the system. Under such circumstances, the managers might believe they have increased their security, but they probably have not. A determined attacker will find the same documentation elsewhere—from other users or from other sites. Extensive amounts of documentation are available as close as the nearest bookstore! Management cannot close down all possible avenues for learning about the system. In the meantime, the local users are likely to make less efficient use of the machine because they are unable to view the documentation and learn about more efficient options. They are also likely to have a poorer attitude because the implicit message from management is “We don’t completely trust you to be a responsible user.” Furthermore, if someone does start abusing commands and features of the system, management may not have a pool of talent to recognize or deal with the problem. And if something should happen to the one or two users authorized to access the documentation, there is no one with the requisite experience or knowledge to step in or help out.

Keeping bugs or features secret to protect them is also a poor approach to security. System developers often insert back doors in their programs to let them gain privileges without supplying passwords. Other times, system bugs with profound security implications are allowed to persist because management assumes that nobody knows of them. The problem with these approaches is that features and problems in the code have a tendency to be discovered by accident or by determined attackers. The fact that the bugs and features are kept secret means that they are unwatched, and probably unpatched. After being discovered, the existence of the problem will make all similar systems vulnerable to attack by the persons who discover the problem.

Keeping algorithms, such as a locally developed encryption algorithm, secret is also of questionable value. Unless you are an expert in cryptography, you are unlikely to be able to analyze the strength of your algorithm. The result may be a mechanism that has a serious flaw in it. An algorithm that is kept secret isn’t scrutinized by others, and thus someone who does discover the hole may have free access to your data without your knowledge.

Likewise, keeping the source code of your operating system or application secret is no guarantee of security. Those who are determined to break into your system will occasionally find security holes, with or without source code.56 But without the source code, users cannot carry out a systematic examination of a program for problems. Thus, there may be some small benefit to keeping the code hidden, but it shouldn’t be depended on. The key is attitude. Defensive measures that are based primarily on secrecy lose all their value if their secrecy is breached. Even worse, when maintaining secrecy restricts or prevents auditing and monitoring, it can be impossible to determine whether secrecy has been breached. You are better served by algorithms and mechanisms that are inherently strong, even if they’re known to an attacker. The very fact that you are using strong, known mechanisms may discourage an attacker and cause the idly curious to seek excitement elsewhere. Putting your money in a wall safe is better protection than depending on the fact that no one knows that you hide your money in a mayonnaise jar in your refrigerator.

Responsible Disclosure

Despite our objection to “security through obscurity,” we do not advocate that you widely publicize new security holes the moment that you find them. There is a difference between secrecy and prudence! If you discover a security hole in distributed or widely available software, you should quietly report it to the vendor as soon as possible. We would also recommend that you report it to one of the FIRST teams (described in Annex 4, Organizations). Those organizations can take action to help vendors develop patches and see that they are distributed in an appropriate manner.

If you “go public” with a security hole, you endanger all of the people who are running that software but who don’t have the ability to apply fixes. In the Unix environment, many users are accustomed to having the source code available to make local modifications to correct flaws. Unfortunately, not everyone is so lucky, and many people have to wait weeks or months for updated software from their vendors. Some sites may not even be able to upgrade their software because they’re running a turn-key application, or one that has been certified in some way based on the current configuration. Other systems are being run by individuals who don’t have the necessary expertise to apply patches. Still others are no longer in production, or are at least out of maintenance. Always act responsibly. It may be preferable to circulate a patch without explaining or implying the underlying vulnerability than to give attackers details on how to break into unpatched systems.

56 Unless you’re developing the software all by yourself on your own workstation, several people may have access to the source code, and, intentionally or accidentally, code gets leaked.

We have seen many instances in which a well-intentioned person reported a significant security problem in a very public forum. Although the person’s intention was to elicit a rapid fix from the affected vendors, the result was a wave of break-ins to systems where the administrators did not have access to the same public forum, or were unable to apply a fix appropriate for their environment.

Posting details of the latest security vulnerability in your system to a mailing list if there is no patch available will not only endanger many other sites, it may also open you to civil action for damages if that flaw is used to break into those sites.57 If you are concerned with your security, realize that you’re a part of a community. Seek to reinforce the security of everyone else in that community as well—and remember that you may need the assistance of others one day.

Conclusions on Policy and Prevention

The key to successful risk assessment is to identify all of the possible threats to your system, and to defend against those attacks which you think are realistic threats.

Simply because people are the weak link doesn’t mean we should ignore other safeguards. People are unpredictable, but breaking into a dial-in modem that does not have a password is still cheaper than a bribe. So, we use technological defenses where we can, and we improve our personnel security by educating our staff and users. We also rely on defense in depth: we apply multiple levels of defenses as backups in case some fail. For instance, we buy that second UPS system, or we put a separate lock on the computer room door even though we have a lock on the building door. These combinations can be defeated too, but we increase the effort and cost for an enemy to do that…and maybe we can convince them that doing so isn’t worth the trouble. At the very least, you can hope to slow them down enough so that your monitoring and alarms will bring help before anything significant is lost or damaged.

With these limits in mind, you need to approach computer security with a thoughtfully developed set of priorities. You can’t protect against every possible threat. Sometimes you should allow a problem to occur rather than prevent it, and then clean up afterwards. For instance, your efforts might be cheaper and less trouble if you let the systems go down in a power failure and then reboot than if you bought a UPS system. And some things you simply don’t bother to defend against, either because they are too unlikely (e.g., an alien invasion from space), too difficult to defend against (e.g., a nuclear blast within 500 yards of your data center), or simply too catastrophic and horrible to contemplate (e.g., your management decides to switch all your Unix machines to some well-known PC operating system). The key to good management is knowing what things you will worry about, and to what degree.

Decide what you want to protect and what the costs might be to prevent those losses versus the cost of recovering from those losses. Then make your decisions for action and security measures based on a prioritized list of the most critical needs. Be sure you include more than your computers in this analysis: don’t forget that your backup tapes, your network connections, your terminals, and your documentation are all part of the system and represent potential loss. The safety of your personnel, your corporate site, and your reputation are also very important and should be included in your plans.

57 Although we are unaware of any cases having been filed yet on these grounds, several lawyers have told us that they are waiting for their clients to request such an action. Several believe this to be a viable course of action.