ch24.htm

来自「Maximum Security (First Edition) 网络安全 英文」· HTM 代码 · 共 837 行 · 第 1/4 页

that one or two holes do exist but that it is extremely unlikely that they can be
exploited, carefully consider his explanation. Interrogate him as to what "extremely
unlikely&quot; means and why he thinks the contingency is just so.</P>
<P>If his explanation is that the level of technical expertise required is highly
advanced, this is still not a valid reason to let it slide, particularly if there
are currently no known solutions to the problem. If there are options, take them.
Never assume (or allow a consultant to assume) that because a hole is obscure or
difficult to exploit that it is okay to allow that hole to exist.</P>
<P>Only several months ago, it was theorized that a Java applet could not access
a client's hard disk drive. That has since been proven to be false. The argument
initially supporting the &quot;impossibility&quot; of the task was this: The programming
skill required was not typically a level attained by most crackers. That was patently
incorrect. Crackers spend many hours trying to determine new holes (or new ways of
implementing old ones). With the introduction of new technologies, such as Java and
ActiveX, there is no telling how far a cracker could take a certain technique.</P>
<P>Security through obscurity was once a sound philosophy. Many years ago, when the
average computer user had little knowledge of his own operating system (let alone
knowledge of multiple operating systems), the security-through-obscurity approach
tended to work out. Things were more or less managed on a need-to-know basis. The
problem with security through obscurity, however, becomes more obvious on closer
examination. It breaks down to matters of trust.</P>
<P>In the old days, when security through obscurity was practiced religiously, it
required that certain users know information about the system; for example, where
passwords were located and what special characters had to be typed at the prompt.
It was common, actually, for a machine, upon connection, to issue a rather cryptic
prompt. (Perhaps this can be likened to the prompt one might have received as a Delphi
user just a few years ago.) This prompt was expecting a series of commands, including
the carrier service, the terminal emulation, and so on. Until these variables were
entered correctly (with some valid response, of which there were many), nothing would
happen. For example, if the wrong string was entered, a simple <TT>?</TT> would appear.
A hacker coming across such a system would naturally be intrigued, but he could spend
many hours (if not weeks) typing in commands that would fail. (Although the command
<TT>HELP</TT> seems to be a pretty universal way to get information on almost any
system.)</P>
<P>Things changed when more experienced users began distributing information about
systems. As more and more information leaked out, more sophisticated methods of breaching
security were developed. For example, it was shortly after the first release of internal
procedures in CBI (the Equifax credit-reporting system) that commercial-grade software
packages were developed to facilitate a breaking and entering into that famous computerized
consumer credit bureau. These efforts finally culminated with the introduction of
a tool called CBIHACK that automated most of the effort behind cracking Equifax.</P>
<P>Today, it is common for users to know several operating systems in at least a
fleeting way. More importantly, however, information about systems security has been
so widely disseminated that at this stage, even those starting their career in cracking
know where password files are located, how authentication is accomplished, and so
forth. As such, security through obscurity is now no longer available as a valid
stance, nor should it be, especially for one insidious element of it--the fact that
for it to work at all, humans must be trusted with information. For example, even
when this philosophy had some value, one or more individuals with an instant need-to-know
might later become liabilities. Disgruntled employees are historically well known
to be in this category. As insiders, they would typically know things about a system
(procedures, logins, passwords, and so forth). That knowledge made the security inherently
flawed from the start.</P>
<P>It is for these reasons that many authentication procedures are now automated.
In automated authentication procedures, the human being plays no part. Unfortunately,
however, as you will learn in Chapter 28, &quot;Spoofing Attacks,&quot; even these
automated procedures are now suspect.</P>
<P>In any event, view with suspicion any proposal that a security hole (small though
it may be) should be left alone.
<H2><FONT COLOR="#000077"><B>Choosing a Consultant</B></FONT></H2>
<P>There are many considerations in choosing a security consultant. First, it is
not necessary that you contract one of the Big Ten firms (for example, Coopers and
Lybrand) to secure your network. If you are a small business, this is likely cost
prohibitive. Also, it is overkill. These firms typically take big contracts for networks
that harbor hundreds (or in WANs, thousands) of machines.</P>
<P>If you are a small firm and cannot afford to invest a lot of money in security,
you may have to choose more carefully. However, your consultant should meet at least
all the following requirements:

<UL>
	<LI>He should be local.<BR>
	<BR>
	
	<LI>He should have at least four years experience as a system administrator (or apprentice
	administrator) on your platform. (If some of that experience was in a university,
	that is just fine.)<BR>
	<BR>
	
	<LI>He should have a solid reputation.<BR>
	<BR>
	
	<LI>Generally, he should not have a criminal record.<BR>
	<BR>
	
	<LI>He should have verifiable references.
</UL>

<H3><FONT COLOR="#000077"><B>Why Local?</B></FONT></H3>
<P>Your consultant should be local because you will need to have him available on
a regular basis. Also, as I've noted, remote administration of a network is just
not a wise thing.
<H3><FONT COLOR="#000077"><B>Experience</B></FONT></H3>
<P>You notice that I say that university experience will suffice, so long as it does
not comprise the totality of the consultant's security education. Why? Because the
academic community is probably the closest to the cutting edge of security. If you
thumb through this book and examine the references, you will notice that the majority
of serious security papers were authored by those in the academic community. In fact,
even many of the so-called commercial white papers cited within this book were also
authored by students--students who graduated and started security firms.
<H3><FONT COLOR="#000077"><B>Reputation</B></FONT></H3>
<P>I suggest that your consultant should have a solid reputation, but I want to qualify
that. There are two points to be made here, one of which I made at the beginning
of this book. Just because former clients of a consultant have not experienced security
breaches does not necessarily mean that the consultant's reputation is solid. As
I have said, many so-called security spe- cialists conduct their &quot;evaluation&quot;
knowing that they have left the system vulnerable. In this scenario, the individual
knows a little something about security, but just enough to leave his clients in
a vulnerable situation with a false sense of security. Technically, a totally unprotected
network could survive unharmed for months on the Internet so long as crackers don't
stumble across it.</P>
<P>It would be good if you could verify that your potential consultant had been involved
in monitoring and perhaps plugging an actual breach. Good examples are situations
where he may have been involved in an investigation of a criminal trespass or other
network violation.</P>
<P>Equally, past experience working for an ISP is always a plus.
<H3><FONT COLOR="#000077"><B>Criminal Record</B></FONT></H3>
<P>Background checks are intrusive. I realize that. However, consider what you are
undertaking. Most smaller businesses today would be paralyzed if their data were
suddenly corrupted or unusable. If yours is such a business, and your potential consultant
is not an established firm, I would seriously consider a background check. However,
the existence of a criminal record (especially if that record is for computer-related
crimes) does not necessarily preclude the individual as a candidate. Much depends
upon the time that has passed since the conviction, the circumstances of the case,
and so forth. For example, I would hire Randall Schwartz without thinking twice.
His technical skills are well known.
<H2><FONT COLOR="#000077"><B>Your Network</B></FONT></H2>
<P>There are several ways you can view security, but I prefer the simple approach
and that approach is this: Your network is your home. Consider that for a moment.
Try to visualize your network as an extension of yourself. I realize that this sounds
a bit esoteric, but it really isn't. You can more easily grasp what I am driving
at by considering this: What type of data is on your network? I will wager that I
can tell you what's there. Yes; I will bet that only the most unimportant things
are on your network--things like your financial information, your identity, your
thoughts, your feelings, your personal reflections, your business...your life.</P>
<P>Would you let the world walk through the front door of your home? Would you let
complete strangers rifle through your drawers, looking for personal documents or
financial statements? Of course not. Then why would you let someone do it over a
network? The answer is: You wouldn't. The problem is, computers seem relatively benign,
so benign that we may forget how powerful their technology really is.</P>
<P>Software vendors want us to rush to the Internet. The more we use the network,
the more software they can sell. In this marketing frenzy, they attempt to minimize
some fairly serious problems out there. The truth is, the Internet is not secure
and will continue to exist in this state of insecurity for some time to come. This
is especially so because many of the networking products used in the future will
be based on the Microsoft platform.</P>
<P>Admittedly, Microsoft makes some of the finest software in the world. Security,
however, has not been its particular area of expertise. Its Internet operating system
is going to be NT--that's a fact. That is also where the majority of Microsoft's
security efforts are being concentrated, and it has made some significant advances.
However, in the more than 20 years that UNIX has been in existence, it has never
been completely secure. This is an important point: UNIX is a system that was designed--almost
from its beginning--as an operating system for use on the Internet. It was what the
Defense Department chose as the platform to develop ARPAnet. The people who designed
it are among the most talented (and technically minded) software engineers on the
planet. And even after all this, UNIX is not secure. We should expect, then, that
Windows NT will take some time to get the bugs out.</P>
<P>So, in closing on this subject, I relate this: Your network is your home. It is
worthy of protection, and that protection costs money. Which brings us to the next
issue...
<H2><FONT COLOR="#000077"><B>Cost</B></FONT></H2>
<P>How much should security cost? It depends on what type of network you have. If
your network is large and heterogeneous, those conditions are going to increase the
cost. It is important that you understand why, because when you go to the table to
negotiate a security package, you need to know what you are talking about.
<H3><FONT COLOR="#000077"><B>The Homogenous Network</B></FONT></H3>
<P>If you currently have a homogenous network, you should see a break in cost. Here
is why: Each operating system implements TCP/IP just slightly differently than the
rest, at least at the application level. Each operating system also has one or more
additional or proprietary protocols that aren't available on other systems (or that
can be available, but only with special software). For example, Windows 95 uses the
SMB protocol, which is not widely available in default installations of every operating
system. Certainly, there are clients available; one of them is SAMBA, which runs
on Linux and perhaps on other operating systems. Because each operating system is
different but all machines running the same operating system are basically the same,
a security consult of a homogenous network is less intensive than one that harbors
many different platforms. It should therefore cost less.</P>
<P>While this is true, it does not mean that you can get a homogenous network secured
for next to nothing. In most instances, it is not possible for security attributes
to simply be cloned or replicated on all workstations within the network. Various
security issues may develop. Some of those involve topology, as I have explained
in other chapters and will again discuss here.</P>
<P>We know that a network segment is a closed area; almost like a network within
itself. We also know that spoofing beyond that network segment is almost impossible.
(Almost.) The more network segments your network is divided up into, the more secure
your network will be. (Ideally, each machine would be hardwired to a router. This
would entirely eliminate the possibility of IP spoofing, but it is obviously cost
prohibitive.) Where you make those divisions will depend upon a close assessment
of risk, which will be determined between your technical staff and the consultant.
For each segment, you will incur further cost, not only for the consultant's services
but for the hardware (and possibly for software).
<H3><FONT COLOR="#000077"><B>The Heterogeneous Network</B></FONT></H3>
<P>If you have a network comprised of many different platforms, the problem of securing
it becomes more complex. Here's an example, again using SAMBA as a focal point. In
certain situations, passwords are revealed when using SAMBA in traffic between UNIX
and Windows 95 boxes. The more protocols you have running and the more third-party
software from different vendors (on different platforms) you have, the more complicated
your security assessment will be.</P>
<P>Certainly, even from a practical standpoint, there are immediate problems. First,
due largely to the division between the PC and workstation worlds, the security consultants
you contract may be unfamiliar with one of more of the platforms within your network,
and they may need to call outside help for them. Also, and this is no small consideration,
your consultants may ultimately be forced to provide at least a small portion of
proprietary code: their own. If this subject crops up, it should be discussed thoroughly.
There is a good chance that you can save at least some cost by having these consultants
tie together existing security packages, using their own code as the glue. This is
not nearly as precarious as it sounds. It may involve nothing more than redirecting
the output of log files or other, ongoing processes to plain text (or some other
form suitable for scanning by a program on another platform).</P>
<P>The problem with hiring toolsmiths of this sort is that you may find your security
dependent upon them. If your local system administrator is not familiar with the