© 1997 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Chapter 9

Setting Up a Firewall Security Policy

To talk about security policy we must talk about risks. As it is the antithesis of security, we naturally strive to eliminate risk. As worthy as that goal is, however, we learn with each experience that complete elimination is never possible. Even if it were possible to eliminate all risk, the cost of achieving that total risk avoidance would have to be compared against the cost of the possible losses resulting from having accepted rather than having eliminating risk. The results of such an analysis could include pragmatic decisions as to whether achieving risk avoidance at such cost was reasonable. Applying reason in choosing how much risk we can accept and, hence, how much security we can afford is risk management.

Did you ever heard about "security through obscurity"? Although it is not as evident within many organizations (it is obscure!), this security practice used to be very common, and it is still around.

Security through obscurity defines a security system that promotes security by isolating information about the system it is protecting from anyone outside the implementation team. This includes but is not limited to hidden passwords in binary files or scripts in the assumption that no one will ever find it.

Are you running your internal network and are planning to run your firewall based on such a system? Better not! It certainly worked back there with proprietary and centralized systems, back in the "glass walls" age. But today, with the advent of open systems, internetworking, and great development of intelligent applications and applets, security policies needs to be taken a step higher.

To run your site based on hidden information, rather than protected information, is to play with fire (without the wall!). Nowadays, users are more knowledgeable about the systems they are running and the technology surrounding them. To keep information unknown is just a matter of time until it becomes well known. To base security on it is useless.

Hackers are proud to prove that. They were the first ones to prove that obscurity, rather than security, is exciting. Consequently, you will need a system that is genuinely secure. True, it can still be broken, but by been structured you will be dealing with a organized method, where you can have tools to increase security, monitor threats, catch intruders, or even pursuit them.

You must keep your firewall (and protected network!) logically secure. Logic should be your starting criteria in putting together a security policy that will use algorithmically secure systems such as Kerberos, PGP and many others.

All right, you already know that your site must be secured and also know what needs to be protected. But what makes a site insecure in the first place? Truly? It is the fact that you turned it on!

Your site will be as secure as the people you allow, or invite, to access it. You can have a very secure site where only corporate users have access to it and you have enough information about each one of them (should you need to track them down later!). So lets assess your corporate security…

It is useful in thinking about risk management to use a sort of formula. This is not, of course, a mathematical equation for use in making quantitative determinations of risk level. It is an algorithm for use in thinking about the factors that enter into risk management and in assessing the qualitative level of danger posed in a given situation.

Reliability and the steps necessary to allow for and deal with reliability failures are risk management issues you must take into consideration. In information systems security, the word "threat" describes a more limited component of risk. For these purposes, threats are posed by organizations or individuals who both intend us harm and have the capability to accomplish their intentions.

In order to develop a thorough security policy, you must consider the possible consequences of attacks from a wide variety of different threats, each of which may act on a specific vulnerability different from those attempted to be exploited by other independent threats and any of which may be unrecognized. Often threats to information and information systems are paired with a specific line of attack or set of vulnerabilities - since a threat which has no vulnerability it is capable of exploiting creates no risk, it is useful to deal with threat-vulnerability pairings in the risk management process.

This uncertainty is a contributing cause of our tendency to rely on risk avoidance. By assuming the threat to be capable, intent, and competent, by valuing our potential targets highly, and by conservatively estimating uncertainties, we reduce risk management to: "what are our vulnerabilities and how much do countermeasures cost to eliminate them?" The management problem is, "How much money can I spend and where can I spend it most wisely?" In most cases, fortunately, it is possible to do better. It is often sufficient to bound the problem, even when exact figures are not available. By careful analysis, we may be able estimate the value of each factor in our equation and balance the risk of loss or damage against the costs of countermeasures and select a mix that provides adequate protection without excessive cost.

Ultimately, the risk management process is about making decisions. The impact of a successful attack and the level of risk that is acceptable in any given situation are fundamentally policy decisions. The threat is whatever it is and while it may be abated, controlled or subdued by appropriate countermeasures, it is beyond the direct control of the security process. The process must focus, accordingly, on vulnerabilities and countermeasures. Vulnerabilities are design issues and must be addressed during the design, development, fabrication and implementation of our facilities, equipment, systems and networks. Although the distinction is not always certain, countermeasures are less characteristics of our systems than of their environments and the ways in which we use them. Typically, to make any asset less vulnerable raises its cost, not just in the design and development phase but also due to more extensive validation and testing to ensure the functionality and utility of security features, and in the application of countermeasures during the operation and maintenance phase as well.

Your basic security requirement should be to minimize, if not eliminate, all the security holes existent in your site. This security holes usually are presented in four ways:

1. Physical - Caused by unauthorized people accessing the site, enabling them to peruse where they are not supposed to. A good example of this would be a browser placed into a public place (reception area, for example), giving an user the chance not only to browse the Web, but also change the browser’s configuration, get site’s information such as IP addresses, DNS entries, etc.
2. Software - Caused by "buggy privileged" applications such as daemons, for example, executing functions they were not supposed to. As a rule of thumb, never trust scripts and applets! When using them make sure you understand what they are supposed to do (and what they are not!).
3. Incompatibility Issues - Caused by bad system’s integration planning. A hardware or software may work great alone but once you put it together with other devices, as a system, it may present you problems. This kind of problems are very hard to spot once the parts are integrated into the system. So make sure to test every component before integrating it into your system.
4. Lack of a security policy - It does not matter how secure your password authentication mechanism is if your users use their kids names as their passwords. You must have a security policy addressing all the security requirements for your site as well as covering, and preventing, all the possible security roles.

The requirements to run a secure firewall also includes a series of "good habits" that you, as administrator should cultivate. It is a good policy to try to keep you strategies simple. It is easier to maintain, as well as to be modified, if necessary.

Most bastion hosts and firewall applications, as mentioned earlier, have the capability to generate traffic logs. Users are at the mercy of these servers, especially Web servers, when information about themselves, their connections, their address or even specifications about their client or company are disclosed. The log provided by a Web server can be threatening for an user as it disclose a list of information, which usually includes:

• The IP address,
• The server/host name,
• The time of the download,
• The user’s name (if known by user authentication or, with UNIX, obtained by the identd protocol),
• The URL requested,
• The data variables submitted through forms users usually fill out during their session,
• The status of the request, and
• The size of the data transmitted.

A fundamental problem of developing a security policy then, is to link the choice of design characteristics which reduce vulnerabilities and of countermeasures to threat and impact in order to create a cost-effective balance which achieves an acceptable level of risk. Such a process might work as follows:

1. Assess the impact of loss of or damage to the potential target. While the impact of the loss of a family member as a parent is beyond measure, the economic value of the member as a wage earner can be estimated as part of the process of deciding the amount of life insurance to purchase, correct? The same model should be used in assessing the impact of loss or damage of a particular network resource of information. Table 9.1 was extracted from my book "Protecting Your Web Site With Firewalls," which economic impact of crime or destruction by fires in a city can be determined as part of the process of sizing police and fire departments. The impact of loss of a technological lead on battlefield effectiveness can be specified.
2. Not all impacts are economic. The loss of privacy or integrity of an user is an example of it!
3. Specify the level of risk of damage or destruction that is acceptable. This may well be the most difficult part of the process. Check Table 9.1 as your boiler-plate.
4. Identify and characterize the threat. The damage that can be caused by criminal behavior can be described and predicted.
5. Analyze vulnerabilities. Your computer systems and networks can be designed to be less vulnerable to hacker attacks. Where potential improvements that may reduce vulnerabilities are identified, the cost of their implementation must be estimated.
6. Specify countermeasures. Where vulnerabilities are inherent or cost too much to eliminate during the design and development of your security policy, countermeasures must be selected to reduce risk to an acceptable level. Access to servers can be controlled. Use of computers and networks can be monitored or audited. Personnel can be vetted to various degrees. Not all available countermeasures need be used if some lesser mix will reduce risk to an acceptable level. Costs of each type of countermeasure must be estimated in order to determine the most cost-effective mix.
7. Expect and allow for uncertainties. None of the factors in the risk management equation is absolute. No threat is infinitely capable and always lucky. No system is without vulnerability. No countermeasure is completely effective. Risk management requires the realistic assessment of uncertainties, erring on neither conservative nor optimistic sides.
8. Keep in mind that in practice, the estimations needed in applying such a risk management process are accomplished in only gross terms. Threat level or uncertainty may be assessed as high or low. Impact may be designated as severe or moderate. This gross quantification of factors in the risk management equation allows the design attributes used to reduce vulnerabilities and the countermeasures to be grouped so that they can be applied consistently throughout large organizations.

Table 9.1 provides a matrix to assess the level of security you may need to implement, based on the level of concern with the information to be protected and the potential consequences in case of breach of confidentiality.

Data Security

Remember! Bastion hosts and servers alike for that matter, are dull! They are obedient, and will do what you ask them to do, but unfortunately, they are dull! Since they will not think on they own, they don’t know the difference between the firewall administrator and a hacker (well, we probably wouldn’t know either!). Anything placed into the bastion host’s document root directory is exposed and unprotected if you don’t find a way to protect it.

Bastion hosts that are loaded with a whole bunch of optional features and services are specially prone to data security risks, especially if your bastion host is also your Web server! Many of the features of a Web server that adds convenience and user-friendliness are more susceptible to security flaws. Unfortunately, most of the Web servers software available in the market do not provide any kind of proxy support.

However, according to a multi-platform Web servers comparative review article, written by Jim Rapoza, for PCWEEK (April 1, 1996), from the six Web servers he reviewed, only two had proxy support. They were IBM’s Internet Connection Secure Server for OS/2 Warp 1.1 and Process Software Corp.’s Purveyor Webserver for NetWare 1.0, where Purveyor was rated as having an "excellent" proxy support and Internet Connection a "good" one.

Both products have a very easy interface for setting up proxies, which should be a must feature for your Web site. These products even allow you to cache specific Uniform Resource Locators (URL) and redirect them to other proxy servers, which is a great security feature. Purveyor even allows you to block an internal user to access non-business related Web sites or controversial ones. I am sure you don’t want upper management blaming you for allowing employees to spend chunks of the time they should be working accessing Playboy, Penthouse or neonazism sites!

Nevertheless, when choosing a Web server software, have data security in mind, and site security as well! Make sure they have solid access security options. You should be able to set users access parameters and block access to the site based on the IP address or domain name of the client.

Proxy support will help you to prevent attacks or unwanted visitors, enhancing data security. It also will help you to cope with the holes generally opened by dangerous features present in so many Web server software. Another important aspect to consider is the underlying operation system. The operating system underlying the Web server is a vital aspect in determining how safe the server is against hackers attack.

The inherent openness of a UNIX systems, for example, will bring extra work for you when trying to block access to hackers. Conversely, a Mac-based system is a much more secure system as it does not as open as UNIX. Servers running Windows NT, or even Windows 95 or Novell have a good built-in security. One of Windows NT advantage is that it supports a large variety of Web server software, which allows you to tailor your server’s configuration.

Besides the operating system, you should be careful with the features each operating system, combined with Web servers had to offer. There are potentially dangerous ones that you should turn off, specially if you do not need them. The following is a list of features that you should pay special attention:

• Automatic directory listings - The more a hacker knows about your system the more chance for you to be tampered. Of course, automatic directory listing can be very convenient, but hackers can have access to sensitive information through them. For example:
• Emacs backup files containing CGI scripts,
• Control logs,
• Directories with temporary files, etc.

• Symbolic links following - There are servers that allow you to extend the document tree with symbolic links. Although convenient, it can become dangerous if the link is created to a sensitive area such as /etc.
• Server side includes - One of the major security hole is the "exec" form of server side includes. It should be turned off completely or made available only to trusted users. Apache and NCSA allows you to turn it off by entering the statement in the directory control section of access.conf: Options IncludesNoExec
• User-maintained directories - Although it might be useful to allow users to maintain directories at the server, or even to add documents to the Web site, you must trust the users. It would be useful to have all the their publishing files and CGI scripts directly maintained by their authors, but it could create major security holes. You will be better off to give the authors their own space and move them when necessary.

Another way to protect data is through the use of SSL, which uses a public-key encryption to exchange a session key --used to encrypt the http transaction-- between the client and server. Since each transaction uses a different session key, even if a hacker decrypts the transaction, the server’s secret key will still be protected.

Netscape servers and browsers do encryption using either a 40-bit secret key or a 128-bit secret key. However, most Netscape users have browsers that support only 40-bit secret keys, due to government restrictions about software that can be exported, but this policy had been modified since the 40-bit secret key was cracked.

If you have an FTP daemon, overall you will not be compromising data security by sharing directories between this daemon and your Web daemon. However, no remote user should be able to upload files that can later be read or executed by your Web daemon. Otherwise, a hacker could, for example, upload a CGI script to your ftp site and then use his browser to request the newly uploaded file from your Web server, which could execute the script, totally by-passing security! Therefore, limit ftp uploads to a directory that cannot be read by any user.

Understanding and Estimating the Threat

That there is real danger to information assets and systems is beyond question. No one who reads the newspapers or pays attention to the other journalistic media can have missed such stories as the denial of service attacks against the Internet (November 2, 1988). Or noted the net attack on Citibank that allegedly resulted in US$ 2.8 million in illicit funds transfers, although Citibank claims that only about US$ 400,000 was not recovered (Reuters, August 18, 1995). Or read Cliff Stoll's fascinating description in his book The Cuckoo's Egg (1989) of the tracking and capture of German hackers funded by the KGB to break into United States Government computers.

Consider the problem of computer viruses. It is estimated (by the National Computer Security Association in 1996) that there are some 8,000 or more viruses in circulation and that 71 percent of all corporate networks have been or are infected (Communications Week, September 18, 1995). Viruses are so pervasive that they have been detected in shrink-wrapped software shipped directly from the manufacturer. New ones crop up at a rate that exceeds twenty per week. The question is not so much "Will you get a virus?" as "When will you get a virus?" But so what? Why not just get an anti-virus software package?

Viruses are just programs, of course, and so can be detected by looking for characteristic sequences of instructions that comprise either the part of the program that makes copies and sends them along to spread the infection or the part that does the dirty work - the payload - that displays an annoying message or destroys your data. And therein lies a problem. The anti-viral software has to have been taught to recognize the instruction string, or "signature," of the virus in order to be able to detect it. A new virus will not be detected at all unless, as occasionally happens, the programmer just used an old virus and changed the payload. That's what happened when the "Stoned Virus" that displayed a message recommending legalization of marijuana was mutated into "Michaelangelo" that destroys data on March 6th, the painter's birthday. Of course, anti-viral software can be updated as new viruses or new versions of old viruses are discovered, but it's always a game of catch-up ball, and even those who take care to upgrade often will not be completely safe.

Moreover, the programmers who create viruses, keep up with the state of the art in anti-viral software, and constantly improve their malicious technology. We are now seeing viruses that are encrypted to escape detection. Other viruses use compression technology to make transmission easier and recognition more difficult.

Since the order in which instructions are executed can sometimes be changed without changing the ultimate result, as when two processes are independent and either can run first, the order of the instructions in a virus may be changed and thereby invalidate the anti-viral software. Or NULOPS, instructions to the computer to do nothing for a clock cycle, might be inserted at random points, mutating the sequence of instructions for which the anti-viral software seeks. Such changes result in viruses that are called "polymorphic" because they constantly change the structural characteristics that would have facilitated their detection. And lately, we have begun to see foxy viruses that recognize that anti-viral software is a work, watch as sectors of the storage device are cleared, and copy themselves over to previously cleared sectors, in effect leaping over the anti-viral bloodhound. Thus, while anti virus packages are a valuable, even essential, part of a sound information security program, they are not in and of themselves sufficient. Good backup procedures and sound policies designed to reduce the likelihood of a virus attack are also necessary.

Sound security policies, practices and procedures like those discussed in this chapter can reduce the risk they represent to a manageable level. Much more dangerous are the risks posed by directed threats, capable and willing adversaries who target the confidentiality, integrity and availability of our information assets and systems.

Outside Threats

Hackers have received a great deal of attention in the press and in the entertainment media. They comprise an interesting subculture, technically astute and talented even if socially and morally deprived. They have been pictured as nerd teenagers who stay up all night eating pizza, drinking sodas as they crouch over their computers, monitors reflecting off of their bottle-thick eyeglasses, and try command after command until they get through their school's computer security so they can improve their grade point average.

If this representation was ever accurate, it certainly is not so today. Today's cyberpunks may mostly be yesterday's juvenile cyberdelinquents grown older, but they tend to be in their twenties and even thirties, although the occasional teenager is still arrested for hacking. To the extent that hackers have a coherent philosophy, it centers around the quaint notion that, "Information wants to be free." The hacker philosophy is libertarian, and technocentric. Access to computers and information, they believe, should be unlimited and hackers should be judged solely by their computer and network skills, not by archaic laws and ethics the evolution of which have not kept pace with the revolution in technology.

When outside hackers have the resources of a large company or a government behind them, they become even more dangerous. Large companies and governments can afford to apply resources to cracking our systems and networks that individuals would have trouble marshaling, including off-the-shelf equipment like supercomputers or arrays of general purpose computers or such special purpose devices as Field Programmable Gate Arrays. Boards are readily available with FPGA chips that can test 30 million DES keys per second at a cost about ten percent of the cost of a PC. For companies and governments, investments in custom-made special purpose chips are feasible that accelerate calculations and make the cost per solution much lower. For an investment easily within reach of a large company or a small government, 200 million DES keys could be tested per second using Application-Specific Integrated Circuits.

Such resources change the difficulty of brute-force attacks on passwords and other access controls from practically impossible to merely time consuming, and with enough resources to trivial. Using an FPGA chip at an investment of a few hundred dollars, a 40-bit key (the maximum size for which export approval can easily be obtained) could be recovered in an average time of about five hours. An investment of a few tens of thousands of dollars could reduce the time to break a 40-bit key to a few minutes. A few hundred thousand dollars would buy the capability to break a 40-bit key in a few seconds, and a few million dollars would reduce the time to less than one second. Custom chips could easily be designed for a few million dollars that would permit 40-bit key recovery in a few thousandths of a second.

DES keys of 56-bits are more secure, of course, than 40-bit keys, but an investment of a few hundred thousand dollars could yield DES keys in a few hours and an investment of a few million dollars would reduce recovery time to minutes.

Inside Threat

Where high-quality information systems security mediates information transactions across the boundary that separates an organization's systems and networks from the lawless Cyberspace outside and protects the confidentiality, integrity and availability of the organization's information assets and systems, it may be easier and cheaper to subvert or suborn an employee than to mount a direct attack. Or the attacker may seek employment and the authorized access that follows in order to better position himself to mount a wider attack that exceeds the access that has been granted as a condition of employment.

Our defenses are mostly directed outward. Few systems have a plethora of internal firewalls mediating information transactions within the organization. Many systems provide the capability to monitor and audit information transactions, even those totally within the system.

But looking for an insider abusing privilege among the vast number of transactions taking place routinely on the system is a daunting task, and impossible without computer-based audit reduction and analysis techniques. So most of our problem lies inside. Techniques are described in later chapters for abating the resulting risks include good use of computer science and cryptography to protect information assets and systems, monitoring and auditing to detect intrusions from without or abuses by insiders, and an effective capability to react to security relevant incidents, correct problems and resume safe operations. But effective and efficient security begins with and depends upon having the proper security policies in place.

A Word About Security Holes

Security holes can be one of the major threats your security policy should cover, especially because many of them are not stopped by the use of a firewall. The following is a list of the four types of security holes threatening the security of your network and company’s assets:

• Physical Security Holes - Caused by giving unauthorized persons physical access to the machine, where this might allow them to perform things that they shouldn't be able to do.
• Software Security Holes - Caused by a bug in the application’s code, or "privileged" software, which can be compromised into doing things which they shouldn't. The most famous example of this is the "sendmail debug" hole which would enable a cracker to bootstrap a "root" shell. This could be used to delete your filestore, create a new account, copy your password file, anything.

Security holes are hard to predict, spot and eliminate. The following is a small list of suggestions on how to avoid or be prepared for them:

• If you’re running an UNIX server, try to structure your system so that as little software as possible runs with root/daemon/bin privileges, and that which does is known to be robust.
• Subscribe to a mailing list which can get details of problems and/or fixes out to you as quickly as possible, and then make sure to run all the patches that becomes available, as soon as they become available.
• Don’t install or upgrade any system or service, unless you’re sure you need it. Otherwise, you may be loading something for a hacker to use. Many packages include daemons or utilities which can reveal information to outsiders. For instance, AT&T System V Unix' accounting package includes acctcom, which will, by default, allow any user to review the daily accounting data for any other user. Also, several TCP/IP packages automatically install/run programs such as rwhod, fingerd, and tftpd, all of which can present security problems.
• Don’t trust installation scripts. Many of them tend to install/run everything in the package without asking you. Thus, check the list of programs included in the package before beginning to install it.
• Watch for security holes generated by incompatible usage of hardware and software. Many times, due to lack of experience, an administrator can install a software in a hardware where compatibility issues exists, which is capable of generating serious security flaws. It is the incompatibility of trying to do two unconnected but useful things which creates the security hole. Problems like this are very difficult to detect once a system is set up and running, so it is better to build your system with them in mind.
• Choosing a suitable security philosophy and maintaining it.

As Gene Spafford (spaf@cs.purdue.edu) commented on the USENET once, there is a "fourth kind of security problem [which] is one of perception and understanding. Perfect software, protected hardware, and compatible components don't work unless you have selected an appropriate security policy and turned on the parts of your system that enforce it." And he continues… "having the best password mechanism in the world is worthless if your users think that their login name backwards is a good password! Security is relative to a policy (or set of policies) and the operation of a system in conformance with that policy."

To find security holes, and identifying design weaknesses it is necessary to understand the system control structure, and layers. In order to do that, you should always try to:

• Determine the items to be protected, or security objects, such as users file.
• Identify your control objects, or the items that will protect security objects.
• Detect potential holes in a system. These holes can often be found in code that:
• Is ported to a new environment.
• Receives unexpected input.
• Interacts with other local software.
• Accesses system files like passwd, L.sys, etc.
• Reads input from a publicly writable file/directory.
• Diagnostic programs which are typically not user-proofed.
• Test code for unexpected input. Coverage, data flow, and mutation.

I hope all the above gave you an idea of what a security policy should contain. Vulnerabilities are many, Internet attacks as well. There are several countermeasure strategies you can use, but without a guideline, a map, you might find yourself shooting in the dark. That’s when a security policy is necessary. It will become your map, your guideline, your contract (with users and upper management), your "power of attorney" to take the decisions you must take in order to preserve the security of your site.

Setting up a Security Policy

As discussed earlier, an Internet firewall does not stand alone--it is part of the organization's overall security policy, which defines all aspects of its perimeter defense. To be successful, organizations must know what they are protecting. The security policy must be based on a carefully conducted security analysis, risk assessment, and business needs analysis. If an organization does not have a detailed security policy, the most carefully crafted firewall can be circumvented to expose the entire private network to attack.

The following is a template of a typical security policy. Use it as a foundation for your own security policy, add and remove whatever doesn’t apply to you and make sure to have as many inputs as possible from upper management, which should totally support it.

A Security Policy Template

<Your Company> INTERNET SECURITY POLICY

This regulation establishes minimum security requirements for the use of the Internet network by <Your Company>. This regulation is not written to restrict the use of Internet, but to ensure that adequate protection is in place to protect <Your Company> data from intruders, file tampering, break in, and service disruption.

In the late 1960s the Department of Defense (DoD) designed and implemented the ARPAnet network for the exchange of defense industry research information world-wide. TCP/IP was the protocol developed and UNIX was the platform.

The National Science Foundation (NSF) needed a network also to interconnect their supercomputers and exchange academic research information so they built their own, but followed the DoD standards. They called their network NSFNET.

The Internet consists of many, worldwide, independent networks that allow interconnection and transmission of data across the networks because they follow the same basic standards and protocols and agreed upon Internet etiquette, " No central authority." Each user organization pays for its own piece of the network.

Motivated by developments in high-speed networking technology and the National Research and Education Network (NREN) Program, many organizations and individuals are looking at the Internet as a means for expanding their research interests and communications. Consequently, the Internet is now growing faster than any telecommunications system thus far, including the telephone system.

New users of the Internet may fail to realize, however, that their sites could be at risk to intruders who use the Internet as a means for attacking systems and causing various forms of threat. Consequently, new Internet sites are often prime targets for malicious activity including break in, file tampering, and service disruptions. Such activity may be difficult to discover and correct, may be highly embarrassing to the organization, and can be very costly in terms of lost productivity and compromised data integrity.

All Internet users need to be aware of the high potential for threat from the Internet and the steps they should take to secure their sites. Many tools and techniques now exist to provide sites with a higher level of assurance and protection.

<Your Company> branches should acquire a copy of the "Guide to the <Your Company> Internet." This document is published by the MIS department. This guide defines the <Your Company> Internet Access Network. You may acquire this guide by contacting the Director of MIS, at extension XXX.

Definitions relating to this policy may be found in appendix "A".

NIST CSL Bulletin, July 1993, NIST Connecting to the Internet: Security Considerations

<List here any other documents users can refer to in order to better understand this policy>

ARPAnet Advanced Research Projects Agency Network

DMZ Demilitarized Zone

DoD Department of Defense

FTP File Transfer Protocol

LAN Local Area Network

NIST National Institute of Standards and Technology

NSF National Science Foundation

NFS Network File System

NREN National Research and Education Network

OSI Open System Interconnect

TCP/IP Transmission Control Protocol/Internet Protocol

TCP Transmission Control Protocol

The responsibility for protecting <Your Company> resources on the Internet is the responsibility of the <Your Company> or Staff Offices. This policy apply to contractors and universities that connect to <Your Company> computer. <Your Company> branches which access the Internet must develop and implement an Internet security policy which meets the minimum requirements of this regulation as following:

1. Data which is exempted from disclosure under the Freedom of Information Act (Public Law 93-502) or whose disclosure is forbidden by the Privacy Act (Public Law 93-579) will not be transmitted over the Internet network unless encrypted. "Note: Logon IDs and passwords are frequently classified as sensitive information."
2. All <Your Company> branches and staff offices using the Internet must follow the guidance in <any additional documentation>.
3. <Your Company> branches and staff offices that plan a gateway to the Internet are responsible for funding, implementing and maintaining the prescribed protection, including devising, and implementing a comprehensive risk management program.
4. Agencies and staff offices will access the Internet only through the <Your Company> Internet Access Network.
5. Host-based security will be the primary method of protecting <Your Company> systems. However, many host-based security software packages cannot be trusted to protect us from the Internet, because of their vulnerability to denial-of-service attacks.
6. Due to inherent weaknesses in certain Internet telecommunication services, and cumbersome aspects of some security packages, many sites will find that the most practical method of securing access to systems from the Internet is to use a secure gateway or a firewall system. <Your company> branches and departments will perform risk assessments to determine where secure gateways, firewalls, smart cards, or authentication tokens will be most suitable. <Your Company> branches will:

• Use firewalls and/or packet filters on the local routers, when the system uses TCP/IP.
• Configure firewalls on with outgoing access to the Internet, but strictly limit incoming access to <Your Company> data and systems by Internet users.
• Apply the DMZ concept as part of the firewall design.
• Firewall compromise would be potentially disastrous to subnet security. For this reason, branches will, as far as is practical, adhere to the below listed stipulations when configuring and using firewalls.
• Limit firewall accounts to only those absolutely necessary, such as the administrator. If practical, disable network logins.
• Use smartcard or authentication tokens to provide a much higher degree of security than that provided by simple passwords. Challenge-response and one-time password cards are easily integrated with most popular systems.
• Remove compilers, editors, and other program development tools from the firewall system(s) that could enable a cracker to install Trojan horse software or backdoors.
• Do not run any vulnerable protocols on the firewall such as TFTP, NIS, NFS, UUCP.
• Consider disabling finger command. The finger command can be used to leak valuable user information.
• Consider not using the e-mail gateway commands (EXPN and VFRY) which can be used by crackers to probe for user addresses.
• Do not permit loopholes in firewall systems to allow friendly systems or users special entrance access. The firewall should not view any attempt to gain access to the computers behind the firewall as friendly.
• Disable any feature of the firewall that is not needed, including other network access, user shells, applications, and so forth.
• Turn on full-logging at the firewall and read the logs weekly at a minimum.
• No <Your Company> computer or subnet that has connections to the Internet can house privacy or sensitive information without the use of firewalls or some other means to protect the information.
• <Your Company> branches and staff offices must develop and document an Internet security strategy based on the type of Internet service selected for use. This strategy must be included in the Internet Security Plan.
• <Your Company> branches and staff offices that use the Internet must adhere to guidance stated in XXXXX" <Your Company> Internet Security Policy."
• All software available on the Internet must be scanned for Trojan horses or computer viruses once it has been downloaded to a <Your Company> computer.
• All downloaded software should be loaded preferably onto a floppy disk and not to the system hard disk. Once you are reasonably assured that the downloaded software does not contain Trojan horses or computer viruses it can be placed on the hard drive. If the software will not fit on a floppy disk then the only option is the hard disk. The software must be scanned before use (executed).
• Mandatory vulnerability and risk assessment of existing gateways is required at annual intervals. Initial assessment should be completed within nine (9) months of the issuance of this policy. And all branches should also conduct weekly or monthly reviews of audit trails of gateway software and firewalls for breaches of security.
• <Your Company> personnel, and contractor personnel working for <Your Company> while using the Internet:
• Must not be harassing, libelous, or disruptive to others while connected to the Internet.
• Must not transmit personal data or unauthorized company-owned data across the Internet.
• Must obey all copyright laws.
• Must not download to company’s computers from the Internet any obscene written material or pornography.
• Must not send threatening, racially harassing, or sexually harassing messages.
• Must not attempt to break into any computer whether <Your Company>, its clients or private.
• Must not be used for private or personal business, except when authorized.
• Must not introduce computer viruses, worms, or Trojan horses.
• <Your Company> sponsored Internet connections are to be used for official <Your Company> business.
• Host computers should be regularly scanned to ensure compliance with <Your Company> security guidelines.

The Director or MIS :

1. Develop, coordinate, implement, interpret, and maintain Internet Security policies, procedures, and guidelines for the protection of <Your Company> information system resources.
2. Review <Your Company> Internet security policy.
3. Assist in <Your Company’s> branch Internet security policy development and implementation.
4. Determine adequacy of security measures for systems used as gateways to the Internet.
5. Ensure that all <Your Company> branches conduct periodic information systems security risk assessments, security evaluations, and internal control reviews of operational <Your Company> Internet gateways and facilities.

All branches and <Your Company> departments that have or are planning to install a firewall or any sort of gateway to the Internet will:

• Devise and implement a comprehensive risk management program which assures that security risks are identified, considered, and mitigated through the development of cost effective security controls. The risk management system will include a service access policy that will define those services that will be allowed or explicitly denied from the restricted network, how these services will be used, and the conditions for exception to this policy.
• Another part of this risk management system will be a firewall design policy. This policy relates precisely to firewalls and defines the rules used to implement the service access policy.
• Each branch and staff office must develop an Internet Security Plan which address all security controls in place or planned.
• These controls shall be commensurate with the risks identified in the risk analysis. Internet Security plans shall be submitted annually with the <Your Company’s> security plans for review and approval. The guidelines governing the submission of these security plans should comply to the Internet Security Plan.
• Perform risk analysis to identify the risks associated with using Internet both for individual users and branches or departmental offices. Cost effective safeguards, identified in the risk analysis process, will be implemented and continually monitored to ensure continued effectiveness.

<Your Company> MIS department should be responsible for developing, testing, and maintaining Internet contingency plans. The risk involved with using the Internet makes it essential that plans and procedures be prepared and maintained to:

• Minimize the damage and disruption caused by undesirable events; and
• Provide for the continued performance of essential systems functions and services.
• Develop, install, maintain, and regularly review audit trails for unusual system activity.
• Fund, implement, and maintain the prescribed protective features identified as a solution by a risk assessment.
• Risk assessment developed by branches and staff offices are to be made available to MIS upon request.
• Ensure that the branch information security manager is a vital part of any security activity on the Internet.

The information security manager is responsible for:

1. Implementing the policy stated in this directive.
2. Developing audit trails for any <Your Company> network connected to the Internet.
3. Reviewing and monitoring activity audit trails on the Internet connections.
4. Working closely with the branch network administrator in monitoring activity on the use of their host and subnets.

All users of data and systems are responsible for complying with this Internet systems security policy, as well as procedures and practices developed in support of this policy.

Anyone suspecting misuse or attempted misuse of departmental information systems resources is responsible for reporting such activity to their branch or staff Office management, or to the information system security manager or the MIS manager.

Violations of standards, procedures, or practices in support of this policy will be brought to the attention of management for action, which will result in disciplinary action up to and including termination of employment.

1. MIS Guide To The <Your Company> Internet
2. <Whatever documents you want to make available to users>

COMPUTING MCGRAW-HILL | Beta Books | Contact Us | Order Information | Online Catalog

HTML conversions by Mega Space.

This page updated on December 05, 1997 by Webmaster.

Computing McGraw-Hill is an imprint of the McGraw-Hill Professional Book Group.

Copyright ©1997 The McGraw-Hill Companies, Inc. All Rights Reserved.
Any use is subject to the rules stated in the Terms of Use.