Security concepts III

Your Network
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.

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.

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.

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.

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...

Cost
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.

The Homogenous Network
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.

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.

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).

The Heterogeneous Network
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.

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).

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 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.

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.

The General Process
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:

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.)


Software. All types of network software that you intend to run, and their version numbers.


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.


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.)
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).

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:

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.


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.
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.

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.