Any use of this Beta Book is subject to the rules stated in the Terms of Use.
|
|
|
|
| |
| © 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. | |
This chapter discusses what you need to know about firewalls and its implementations. In some ways it complements chapter 7, "What is an Internet/Intranet Firewall After All?," as it goes beyond the basic concepts discussed on that chapter. This chapter reviews the different firewall technologies used today, their strengths and their weaknesses, and the tradeoffs involved when designing a firewall system and implementing it to your specific application and corporate needs.
We discussed on chapter 7 that firewalls helps to protect private networks from unauthorized intruders. But there are many firewalls available on the market, as someone said once, "from the basement-brewed firewalls to the me-too firewalls from the larger manufacturers." Chapter 14, "Types of Firewalls and Products on the Market" gives you an extensive list of all the major firewall vendors, their products and in-depth details and discussion about the product strength, pros and cons. When reviewing those products, keep in mind that the underlying technology used in the firewalls is very important to the security and integrity of the firewalls.
As you already know, unless you skipped chapter 7, which I recommend to get back there, there are currently two main firewall technologies: packet filtering and application level. But we also discussed that depending on the technology employed, firewalls can be classified in four categories:
1. Since hybrid firewalls still rely on packet filtering mechanisms to support certain applications, they still have the same security weaknesses
Before you start selecting a firewall from chapter 14, you should develop a corporate security policy, as discussed on chapter 7, and then select the firewall that can be used to implement the chosen policy. When evaluating firewalls, care must be taken to understand the underlying technology used in the firewall as some firewall technologies are inferior in security to others.
The basic concept of a firewall will always be the same, so you should evaluated a firewall based on the level of security and implementation features it offers. When I say security features I mean the ability a firewall product has to deliver security based and consistent to your corporate security objectives and policy. The following are some of the characteristics you should be looking for in a firewall:
As for implementation features, you should be looking for the ability a product has to satisfy your network management requirements and concerns. A good firewall product should be:
As far as integrated features, look for the ability of an firewall to meet your and users needs, such as:
A security policy is very important when setting up a firewall at your company, as it outlines what assets you consider worth protecting and what actions or risk management procedures you must cover in order to protect your corporate assets.
Network security policies often must integrate security issues from all previous policies. Usually companies seek outside assistance when first creating their network security policy.
The following is a boiler plate for you to use when creating a security policy. Make sure to add or remove any item that don’t apply to your environment:
"Your Company Name" Security Policy
Definition
Reasons for adopting a security policy
Mission statement
How should it be reenforced
Support from upper management
Special circumstances and exceptions to the rule
Need for upper management approval
Objectives and security goals
Definitions
General security policy and procedures:
About the networks
About the Intranet
About the Internet
About the Extranet
About telecommuters
About remote users
About Application use
About hardware use
Of desktops and workstations
Of networks
Of Intranet
Of Internet
Of Extranet
Of applications
Of telecommuters
Of remote users
Viruses
Worms
Applets
Trojan Horses
Security holes
Espionage
For the company
For personnel
For wiring
For networks
For logistics
For Operations
For workstations
For servers
For remote access services
Common goals and mission statement
Specific goals and procedures
Procedures for auditing corporate security
Automatic generation of login reports
Security checklist
Adopted access control mechanisms
Firewall and proxy servers
Security management
Risk management and control
Network security interacts with physical security because the size or shape of the network "machine" or entity can span a building, campus, country or the world due to interconnections and trust relationships. The weakest link in an international network, for example, may be the fact that a serial-line maintenance cable passes over a public restroom at corporate headquarters! Physical security policy may have to be updated, and the physical policy must be taken into account when creating the network policy.
Access control explicitly decides for each packet of network traffic whether or not it is allowed and what action is appropriate. A firewall determines if the packet or session is consistent with it's copy of the security policy.
With a sufficiently powerful policy engine, the firewall can implement fine-grained (and therefore more secure) polices. Good policy engines impose the fewest restrictions on which policies they can implement. Good access control includes managing remote access and enables administrators to provide more or less access to users depending on from where they are working.
Authentication is how users to the network infrastructure who they are. The type of authentication used varies depending on from where users are authenticating. From their desk, a simple user id and password may be sufficient because of the accompanying physical security. When connection to the firewall from the Internet, a token-based authentication may be necessary.
Encryption can ensure data integrity or protect sensitive information sent over insecure lines. Such protection is usually essential for remote access to important company assets or as extra protection when using company Intranet.
A serious issue with encryption is how to manage the "keys." Keys are used to encrypt and decrypt the data. If you have only one or two connections that must be encrypted, then manual key distribution is fine. If you have 100's or 1,000's of keys to distribute, then only automated key management will work. Manual distribution of large numbers of key is too insecure or costly.
Once a security policy has been implemented, it must be periodically checked to ensure that all components and employees are in compliance. Without sufficient auditing, a company may have no legal recourse if there is a security breach. Auditing can also find problems before they turn into security breaches. Auditing and monitoring products are relatively new so many tasks must still be done manually and less frequently than desired.
You must train your users about the information system in place, from the desktop, and applications to the network and access to the Internet. Otherwise they will be one of the most serious threat to your network security. If your users do not understand the power and proper use of your network, then they can unintentionally compromise security. In particular, employees must manage passwords properly and recognize when someone asks them for inappropriate information about the network.
It is very hard for you to detect if your site has been broken-in to. If your site was been broken by a hacker, chances are you would never know! They are very difficult to be detected! If it was broken by a cracker, you may be able to trace it more easily.
Fortunately, for those of you using an UNIX systems, there is a program called "tripwire," that can perform periodical scans in your system to detect if any system files or programs have been modified. But this is not enough to prevent a hacker to invade your system and not every operating system platforms have tools like tripwire.
| Tip: Tripwire is distributed free of charge. If interested in downloading it, try URL: ftp://coast.cs.purdue.edu/pub/COAST/Tripwire/ |
Another quick check you can do is to check your access and error log files for suspicious activity. Look for traces of system commands such as "rm", "login", "/bin/sh" and "Perl."
For those on Windows NT platform, check the Security log in the Event Log periodically, looking for suspicious activities.
Also, hackers usually try to trick a CGI script into invoking a command by entering long, very long lines in URL requests with the purpose to overrun a program’s input buffer. Lastly, look for repeated failed attempts to access a password or section protected by passwords. Overall, these could be an indication that someone is trying to break-in to your site.
Sites are been broken-in to more and more every day. As the technology, specially the Web technology, changes so rapidly, systems become obsolete or vulnerable to new threads very quickly. Even the most protected system can become vulnerable by a creation of a new Java applet not predicted into its present security system.
Web server running operating systems (OS) such as SunOS and UNIX, which are based on the client/server abstraction are particularly sensitive to these moving Internet technology trends. As they usually are developed to model the network as an extension of its internal data bus, which also extends a series of features hardly found in other OS platforms, these same extensions opens a door (if not many!) to hacker and intruders.
But opening a door for potential hackers is only the index of the whole Bible! There is much more to it when come to intrusion detection.
Nowadays, hackers are very aware of the typical security models utilized by MIS and deployed all over the Internet. As a matter of fact, they use it for they own interest. Password systems, access and authentication systems are not sufficient to guarantee the security of a protected network.
Hackers can write simple applets to act as Network File System (NFS) clients, for instance, and bypass all the access control system normally used, gaining total access to internal networks or users files. But this is not merely a security hole of NFS, it extends to almost every network service available.
When comes to secure your site, you must rely and apply every resource you can to guarantee the safety of your site and users. Firewalls and proxy server, as you saw on chapter 10, will not totally resolve the problem, but they will greatly enhance your chances of survival.
Once you have done everything you can to protect your site, from hardware to software, from security policy to its implementation, the only thing you can do is to accept the odds and wait for the day that you may need to face an incident. I hope you never will, but if you do, you must be prepared to deal with the incident, from the systems perspective, to the legal one.
Our battle in protecting our site and protected network system can be compared with the same battle we go through in protecting our own bodies. In order to prevent from a virus disease we must isolate it, analyze it, observe it, learn from it, so that we can reverse its vital conditions and hopefully exterminate it.
The same is true with computer security. We must be able to isolate our attackers, analyze it, observe it and learn from it as well. Unfortunately, not much is discussed about the hacker, the intruder, the attacker. Much description goes for the symptoms that evidences its presence and the devastating consequences of its attacks.
Just like with viruses, no one really knows much about the hackers, only about the signs of their presence. The good news is that this hacker do have forms. Most of them are usually male, computer science students. Of course, all of them have access to the Internet and know very well the UNIX environment.
We could move on and ask ourselves why the hacker do what they do. But it would be out of the scope of this book, so lets just say, I hacker likes to challenge himself and the majority of the times he will break into a system, just for the challenge of been able to do so.
A hacker, like a bug (or virus), usually follows a standard pattern to break into a site. Usually he tries to:
Many times these usernames are composed of the last name and first initial or a combination of both. Even if a username is not so obvious, it is easy to obtain through finger and ruser.
However, the password is not something so easy to break if users choose them with at least 12 to 15 characters, and they are not found on any dictionary. There are too many combinations to be tried, and even if a hacker is to use password cracking tools (see Appendix H), it is too much time consuming and not guaranteed to work in a timely fashion. At least, it will demand patience and a lot of time. Further, with Windows NT and the majority of the operating systems, the machine will disconnect after the third or fifth attempt to enter a correct password anyway. That is why a hacker will usually rely on network services such as NIS, RLOGIN/RSH, NFS. More will be discussed about it ahead.
There are several services that can be used as cracking tools as well. The following is a selection of some of them, which you should be careful when making them available and using them.
The network information service (NIS) can be very useful for a hacker as it provides a database service of multiple clients and replicated servers. This service stores various information such as password files, group files, and the like. Only clients with the NIS domain name have access to it, as a way to protect it, since it holds sensitive information.
Unfortunately, by default installation, usually the NIS domain is also the DNS domain name for the site, or something very similar. Once a hacker gets access to it a get a copy of the password file, he only needs to run one of the many password cracker applications (some listed on Appendix H) to gain access to the system.
This is very practical with UNIX-based systems, but not so with Windows NT, Macintosh and other platforms. However, as I write this book couple password cracking systems were released for Windows NT.
In trying to resolve this problem, shadow passwords can be used. This consists of two databases, the actual password file, available for privileged users and another one available to everyone. It makes it harder to break in but not impossible as a shadow file can still be read by anyone as long as they make the request from a privileged port.
The remote login service provides a remote terminal service so that users can access the network remotely as if they were directly attached to it. It is much the same of the Remote Access Service (RAS) for Windows NT and Windows 95. The authentication in these services is done by entering the username and the password, as well as the domain name.
The problem is that many times, in the attempt to ease the operation for the users, the domain name and password is giving automatically. The user only needs to enter his/her password.
Also, the user usually has an option to have the password remembered by the system next time he/she logs in so it doesn’t have to be entered! The remote shell service, a related service, allows anyone already authenticated into the system to log in onto trusted domains and execute commands on those domains. This service uses the same authentication mechanism as the login service; for this reason the two services are discussed here as one. If not monitored very closely, remote access sessions can also be a major threat to the system, as very often it even by-passes any installed firewall.
When used wisely these trust mechanisms are very valuable. Users don’t have to type their password every time they log into a trusted machine and remote commands can be executed without logging in first. The bad decision here is to let the user decide who to trust and who not to trust! For example, if in a .rhosts file the user Mario trusts the user Lourdes and in turn Lourdes trust the user Marcio and Marcio trusts the user Celia, Celia can become Lourdes through the trusting relationship. If any oth this accounts are broken in to, all the other ones become exposed as well.
Sun’s Network File System (NFS) is one of the most important and vulnerable network service in the system, as it provides full access to files and directories. The major security hole is that NFS’s access control mechanisms are very hard to maintain, and are hardly adequate. Another hole is that it doesn’t have user authentication, even when using the so-called secure NFS implementation.
Every user can write his own NFS client, specify any identity and read or write files. An NFS client that provides this basic functionality can easily be written in about 300 lines of C code. The secure NFS tries to fix this security hole but it doesn’t totally succeeds. The problem is that the underlying cryptosystem doesn’t work, and can be broken very easily.
File handles also used to (it has been fixed!) represents a major vulnerability. They can be constructed without the help of the mount daemon, which allows a client to directly go to the NFS daemon, and bypass the access control mechanisms which are enforced by the mount daemon.
The File Transfer Protocol (FTP) service allows clients to copy files from one machine to another. It resembles NFS in a way, but is intended for long haul networks. Clients normally need to be authenticated.
Nevertheless, FTP implementation has been well known for its security holes. Over time, FTP has become a very complex and difficult system to understand as features were added. For instance, a major security hole of this system is that it can be tricked to give a hacker the permissions of a determined user, while the hacker actually logs in using a public account. These bugs have all been fixed, but FTP services became so broad that I recommend you to watch it very closely.
That is why it is so important to keep your eyes on the directory permissions of an FTP server. Once a hacker is in, the first thing he will check is if he can write do that directory. If so, he will probably put a .rhosts file into it containing his name and his current machine. Since the directory is often the home directory of the user ftp (or ftpd), a simple remote login sufficed to get into the system!
There are several other security risks with FTP, which is not the scope of this book to get into it. The purpose here is to show you the many open doors present in your system, even with a firewall in place.
Just like a virus, a hacker goes to a period of "incubation." Once he breaks into a system, he starts to consolidate his position, which I call the incubation stage. Usually it is done by simply placing a .rhosts file in the home directory of a cracked account. There are other methods, but this is usually very effective.
Besides consolidating his presence in this new "body," a hacker is also interested on what is there for him: mailboxes, user’s information, etc. Once inside, a hacker will not waste time in consolidating his position there. Usually he will target applications that require passwords, such as TELNET and FTP.
Therefore, it is important that you try spot a hacker as soon as you can, possibly before he consolidates his presence within your system. The following is a shell script sample for spotting a hacker. You can base on it to tailor your own, depending on the system you are trying to protect:
#!/bin/sh
LOGFILE=logfile
while true; do
case 'date | cut -d" " -f5 | cut -d: -f1' in
(18|19|20|21|22|23|00|01|02|03|04|05|06|07)
(echo "======= "; date) >> $LOGFILE
(echo "who"; who) >> $LOGFILE
(echo "ps axl"; ps axl) >> $LOGFILE
(echo "netstat -n"; netstat -n) >> $LOGFILE
sleep 600
;;
*)
sleep 3600
;;
esac
done
I hope you will never have a break in at your site. But unfortunately, chances are that you will. So if you ever need to respond to a security incident there are some steps worth following. Although you don’t need to follow this steps in order, and maybe some of them not even apply to your situation, you should at least review them as it will help you to get control of the situation sooner, than later.
Borrowing Garfinkel’s rules for incident response, make sure you:
Many times, in face of a hacker’s attack, there is not much you can do other than feel sorry about what happened to your site and/or users. Other times, you might be able to even stop a hacker from going any further! So your steps, in case of an incident should be:
The first initiative you should make when a break in is confirmed should be to assess the damages, the seriousness of the break in as soon as possible. For instance, there was a time I used to be directly involved with computer security incidents. I used to have a white board at my office for situations like that. In every situation, I would start assessing the incident by writing down few questions on the board:
Once you assessed the situation, you should be in the position to start making some decision, taking some actions. At least short term ones. The first one should be to cut off the link. What that means will depend on your environment. Go back to your white board, take a look at the notes already there and based on it put some more down:
Now it is time to go back to your white board, add up all the information you wrote there, subtract the hyper reactions the followed the realization you have been hit and come up with the results. At this point, you must have a plan.
Take your time. The worse is over, your system is probably already down, and surely, you will learn something new today! Make sure to think thoroughly about the actions you are about to take. Evidently, at this point you already identified the security hole and will be fixing it. Make sure your fix won’t create another security hole or will affect other services or processes. Will your approach resolve the problem?
Once you have the whole plan ready, bounce it off someone else you trust. Try someone out of the picture, not affected by the same bias you may are.
It is time to implement your emergence response plan. Make sure upper management, users and service providers are aware of the incident.
You don’t need to give them much information, especially the technical ones, but should give them a reasonable timeframe for the restoration of the system.
Notify CERT, exchange your information with them. Not only you will be helping them to alert others about it but they might be able to help you with their expertise.
Finally, repair the security hole and restore the system. Make sure to document the whole incident, learn from it and archive it.
It is very difficult to catch intruders. Especially when they try to cover up their tracks. Chances are that if you are able to spot a hacker attack, it will be by accident! Very unlikely intentional.
However, even though you will need a lot of luck to spot a hacker in your system, there are some guidelines that you can follow to help you to be more lucky:
There is so much that should be discussed when reviewing security. Many books were written about it. Associations and task forces were created for that purpose.
The following is a summary list of security issues you should review. It is not a complete list, of course, but it does try to address some of the main issues affecting your Web environment. At the end of this book you will find some complementary bibliography references do complement this information:
As you can see, there are few things you can do to prevent break-ins. As more control you have over your system, more will be your alternatives to prevent it and even to try to catch an intruder... as far as system’s at least. Legally speaking, unfortunately there is not much you can do yet. The legal system in U.S. is trying to move fast, but not fast enough, one may say.
Computer security law is a new field, not yet established in the realms of law. The meaning of most technical computer terms are still a bit foreign or unclear in the courtrooms.
The legal establishment had yet to reach broad agreement on many key issues. Even the meaning of such basic terms as "data" can be the subject of contention.
Computer security law is still moving very slow, and if it moves, it is mostly due to litigation coming to court and making attorneys and judges very much reluctant due to their lack of knowledge and understanding of technical terms and security issues.
But the American Bar Association has already a full plate as computer security law and public policy needs to be developed. Needless to say, the legal perspective in pursuing a hacker is not in a solid ground yet, but the government and ABA acknowledges it and are working to resolve the issue.
The American Bar Association’s (ABA) Science and Technology Section is responding to the control, legal and security issues associated with the Electronic Data Interchange (EDI) and the electronic commerce information technologies.
The Section has specialty committees in several areas under the Electronic Commerce and Information Technology Division:
| Note: If you would like to have more information about ABA’s Science and Technology Section (STS) and its Committees, you can check the URL: http:// http://www.intermarket.com/ecl/ |
Back in 1990 the government began a nationwide campaign to crackdown on illicit computer hackers. There were several arrests, criminal charges, and even a dramatic show-trial, with several guilty pleas, and confiscation of data and equipment all over the country.
The U.S. Secret Service joined forces with state and local law enforcement groups throughout the nation to try to put a stop on the "computer underground" community, the hackers and crackers community. It was a showdown! There is even a book reviving those moments, The Hacker Crackdown, by Bruce Sterling (bruces@well.sf.ca.us).
| Tip: If you want to know more about this crackdown, check Bruce’s electronic version of the book at URL: http://homepage.eznet.net/~frac/crack.html |
The FBI’s National Computer Crime Squad is dedicated to detecting and preventing all types of computer-related crimes. When an incident is detected, the tendency is to overreact, and many times, based on the legal infrastructure do deal with the issue, that is what ends up happening.
Network intrusions, for instance, have been made illegal by the U.S. federal government, but detection and enforcement are very difficult. The law, as it presents when facing computer crimes, is very much limited in essence and scope. It does not take much to realize it when you take the criminal case of Kevin Mitnick’s, aka the Condor, when recently pleating bargain. His final plea and the crimes he allegedly committed had very little connection to each other.
| Note: If you are not familiar with Kevin Mitnick’s case, he was arrested back in February of 1995 for for allegedly breaking into the home computer of Tsutomu Shimomura, a respected member of the computer security world. Kevin, also known as "Condor," was suspected of spoofing Tsutomu’s computer and stealing computer security tools to distribute over the Internet. By the beginning of July, the federal prosecutors and Kevin’s lawyers had reached a plea bargain agreement whereby Kevin would admit the charges of "possessing unauthorized access devices" in exchange of the prosecutors dropping 22 charges brought against him. According to the sentence guidelines, Kevin’s admitting he was guilty would carry a maximum prison sentence of eight months. |
The fact is that corporations and governments alike, love to spy on the enemy. The Web is providing new opportunities for this. Wired Magazine (June of 1996), commented that more and more the American people are watching less television at night to spend an average of 11 hours in front of a computer screen. Mostly likely on the Web!
Hackers-for-hire became a trend. Somewhat, an idol. I had the chance, while writing this book, to talk to some of them, and what I found out is that there is a status quo in been a hacker. Just check the magazine and newspaper articles about them, it is always catching, vibrating. Crackers are living to become hackers, and hackers and law enforcement agents are re-living the tale (tale?).
Tracing hackers and crackers is a very labor-intensive, specially the first. Convictions are hard to be reached, as the laws are not written with electronic theft in mind.
For instance, how would you qualify a scenario where your site is victimized with mail bombing? Hackers, with little effort, can instruct a computer to repeatedly send electronic mail to your Webmasters account to such a extend that it could generate a "denial of service" state and potentially shutdown your entire site. Is this action illegal? It may not be.
| Note: The journalist Joshua Quittner and Michelle Slatalla had their home computer targeted by hackers and flooded with mail bombs. Also, their phone lines were rerouted for a whole weekend. |
The problem is that, there is not a concrete definition yet for the term "computer-related crime." What is the difference between illegal or deliberate abuses of the Internet and an annoying act. Unfortunately, one could look at e-mail bombing both ways.
Legal systems everywhere, and ABA/STS is an example, are very busy trying to find ways of dealing with crimes and criminals on the Internet. As it stands, there is no common sense on how hackers an other computer criminals are prosecuted. It varies from one jurisdiction to another. It is as cases like Kevin Mitnick and Jake Baker unfolds that the world’s legal system starts to react and be ready for this new cast of citizens.
Computer information systems present a whole slew of legal issues. For instance, your Web site can very well be used for dissemination of useful information, but it can also be used as an outlet for defamation, contrabanded materials, etc. How should this situation be treaded? In case of a computer crime at your site where users where affected, who is liable, you or the "hacker?" Is the crime his fault, since he was the author, or the Webmaster’s, since he controls and provides access to the site?
There are multiple ways for regulating a wide variety of crimes, or potential crimes, for that matter. Therefore, the regulatory environment governing computer information systems is still somewhat confused.
The Federal Communications Commission (FCC), is responsible for regulating broadcasters and common carriers providing electronic data. However, FCC does not regulate computer information systems because it is considered to be an "enhanced" service.
What the legal system has to say? Not much at the moment. Pursuing a hacker through the legal system is a much harder and "almost impossible" task then tracking he/she down on your system after an attack. However, there are case laws and statutes in existence that deals with some specific aspects of computer information systems:
Another issue, can a person sue for defamation that occurred to a fictitious name (username) or a persona that appears on a computer? Because defamation involves speech, defamation raises serious First Amendment concerns. As it stands, liability may result if the act was libelous, and may not, if the defamation concerns public figures, public officials, or matters of public interest.
| Note: The Fraud and Abuse Statute states that: "a) whoever
of this section.
6. knowingly and with intent to defraud traffics (as defined in section 1029) in any password or similar information through which a computer may be accessed without authorization, if (A) such trafficking affects interstate or foreign commerce; or (B) such computer is used by or for the Government of the United States; of this section.of this section is(1) of this section which does not occur after a conviction for another offense under such subsection, or an attempt to commit an offense punishable under this subparagraph; and(1) of this section which occurs after a conviction for another offense under such subsection, or an attempt to commit an offense punishable under this subparagraph; and(1) of this section which does not occur after a conviction for another offense under such subsection, or an attempt to commit an offense punishable under this subparagraph; and (B) a fine under this title or imprisonment for not more than ten years, or both, in the case of an offense under subsection(6) of this section which occurs after a conviction for another offense under such subsection, or an attempt to commit an offense punishable under this subparagraph; and(5) of this section which does not occur after a conviction for another offense under such subsection, or an attempt to commit an offense punishable under this subparagraph; and(5) of this section which occurs after a conviction for another offense under such subsection, or an attempt to commit an offense punishable under this subparagraph.The United States Secret Service shall, in addition to any other agency having such authority, have the authority to investigate offenses under this section. Such authority of the United States Secret Service shall be exercised in accordance with an agreement which shall be entered into by the Secretary of the Treasury and the Attorney General. |
Unfortunately, despite the government, ABA and other agencies efforts, there is not much the law can do for you and your users. At least, not in s short term or without lots of time and money to battle in the legal system.
Your best bet than is to make sure you can protect your Web site. This whole book discussed the several ways you can protect your site, emphasizing on the use of firewalls. I hope you take to heart what was discussed and start putting in practice. It will save you time an grieve.
Nevertheless, I would like to close this book by reminding you of the very basic Web site security requirements to keep in mind:
The only way you will be able to achieve excellence in these areas is going to be by regulating the flow of users, services and activity of your site with predetermined set of rules, the security policy.
The security policy, which should precede any of the security strategies you may implement (firewalls, packet filtering, access control and authentication, etc.), will specify which subjects can access which objects. Thus, it is important that you have very clear what are the subjects you will be dealing with at your site (e.g. internal users, external users, clients leasing portions of your site, etc.) and objects to be accessed or offered (e.g. Web services, links, leased home pages, etc.)
You will need to devote some time an effort to elaborate your security policy. Security measures are employed to prevent illicit tampering with your "users and clients as well as your services offered.
As your site gains momentum, your users will increasingly rely on the services you provide to carry out many essential functions of their day-to-day life. Luckily, your site will become part of their "bookmarks" right at the first visit. If your site is to be depended upon, it is essential that you, Webmasters, systems administrators and everyone else responsible for its operation to recognize the vulnerabilities to which the site is subject and take the steps to implement appropriate safeguards. That is what this book is all about.
Internet security, while a relatively recent concern, is subject to a variety of interpretations. Historically, security measures have been applied to the protection of classified information from the threat of disclosure in a MIS or computer lab environment. But nowadays, in an environment where general Internet users are capable to shift from personal home pages on the Web to personal IPSs, much attention has been directed to the issue of individual privacy as it relates to personal information stored in the computerized data systems.
Data integrity in financial, scientific and process control applications at your site should be another focus of attention.
When setting up you security policy, remember that security policy, like your car insurance, is to a large extent applied risk management: you should try to achieve a tolerable level of risk at the lowest possible cost. The goal is to reduce the risk exposure of your site to an acceptable level, best achieved by a formal assessment of your risks. This includes a number of components, such as the identification of the Web site assets, values, threats and vulnerabilities, as discussed in this book, as well as the financial impact of each threat-asset combination.
When analyzing your risks, make sure to involve as many people as possible, from users to managers and upper management. If confidentiality is a specific concern, based on the services you will provide (dating services, financial services, etc.), additional protection must be provided through the application of hardware/software security solutions as well as mandatory regulatory requirements.
Make sure to include specific security administrative practices, assigning security responsibilities to all professionals involved with the operation and maintenance of the site. Make sure to determine:
Internet security is possible! Break-ins, although inevitable, can be prevented when you are aware of security issues. However, this means that all the issues discussed in this book would have to be taken into consideration, that this book would not be enough to guide you in securing you site as new threats arise everyday and the Web and computer technology is to diverse to be comprised in a single book.
Internet security and firewall management is a full-time job. The systems manager or the Webmaster, or the LAN administrator, or the MIS director and so on, cannot be blamed in case of an incident. They probably didn’t have time!
If the people involved with the every-day activity and operation of your site could known the information contained in this book, the risks of your site being attacked and the resulting damage could be much less. This is exactly why I wrote this book. Not for the gurus. Not for the technically skilled. It was to give an survey of the threats a Web site faces, the existence of hackers to make our work more... enjoyable.
By no means, don’t you have the illusion that by following the information and guidelines of this book your site will be impossible to penetrate.
Finally, make sure to keep security into account during the whole phase of your Web site design. This will also make security much more user friendly.
|
|
|
|
| |
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.