8
surface. But, if you repeatedly ask for details and dont get them, there may be more to it than meets the eye.
Common justifications are security and privacy. Unless you are in a management position, there is often little you can do other than accept the explanations given. But if you are in a management
position, are technically competent, and still hear these excuses from your employees, beware You have a serious problem.
No one knows everything. Whenever information is suppressed, you lose input from individuals who dont have the information. If an employee cant control her ego, she should not be turned loose on
your network with the tools described in this book. She will not share what she learns. She will only use it to further entrench herself.
The problem is basically a personnel problem and must be dealt with as such. Individuals in technical areas seem particularly prone to these problems. It may stem from enlarged egos or from insecurity.
Many people are drawn to technical areas as a way to seem special. Alternately, an administrator may see information as a source of power or even a weapon. He may feel that if he shares the information,
he will lose his leverage. Often individuals may not even recognize the behavior in themselves. It is just the way they have always done things and it is the way that feels right.
If you are a manager, you should deal with this problem immediately. If you cant correct the problem in short order, you should probably replace the employee. An irreplaceable employee today will be
even more irreplaceable tomorrow. Sooner or later, everyone leaves—finds a better job, retires, or runs off to Poughkeepsie with an exotic dancer. In the meantime, such a person only becomes more
entrenched making the eventual departure more painful. It will be better to deal with the problem now rather than later.
1.3.2.3 Legal and ethical considerations
From the perspective of tools, you must ensure that you use tools in a manner that conforms not just to the policies of your organization, but to all applicable laws as well. The tools I describe in this book
can be abused, particularly in the realm of privacy. Before using them, you should make certain that your use is consistent with the policies of your organization and all applicable laws. Do you have the
appropriate permission to use the tools? This will depend greatly on your role within the organization. Do not assume that just because you have access to tools that you are authorized to use them. Nor
should you assume that any authorization you have is unlimited.
Packet capture software is a prime example. It allows you to examine every packet that travels across a link, including applications data and each and every header. Unless data is encrypted, it can be
decoded. This means that passwords can be captured and email can be read. For this reason alone, you should be very circumspect in how you use such tools.
A key consideration is the legality of collecting such information. Unfortunately, there is a constantly changing legal morass with respect to privacy in particular and technology in general. Collecting some
data may be legitimate in some circumstances but illegal in others.
[3]
This depends on factors such as the nature of your operations, what published policies you have, what assurances you have given your
users, new and existing laws, and what interpretations the courts give to these laws.
[3]
As an example, see the CERT Advisory CA-92.19 Topic: Keystroke Logging Banner at http:www.cert.orgadvisoriesCA-1992-19.html
for a discussion on keystroke logging and its legal implications.
9
It is impossible for a book like this to provide a definitive answer to the questions such considerations raise. I can, however, offer four pieces of advice:
•
First, if the information you are collecting can be tied to the activities of an individual, you should consider the information highly confidential and should collect only the information
that you really need. Be aware that even seemingly innocent information may be sensitive in some contexts. For example, sourcedestination address pairs may reveal communications
between individuals that they would prefer not be made public.
•
Second, place your users on notice. Let them know that you collect such information, why it is necessary, and how you use the information. Remember, however, if you give your users
assurances as to how the information is used, you are then constrained by those assurances. If your management policies permit, make their prior acceptance of these policies a requirement
for using the system.
•
Third, you must realize that with monitoring comes obligations. In many instances, your legal culpability may be less if you dont monitor.
•
Finally, dont rely on this book or what your colleagues say. Get legal advice from a lawyer who specializes in this area. Beware: many lawyers will not like to admit that they dont know
everything about the law, but many arent current with the new laws relating to technology. Also, keep in mind that even if what you are doing is strictly legal and you have appropriate
authority, your actions may still not be ethical.
The Peter Principle Revisited
In 1969, Laurence Peter and Raymond Hull published the satirical book, The Peter Principle. The premise of the book was that people rise to their level of incompetence. For
example, a talented high school teacher might be promoted to principal, a job requiring a quite different set of skills. Even if ill suited for the job, once she has this job, she will
probably remain with it. She just wont earn any new promotions. However, if she is adept at the job, she may be promoted to district superintendent, a job requiring yet another set of
skills. The process of promotions will continue until she reaches her level of incompetence. At that point, she will spend the remainder of her career at that level.
While hardly a rigorous sociological principle, the book was well received because it contained a strong element of truth. In my humble opinion, the Peter Principle usually fails
miserably when applied to technical areas such as networking and telecommunications. The problem is the difficulty in recognizing incompetence. If incompetence is not recognized,
then an individual may rise well beyond his level of incompetence. This often happens in technical areas because there is no one in management who can judge an individuals
technical competence.
Arguably, unrecognized incompetence is usually overengineering. Networking, a field of engineering, is always concerned with trade-offs between costs and benefits. An
underengineered network that fails will not go unnoticed. But an overengineered network will rarely be recognizable as such. Such networks may cost many times what they should,
drawing resources from other needs. But to the uninitiated, it appears as a normal, functioning network.
If a network engineer really wants the latest in new equipment when it isnt needed, who, outside of the technical personnel, will know? If this is a one-person department, or if all the
members of the department can agree on what they want, no one else may ever know. It is
10
too easy to come up with some technical mumbo jumbo if they are ever questioned. If this seems far-fetched, I once attended a meeting where a young engineer was arguing
that a particular router needed to be replaced before it became a bottleneck. He had picked out the ideal replacement, a hot new box that had just hit the market. The problem with all
this was that I had recently taken measurements on the router and knew the average utilization of that bottleneck was less than 5 with peaks that rarely hit 40.
This is an extreme example of why collecting information is the essential first step in network management and troubleshooting. Without accurate measurements, you can easily
spend money fixing imaginary problems.
1.3.2.4 Economic considerations
