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Ö
(c ) Assessing Your Corporate Security Risks
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:
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:
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:
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.
Level of Integrity To Be Implemented
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:
Be aware that by turning off automatic directory listings wonít stop hackers from grabbing files whose names they guess at, but it at least make the process more difficult.
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.
(d ) The Virus Threat
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.
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.
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:
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:
As Gene Spafford (email@example.com) 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:
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:
The Director or MIS :
All branches and <Your Company> departments that have or are planning to install a firewall or any sort of gateway to the Internet will:
<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:
The information security manager is responsible for:
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.
9 SOURCE OF INFORMATION