ch24.htm

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

code they used, you may have to rely on the consultants to come for second and third
visits. To guard against this, you should ensure good communications between your
personnel and the security team. This is a bit harder than it seems.</P>
<P>First, you have to recognize at least this: Your system administrator is God on
the network. That network is his domain, and he probably takes exceptional pride
in maintaining it. (I have seen some extraordinary things done by system administrators--truly
commercial-grade applications running, custom interfaces, and so forth.) When an
outside team comes to examine your system administrator's backyard, no matter what
they say, the experience feels a little intrusive. Diplomacy is really an important
factor. Remember: The consultants will leave, but you have to live with your system
administrator on a daily basis.
<H2><FONT COLOR="#000077"><B>The General Process</B></FONT></H2>
<P>Before you contact any firm and have them come to your offices (or home, I suppose),
you need to gather some information on a few things, including the following:

<UL>
	<LI>Hardware. This should identify the make, manufacturer, model, and series of each
	workstation, hub, router, network adapter, and so forth. Ideally, you should also
	have a list of how much memory is in each machine, the capacity of the disk drives,
	and the specs of your Ethernet. (For example, 10Base-T or whatever.)<BR>
	<BR>
	
	<LI>Software. All types of network software that you intend to run, and their version
	numbers.<BR>
	<BR>
	
	<LI>Protocols. The protocols you are now running (or plan to run in the future).
	Try to prioritize these. For example, if there is a single machine that simply must
	run NFS, highlight that. Also, report the type of connectivity that you currently
	have.<BR>
	<BR>
	
	<LI>Scope. The maximum number of workstations you plan to run, where they are located,
	where the network segments exist, where you plan to expand, and any curiosities that
	might be relevant. (For example, that you have older, legacy Novell NetWare servers
	running in one office. If these are sufficiently old, they may traffic unencrypted
	passwords. Your consultant will need to know that. Don't let something like that
	crop up later.)
</UL>

<P>Next, you will need to gather a little model of your company's trust system. That
is, you will need to have your system administrator devise some easy listing method
to peruse privileges. This will identify what each user or workstation requires in
the way of privileges. It might be worth outputting this not only in text format,
but also in some graphical representation. On certain platforms, this type of software
is available, but it is quite expensive. It is probably better (for small firms trying
to save money) if this is done using some technical drawing package (such as Visio).</P>
<P>This information should be bound together. (There are copying services that will
bind such a folder, such as Kinko's Copies, or perhaps you have in-house facilities
that can do this.) Each section should be separated by a tab that identifies that
section. Contained within this folder should also be the following items:

<UL>
	<LI>A statement from the system administrator about the security of the system. This
	should include any special considerations, including whether special software has
	been written, what type of security utilities are now being used, which ones could
	not be used, and why.<BR>
	<BR>
	
	<LI>A statement of what type of security policies have been enforced within your
	network, a history of any security breaches that you may have had, and so forth.
</UL>

<P>This compilation of information should be handed over to the security consultants
only after you have verified their reputation, because once it is in their hands,
they will know more about your network than your system administrator did just one
week before. However, it is important to collect the information, and here is why:
If you don't do it, the security consulting firm will. That will cost a lot of money.
Moreover, it will entail them having to disrupt daily activities even further than
they already have to while implementing solutions.</P>
<P>The next step may or may not be within your budget, but if it is, I would strongly
recommend it. Locate two separate security firms known to have good reputations.
(Even if they are in a different state; it doesn't matter.) Ask those firms what
it would cost to examine the information and make a recommendation, a kind of mock
bid. Included within their summaries should be a report of how such a job would be
implemented if they were doing it. This will not only serve as an index for what
the probable cost and effort would be, but also may alert you or your system administrator
to special issues, issues particular to your precise configuration. That having been
done, you can begin your search for a good, local source.
<H2><FONT COLOR="#000077"><B>Degrees of Security</B></FONT></H2>
<P>There are different ways that you can implement security. There is no law saying
that you have to connect your entire network to the Internet. (Although I see a fair
number of businesses doing it.) One simple way to reduce your cost is to create only
a very limited segment that has connectivity. If your primary concern is receiving
customer feedback (and providing some promotional information), there really is no
need to connect at all. Certainly, an ISP can host a page (or even co-locate a box)
for you.</P>
<P>However, if you are determined to provide dedicated access, with a server under
your local control, there are some things you can do to greatly increase security.
First, if the only box you are placing out on the freeway is a Web server (and you
are concerned about that server being cracked), you can use read-only media. This
procedure is admittedly more difficult to implement than a live file system (one
that is read/write), but the gains you realize in security are immense. Under such
a scenario, even if a cracker gains root access, there is very little that he can
do. The downside to this, of course, is that dynamic pages cannot be built on-the-fly,
but if you are providing an auto-quote generator or some similar facility (perhaps
even interfacing with a database), it can still be done.</P>
<P>Really, the key is to enclose all CGI into a restricted area. The CGI programs
read the data on the read-only media and generate a resulting page. This is a very
secure method of providing technical support, product lists, and prices to clients
in the void. Essentially, so long as you back up your CGI, you could have that identical
machine up in one hour or less, even if crackers did manage to crash it. This type
of arrangement is good for those who are only providing information. It is poor for
(and inapplicable to) those seeking to accept information. If you are accepting information,
this might involve a combination of secure HTML packages or protocols, where the
information received is written to removable, write-one-time media.</P>
<P>The sacrificial host is really the safest choice. This is a host that is expressly
out in the open and that you expect to be cracked. Certainly, this is far preferable
to having any portion of your internal network connected to the Internet. However,
if you also want your local employees or users to be able to access the Net, this
is entirely impractical. It can, however, be implemented where you do not expect
much access from the inside out, particularly in commerce situations.</P>
<P>A commerce situation is one where you are accepting credit card numbers over a
browser interface. Be very careful about how you implement such schemes. Here is
why: There are various paths you can take and some of them represent a greater risk
than others. Typically, you want to avoid (at any reasonable cost) storing your customers'
credit card numbers on any server connected to the network. (You have already seen
the controversy that developed after it was learned that Kevin Mitnik had acquired
credit card numbers--reportedly 20,000-- from the drives of Netcom.)</P>
<P>Generally, where you are accepting credit card numbers over the Internet, you
will also be clearing them over the network. This typically requires the assistance
of an outside service. There are various ways that this is implemented, although
two techniques dominate that market.
<H3><FONT COLOR="#000077"><B>Local Saves</B></FONT></H3>
<P>In a local save scenario, the information is piped through some secure, encrypted
HTTP session (SHTTP, for example). Usually, this is done through a form written specifically
for that purpose. The form outputs the information to a local disk somewhere, from
which it can later be retrieved for verification purposes. Along that journey from
the input form to the disk, the numbers may be sent through several processes. One
is where the numbers are examined against a common algorithm that determines (first
and foremost) whether the submitted credit card number is even a real one. By <I>real</I>,
I mean that it is a potentially real one. This is one somewhat flawed version of
verification. It basically relies on the same algorithms that are used to generate
card numbers to begin with. If the submitted number fails to result in a number that
could have been generated by the algorithms, the card number is a dreamt-up number,
something that someone randomly guessed. There are two flaws with this type of verification,
one in the basic concept and the other in reference to security.</P>
<P>The first problem is this: The algorithms used are now widely disseminated. That
is, there are credit card number generators available across the Internet that will
resolve numbers to either a state of authenticity or no authenticity. Kids used them
for years to circumvent the security of Internet service providers.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>One very good example is utilities
	that exist for unlawfully accessing AOL. These utilities have, embedded within their
	design, automatic generators that produce a laundry list of card numbers that will
	be interpreted as valid. When these programs first emerged, the credit card number
	generators were primitive and available as support utilities. As using generators
	of this variety became more common, however, these utilities were incorporated into
	the code of the same application performing the dial-up and sign-on. The utilities
	would pop up a window list from which the cracker could choose a number. This number
	would be sent (usually by the <TT>SendKeys</TT> function in VB) to the registration
	form of the provider. 
<HR>


</BLOCKQUOTE>

<P>So, at the start, individuals could come forward with at least <I>mathematically</I>
sound numbers for submission. Thus, simple algorithm credit card validation subjects
the accepting party to a significant amount of risk. For example, if this verification
is used in the short run but the cards are later subjected to real verification,
the interim period comprises the longest time during which the accepting party will
lose goods or services as a result of a fraudulent charge. If this period is extended
(and the temporary approval of such a credit card number grants the issuer access
to ongoing services), then technically, the accepting party is losing money for every
day that the credit card is not actually validated.</P>
<P>Secondly, and perhaps more importantly, storing the numbers on a local drive could
prove a fatal option. You are then relying upon the security of your server to protect
the data of your clientele. This is not good. If the information is ultimately captured,
intercepted, or otherwise obtained, potentially thousands (or even hundreds of thousands)
of dollars might be at stake. If there is a subsequent investigation (which there
usually is), it will ultimately come out that the seed source for the numbers was
your hard disk drives. In other words, after the Secret Service (or other investigating
party) has determined that all victims shared only one common denominator (using
your service), you will have a problem.</P>
<P>This is especially true if your system administrator fails to detect the breach
and the breach is then an ongoing, chronic problem. There is a certain level at which
this could raise legal liability for your company. This has not really been tested
in the courts, but I feel certain that within the next few years, special legislation
will be introduced that will address the problem. The unfortunate part of this is
as follows: Such a case would rely heavily on expert testimony. Because this is a
gray area (the idea of what &quot;negligent&quot; system administration is, if such
a thing can exist), lawyers will be able to harangue ISPs and other Internet services
into settling these cases, even if only in an effort to avoid sizable legal bills.
By this, I mean that they could &quot;shake down&quot; the target by saying &quot;I
will cost you $50,000.00 in legal bills. Is it worth the trouble to defend?&quot;
If the target is a large firm, its counsel will laugh this off and proceed to bury
the plaintiff's counsel in paperwork and technical jargon. However, if the target
is a small firm (perhaps hiring a local defense firm that does not specialize in
Internet law), a legal challenge could be enormously expensive and a drain on resources.
If you have to choose, try to saddle some third party with the majority of the liability.
In other words, don't store those numbers on your drives if you can help it.
<H3><FONT COLOR="#000077"><B>Remote Saves via CGI</B></FONT></H3>
<P>The second scenario may or may not be preferable. This is where you drop a secure
HTML form into the structure of your Web site. (This form is provided by the credit
card clearing service.) With this, you will likely also receive customized scripts
that redirect the data submitted in that form to a remote server. That remote server
fulfills one purpose only: clearing the numbers.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>There are various methods through
	which the mechanics of this process are achieved. One is where the credit card clearing
	company has proprietary software that attaches to a particular port. On both the