This chapter briefly discusses the internal breach. An internal breach can be defined as any breach of security on a network to which the hacker or cracker has some access, on which he is a user with a valid account, or where he is a member of a company that maintains such a network.
Whether you are a victim or a perpetrator of an internal breach, know this: Authorized users have access to an enormous amount of information that remote (and unauthorized) users and crackers work hard to acquire. For example, building a list of users on a UNIX system is only a few keystrokes away for the authorized user. It can be done as simply as this:
ypcat passwd || cat /etc/passwd) | sed -e `s/:.*//'
Compare this with building a reliable username list from the outside. This might entail writing a script that routinely issues finger and ruser requests, checks the data against an outfile, and discards dupes. Even if the network you are targeting is small, you could spend a lot of time trying to obtain a decent list. In contrast, larger networks such as ISPs might render hundreds of names at a time. It depends on how lazy the system administrator is at that location. As I discuss in Chapter 13, "Techniques to Hide One's Identity," if the system administrator has failed to install a hacked finger daemon or failed to restrict finger access either marginally or completely, a huge user list can be obtained with a single command line. So my first point is this: Local users who have even limited but authorized access can obtain quite a bit of information about users.
Additionally, they have access to tools that are unavailable to remote, unauthorized users. Exactly what those tools are depends on the system; but in most UNIX-based environments, this includes at least shell language access and probably Perl access. If the network in question is an ISP, it probably also includes access to a C compiler. If that ISP is running Linux, there is a strong chance that a laundry list of compilers is available. Most system administrators who use Linux install the majority of, if not all, development packages. Certainly, TCL will be available. This will probably be accompanied by gcc and g++, a BASIC development package, and perhaps Pascal, Python, FORTRAN, and others. Aren't Linux and GNU wonderful?
Nevertheless, the shell languages alone are enough. These, coupled with awk and sed, formulate a formidable programming environment. And this doesn't apply exclusively to UNIX, either. Here are some power-packed development tools that could empower a user on other networks or platforms:
In fact, user access to programming tools is an even more critical issue in the Windows 95 environment. NT, providing it is installed correctly, boasts strong access control. This control is at least as strong as in most implementations of non-trusted UNIX. In contrast, Windows 95 has no access control.
Because of this, a local user can install such development packages on his workstation at any time. Most of these tools now exist in free form, either from GNU or some other organization or vendor. There are even TCL interpreters for Windows 95, so the user need not spend $400 for a development package. Contrast this with the UNIX and NT environments. A local user installing such packages on a local workstation has serious problems. For example, access control policies can prevent users from executing programs in certain directories. Also, disk quotas are often instituted on such networks. Thus, a user only gets (for example) 8MB of space for himself. This precludes all but the smallest compilers, and even then, installation is tricky.
Conversely, a user can install anything he likes on a Windows 95 network; however, he probably doesn't even have to. If a full distribution of Office is available and no third-party access-control product has been installed, the local user will at least have access to WordBasic or other tools that, while not generally characterized as full-fledged development tools, can offer increased levels of access and control. Let's not even consider the possibilities if Java is available.
Moreover, local users have an immediate avenue to the network. They are therefore prime candidates to place a sniffer on the drive or drives. As discussed in earlier chapters, this allows them to obtain (at the very least) the usernames and passwords of those located on the same network segment.
There are other advantages of being a local user. One is simply that you are authorized to be there. Think of this not in terms of computers but in terms of real life. An individual who is about to commit a burglary late at night is already in a compromised position. If he is found loitering about the grounds of a local resident's home, he already appears suspicious. However, if he lives inside the house as a guest, he has every right to be lurking about at 3:00 a.m.
Similarly, a local user with authorized access (who intends to exceed that access) is supposed to be there. Although it might seem odd for someone to be logged on in the middle of the night, normal user activity during the day is perfectly acceptable.
With this right comes certain amenities. One is that the user's presence on the system need not be hurried. In contrast, a cracker who tries to leverage the simple access he has gained may be forced to spend only short periods on the network. Until he gains root (or a reasonably facsimile thereof), he is constantly under pressure and the threat of being discovered. In contrast, a local, authorized user can crack at his leisure. He need not hurry at all. In fact, he could spread his activity over a period of months.
Furthermore, local users have the ability to use perfectly innocuous techniques (that in themselves cannot be deemed unauthorized) to derive information about the system. A user can quietly run netstat, arp, ifconfig, and other queries without anyone thinking twice. Therefore, he has the luxury of building an enormous knowledge base about the system using techniques that will likely never be logged. The system administrator who ends up investigating a breach that started this way can only hope that some of these queries were redirected to outfiles or hope for other tangible evidence.
That said, being a local user does have its disadvantages. For instance, cracking under an authorized account places the user in a compromised position if trouble does eventually surface; the system administrator can easily determine who has been doing the cracking. If the cracker is unaware that his activity has been detected (and the system administrator has been logging that activity), he is basically up the creek without a paddle. Subsequent testimony of co- workers can at least establish that this user was sitting at that desk all day long.
Moreover, the local user is under a lot of pressure to avoid leaving materials or evidence behind. The remote user needn't worry about this. For example, a remote user can issue a finger query from his local prompt and redirect the information to a file. No one will be scanning the remote user's directories for such files. In contrast, the local user cannot safely leave that information on the drive. In fact, if the situation is sufficiently serious, the local user shouldn't place the information on the drive at all, even if he intends to delete it later. Data recovery techniques are now sufficiently advanced that if the local user discards or otherwise deletes the information, it can probably be recovered. In such an instance, the smart local cracker will at least encrypt the data before discarding it. However, this may even be a wasted effort, depending on the operating system, the version, the type of file, and so forth.
Cross Reference: Ever heard of MicroZap? If not, you should become familiar with it. It is a utility that will obliterate trace elements of files that have been (or are about to be) deleted. You can get information on this utility online at http://www.govtech.net/.
For an interesting (albeit brief) look into this problem, I suggest you read the article "Erased Files Often Aren't," by Michael Anderson. In it, he reports how he received some floppy disks from a consortium of executives in law enforcement. He wrote:
Cross Reference: You can find "Erased Files Often Aren't," by Michael Anderson (published in Government Technology Magazine, January, 1997) online at http://www.govtech.net/1997/gt/jan/jan-justice&technology2/jan-justice&technology2.shtm.
Perhaps crackers reading this aren't thoroughly convinced; perhaps that example was a bit too benign. What about this case, then:
Cross Reference: The previous paragraph is excerpted from an article by Richard K. Moher titled "Computer Crime: Tips on Securing and Recovering Electronic Data" (originally published by New York Law Publishing Company). This article can be found online at http://www.ljextra.com/securitynet/articles/121796s2.html.
At the beginning of this book, I discussed the types of holes that exist, why they exist, and what impact they can have on Internet security. If you remember, I pointed out that local holes were far and away more common than remote ones.
Remote holes are matters of extreme concern. In fact, when a remote hole surfaces, crackers have to work to capitalize on that hole within the first few days of its reporting. If they fail to do so, the hole will be swiftly closed, precluding further exploitation. Moreover, programmers are extremely careful when coding remote applications, be they client or server. Big vendors are likewise careful because applications that offer remote access form the very binding thread of the Internet. If these applications could not be trusted, the Internet would come to a grinding halt. Lastly, because so much focus has been on remote applications (particularly by crackers who do often crack across borders or even continents), it is rare to find a remote hole that can result in root or even privileged access.
In contrast, internal applications may often be flawed. It's not that programmers who work on internal applications are less careful than their counterparts who code remote applications; rather, programmers who work on internal applications have a more difficult task. For example, client/server applications are generally limited in their scope. True, these applications may call others, but their scope is typically limited to a handful of operations that occur outside the client/server relationship.
In contrast, local internal applications may be required to interface with dozens of system utilities or processes. As I mentioned at the beginning of the book, many don't expect these utilities or processes to have security implications. Finally, internal applications could be coded by anybody. Third-party vendors abound for local internal applications. Conversely, there are only so many vendors that design fully fledged server packages for a given platform. In the UNIX community, this is especially so. How many HTTP servers are there for UNIX? Compare this to the number of text editors, CD-ROM utilities, and printing tools. The latter exceed the former by a huge margin.
This is less so in the IBM-compatible and Macintosh communities. However, these communities have still other problems. For example, in Windows 95, a malicious cracker could easily attack the underlying database system by removing just a few key files. So there is no comfortable trade-off.
The internal cracker need not concern himself with complex techniques, such as scanning, and tools. He simply needs to know the system and its holes. This is not a complicated matter.
Much depends upon the type of network he is attempting to crack. However, one thing remains universal, regardless of the platform with which he is working: known holes. To obtain known holes, the cracker may have to do either a little research or a lot (probably a little less now that this book exists).
For information about internal (and remote) holes, BUGTRAQ is a great source. The technical level of the information available there is generally very high. Moreover, there are often detailed analyses of tools and techniques for a wide variety of platforms. A perfect example is a September 1996 posting by a software engineer from Indiana. He begins his posting as follows:
Cross Reference: The previous paragraph is excerpted from "An Attack Against the NetWare Login Protocol," by G. Miller. It can be found online at http://geek-girl.com/bugtraq/1996_3/0530.html.
The posting continues for about three typewritten pages, complete with diagrams showing the methods through which keys are exchanged on a Novell NetWare login. At the conclusion of the posting, the author leaves his WWW page address, where one can find other tools to test (or circumvent) network security.
NOTE: Some (though not all) of Mr. Miller's tools are on the CD-ROM that accompanies this book. Two such tools are Miller's spoofing utility and his C source for attacking the Novell login procedure.
What is even more extraordinary about BUGTRAQ is that readers post to it with detailed information about this or that hole. When a posting like the one referenced previously appears, it is immediately followed by commentary from other members of the list. Much of the time, other members take code, policy, or theory and test it out in their own environment. This yields even further information about the discussed attack.
The fact is, the majority of information posted to BUGTRAQ refers to secondary holes that can only be exploited by local users. Tracking a few such advisories can be instructive. Suppose we take HP-UX as an example; a search through BUGTRAQ looking for pure security advisories or holes produces some very interesting information.
NOTE: A pure advisory or hole is any top-level posting (a posting that is the first in a series). It is quite literally the first mention of that particular hole. Subsequent threads can also be significant, but here I am simply demonstrating the nature of the data, not the value of it.
Have a look at a few listings:
These types of advisories are posted each day. Many of them contain explicit instructions for testing your state of vulnerability. These instructions generally include source or shell code. A local cracker need not be a genius to exploit this information. In fact, if a cracker is a subscriber of BUGTRAQ (and perhaps a dozen other public security mailing lists), he doesn't even need to search for the information. As soon as a vulnerability hits the wire, it is automatically mailed out to all members of the list. If the cracker is such a member, he gets this news hot off the press. So the information is there. This situation, therefore, breaks the local crack into two categories or classifications:
An opportunity crack is one that suddenly emerges. This is where the cracker has been monitoring or at least receiving security advisories on a regular basis. He cranks up his browser one morning and a new vulnerability is available. This situation is very common.
If an average crack occurs on your network, it is your fault and not the cracker's. That is because the average crack involves exploitation of known vulnerabilities. This brings us to an issue of some concern: Just what is a "known vulnerability," and what is the time period after which your security personnel or system administrator should be aware of it?
A known vulnerability is any vulnerability that has been papered. Technically, a vulnerability should not be deemed known until some authoritative source has acknowledged it. Examples of an authoritative source would be CERT, CIAC, or the vendor. However, you should not cast this in stone. Sometimes, vendors hide from the inevitable. They may know the hole exists, but may stall the publication of it until a fix has been found. Even though such a hole has not been papered, it is an existing, known vulnerability. If it has been circulated within the cracker community, it makes little difference whether the vendor is hiding or not. If crackers have started using the hole to exploit systems, and if the first case of this activity has been reported to a security group, the hole is real and known.
Situations like this do arise, and you can identify them. They usually surface as follows: An individual system administrator whose site has been successfully attacked via the hole independently posts to a security list or newsgroup. That post is vague about the particulars but explains that the vendor was contacted. The post indicates that the vendor said it was working on a fix and an advisory. The individual system administrator then requests information, such as whether anyone has had similar experiences.
In general, your system administrator or security personnel should know about a papered hole within one week of its discovery. That is what they are paid to do: Discover holes and the fixes for them. If your network gets cracked because of an age-old hole that has been papered for more than a year, you have a problem.
Many companies do not pay enough attention to hardware considerations. If you have machines that are located in such a manner that local users can tamper with them, expect trouble. Suppose you use a (fictional) operating system called the BOG operating system. (I hope no such operating system exists. If it does, I apologize. I have not heard of the BOG system, in any case.) Figure 23.1 shows the construction of this fictional operating system.
FIGURE 23.1.
The fictional BOG system network.
This figure shows a three-station network consisting of a server and two workstations. Suppose the BOG operating system has strong access control; the access control is so strong that the user on Workstation 2 (who has high access privileges) has files located on the drive of Workstation 1. These files can be accessed only by Workstation 2 or root. In other words, a portion of Workstation 1's drive is owned by Workstation 2 and root.
Say Workstation 1 operates on a SCSI drive that is attached to an adapter (or even on board, if you like). The system administrator has installed software that prevents any user from booting from a floppy disk. The SCSI disk is attached to the desk via a locking device (these are common. I see a lot of them on Mac networks). The BOG operating system boots directly to a login prompt, and the local single user password has been disabled. It's a pretty tight setup.
Now suppose Workstation 1 is located in a room on its own. Well, that's it then; all the security measures are for naught. The user can tamper with the equipment without fear of being discovered. As long as a user can chain an additional disk to the SCSI adapter, he can circumvent this security. He may not be able to do it using a disk loaded with the BOG operating system, though; he may have to use another. To demonstrate, assume Workstation 1 is running Windows NT. Assume the user brings in a SCSI disk loaded with Linux and changes the SCSI ID numbers so the adapter catches the Linux disk first. No further effort need be made. The Linux disk will boot to a login prompt, and the user logs in as root. At the time of boot, Linux will catch the other partition. The user need only mount the NT partition in the local (Linux) directory of his choice. The Linux user is root, after all. He can do anything. A True Story: The system administrator for a Windows for Workgroups network with third-party access control installed was baffled by changes in the file system. He had a logging utility, but the logs showed very little activity that could be deemed suspicious. After a few weeks, the system administrator placed a bogus database file in a directory and waited for someone to take the bait. The database file had a password to another portion of the network, where a few old, tired NetWare legacy machines were located. On the Novell box in question, the system administrator logged heavily. Evidence surfaced that someone had indeed logged in using the bait ID, but for whatever reason, the system administrator could not determine the identity of the user.
Here comes the good part: I get called in on a Sunday morning to take a look. After hours of trying to determine the problem, I discovered a hidden directory on one machine. In that directory were several files, including gzip.exe and rawrite, and a hidden batch file. In the batch file were commands to load a Linux file system. After seeing this, I rebooted the machine and went into CMOS. Then, I proceeded to kick myself several times. CMOS reported a second disk. I rebooted again and ran the hidden batch file. This immediately caused Linux to begin loading on the second disk. Apparently, the user had found adequate time to lift the cover and install a second IDE hard disk drive. Naturally, Windows didn't see the second disk because the file system was exotic (at least, exotic to Windows). During lunch hours (or other available times), the user would load Linux and roam a while. Bizarre.
For those of you who care: The employee was using a Slackware version of Linux. That file system was crawling with many different files plundered from the network. You may wondering how we, without having root, managed to peruse this disk. Make a note: Always carry boot disks. They are the modern equivalent of a bazooka. Any type of software that will circumvent the security of your system can effectively be put on or within proximity of your system in a manner sufficient to produce that breach. For example, suppose you have removed the floppy disk drive so that no one can load software. Safe or not? No. If your operating system carries native drivers for multiple devices, you have a problem. Perhaps another SCSI drive can be introduced. Perhaps a Zip drive can be introduced.
TIP: On networks that use some form of DOS, Plan 9 will soon become a likely hidden operating system. It is especially useful because the basic distribution is so small. It would also be popular because the system is exotic and not easily manipulated by a neophyte, even if he stumbles across it. Most PC users wouldn't know what they were looking at.However, for a cracker to implement this, he must either introduce a second disk or he must introduce Plan 9 when the workstation is established (for example, when the DOS installation occurs). The only other possibility is if he has adequate space to transfer the contents of the drive temporarily while he re-partitions and installs Plan 9. Depending on the speed of the network, drives, and processor, this could be done in a reasonable amount of time. Detecting this could be a problem if the cracker is skilled. The most reliable way would be to check the partition table or compare the reported size of the disk with the actual size.
Even if the native drivers do not exist, as long as you offer your users access to the Internet, they can get that software in. For example, many systems may not natively support a Zip interface, but iomega has a site with drives for all sorts of systems. Here, even the existence of a serial port is a security risk.
Access to the Internet for local users presents such a wide range of security problems, it would be difficult to fix on one particular thing. Security in this situation is a two-way street. For example, you don't necessarily have to have your network compromised. It could be your hard work instead. Here is a post to the mailing list maintained at firewalls@GreatCircle.COM. The author was a system administrator responsible for information security, and the date of the post was Friday, March 28, 1997. The author writes:
For crackers, that is the beauty of the Internet. The best way to get through a firewall is to have someone inside send out the necessary information. I know individuals who have taken passwords and other information from companies this way. Typically, one member gets a contract (or a temp job) working inside. He shoots out information that could not be easily acquired in any other way through the firewall. One group I know did it to Pacific Bell. Another did it to Chevron. These are not your average Mom and Pop outfits.
One thing that can at least stop these internal thieves from moving your valuable data out is Secure Computing Corporation's Secure Network Server (SNS). This National Security Agency-approved module filters e-mail. The system employs proprietary technology and, according to documentation provided by Secure Computing Corporation, the system
Cross Reference: Check out SNS online at http://www.nsa.gov:8080/programs/missi/scc_sns.html. It's awesome.
Indeed, there are problems even if your local users are not actively trying to crack your system. They may be cruising the Net as part of their job, not realizing that some valuable or proprietary information has inadvertently slipped out of your network. One example is the recent Shockwave controversy. It was recently learned that Shockwave can be used to breach the security of networks cruising a page:
Cross Reference: The previous paragraph is excerpted from an article by David de Vitry, titled "Shockwave Can Read User's Email." It was originally posted online at http://www.webcomics.com/shockwave/, and can also be found at http://www.ntsecurity.net/.
A remote local user is a user who possesses an account on your system but has no physical access to it. In some respect, we are all remote local users because we have accounts on boxes located within the offices of our ISPs. That is, we are local because we are logged to the system and have a user ID and a password, but we are physically remote to the box itself.
This is now becoming more common on private networks and is no longer simply an issue for ISPs and software development firms. People all over the country (even the world) are now doing much of their work at home or on the road. I, for one, haven't seen the inside of an office for over two years. Indeed, this entire book was authored, submitted, and edited without me ever meeting my editors; all of it was done over the Internet. Large firms now have their employees telecommute on a regular basis. AT&T, for example, reported that in 1994, over 22,500 of its employees worked at home.
A recent report titled "Two Years Later A Report on the State of Telecommuting" was released on the subject. A sample of at least 13 Fortune 500 companies revealed that formal telecommuting agreements between firms and employees were exceedingly common:
Cross Reference: "Two Years Later A Report on the State of Telecommuting" (1996, Smart Valley, Inc.) can be found online at http://www.svi.org/PROJECTS/TCOMMUTE/telrpt.pdf.
Most of these telecommuters are logging into some type of server. These are what I would characterize as remote local users. Naturally, these users will probably have less power at a remote terminal than they would at their own. However, this is not always the case. Much depends on the software they are using to connect. If the software is identical to what they would be using without telecommuting, then yes, they will have essentially the same power as they would if they were sitting right in front of the server at the office.
Whether a user is a local user or a remote local user, his basic attack will be pretty much the same. The only tactical advantage that a true local user has is that he can manipulate hardware and perhaps gain access to certain tools that cannot be used remotely.
Examples of such tools include any X applications. Although X applications can be maintained nicely over the Internet, this is rarely done in practice. First, it is a security risk; second, the client's transmission speed is usually insufficient (if the remote user is cruising with a 28.8 modem). The same can be said for running Windows or Windows NT over the Internet. Unless you have at least an ISDN at both ends, it's not worth the trouble. True, some applications--notably those designed by Microsoft--only move the underlying data as opposed to all that graphical material, but the larger portion of applications aren't designed that way.
NOTE: Note that a user's remoteness in no way alters his capability to use development tools that support a CLI.
Much depends on your topology and what the cracker is after. There are certain situations in which even the cracker's user status may not assist him in taking a direct route (a direct route being that of logging into his workstation at work and marching off from that point throughout the network). In these instances, even a semi-privileged user may have to come in using the same techniques as an attacker without an account. This typically occurs when the cracker is seeking access to a network segment in which he does not belong.
No matter what platform you use, the only cure for these types of intrusions is to log heavily. Because these users have at least some level of access, there is a good chance that you might not be able to easily discern an attack. Remember what I said earlier: They have a reason and a right to be there. The following sections introduce some tools that might assist you in preventing (or at worst, recording) an internal intrusion.
The Kane Security Monitor is available for Windows NT, and a sister application is available for Novell NetWare. The Kane system is extremely flexible, offering system administrators the ability to define their own security events. That is, you can assign significance to a wide range of events that might occur that, in your opinion, constitute a security breach. (This is in some ways the equivalent of the access control alarm model available in VMS.) As reported by Intrusion Detection, Inc., the company that developed the software:
Cross Reference: Find the paper from which the preceding paragraph is excerpted at http://www.intrusion.com/ksm.htm.
A fully functional trial version is available at
Using Windows 95, are we? Try NetXRay by CINCO. This truly is a well-coded package. It allows monitoring of multiple network segments, and supports multiple instances of the monitor and capture (and analysis) of just about any type of packet you can dream of. What's more, you can take it for a test drive (but it will only record a handful of packets; it's only a demo). To do so, point your browser here:
LANWatch Network Analyzer for DOS is a well-coded utility that provides over 400 separate filters for LAN traffic. Moreover, LANWatch screens provide color coding of all events and statistics. It has facilities for ongoing, real-time monitoring as well as snapshots for close examination of a particular event. It also runs on very, very low overhead. Requirements are DOS 3.3 and 512KB. This is an ideal tool for DOS-based network management or for anyone trying to code a utility to run over a network. If you are writing a custom network application for a DOS network, you can verify the efficacy of the application using LANWatch by watching your code in action. Information on LANWatch can be obtained here:
inftp.pl is a Perl script that records incoming FTP sessions. It was written by Stephen Northcutt, a system administrator on a military network. Northcutt is the developer of a few finely coded utilities. This utility (perhaps used in conjunction with another from Northcutt, called inpattern.pl) allows you to incisively log FTP traffic. The combination of the two utilities results in logs that trap specific events or patterns. Both are available at the location listed here, as is a document authored by Northcutt titled "What Do Castles Have in Common with Corporate Networks?" The document offers a brief (but surprisingly clear) treatment of firewalls. Northcutt provides some good links in the meantime. The scripts are here:
SWATCH (the name is derived from the term system watcher) is a popular utility created by Stephen Hansen and Todd Atkins at Stanford. To get a closer look at what a SWATCH record looks like, you should go to Stephen Northcutt's site. He has a log posted here:
The cool thing about SWATCH is that it can handle many systems. It is a quick and painless way to integrate the merging of data from the syslog utilities of several machines. SWATCH is available here:
NOCOL, which is for UNIX systems, monitors traffic on the network. It is a big package and has many important features. It uses a standard Curses-based interface, but has support for additional Perl modules written by the user. (It even has a Perl interface. Appropriately enough, it is called PerlNOCOL.) Authored by Vikas Aggarwal and released in late 1994, NOCOL is not something you can set up in 10 minutes. This is a complex and complete package, with separate monitors for each different interface. Check it out here:
NeTraMet is an interesting utility. It is a bit dated, but it works nicely and supports both PCs and SunOS. The distribution comes with source for both SunOS and IRIX, as well as pre-built executables for DOS. You can also obtain the source for the PC version if desired. (This is a rules-based filter and analysis tool. Be forewarned, however, that the documentation is in PostScript. Get an interpreter.) NeTraMet is here:
Internal network breaches are far more common than you think. The problem is, they are not reported as fastidiously as other types of cracking activity. This is due primarily to the need for corporate secrecy. Many in-house crackers are caught and simply discharged with little fanfare.
In past years, internal network security has been a concern primarily for large institutions or corporations. However, the rise of the personal computer changed that climate. Today, most businesses have some form of network. Thus, even if you maintain a small company, you may want to reevaluate your computer security policies. Disgruntled employees account for a high percentage of internal damage and theft of proprietary data. You should have some form of protection and--if possible--a disaster recovery plan.
A Guide to Understanding Data Remanence in Automated Information Systems. NCSC-TG-025 Library No. 5-236,082. Version 2.
Erased Files Often Aren't. M.R. Anderson. Government Technology Magazine, January, 1997.
Computer Crime: Tips on Securing and Recovering Electronic Data. Richard K. Moher. Law Journal Extra and Law Technology Product News, originally published by New York Law Publishing Company.
CIAC Bulletin G-45: Vulnerability in HP VUE.
Some Remarks on Protecting Weak Secrets and Poorly Chosen Keys from Guessing Attacks. Gene Tsudik and Els Van Herreweghen.
CERT Guidelines for Responding to a Root Compromise on a UNIX System. Version 2.0, March 1996.
Running a Secure Server. Lincoln D. Stein. Whitehead Institute/MIT Center for Genome Research.
Securing Internet Information Servers. CIAC 2308.
UNIX Incident Guide How to Detect an Intrusion. CIAC-2305.
CERT(sm) Coordination Center Generic Security Information. January 1995.
Implementation of a Discretionary Access Control Model for Script-Based Systems. T. Jaeger and A. Prakash. 8th IEEE Computer Security Foundations Workshop, 1995.
The Distributed Compartment Model for Resource Management and Access Control Technical Report. Steven J. Greenwald and Richard E. Newman-Wolfe. University of Florida, Number TR94-035, 1994.
An Access Model for Shared Interfaces. G. Smith and T. Rodden. Research report. Lancaster University, Computing Department, Number CSCW/8/1994, 1994.
© Copyright, Macmillan Computer Publishing. All rights reserved.