- Email: [email protected]
Auditing the Internet
December
7 996
Network Security
How good do you have to
be? In information protection, the devil, as they say, is in the details, Successful defences tend not to rely on a few clever tricks, They tend to rely on a steady long-term effort at constant improvement and adaption. Being just a little bit
better than the competition is probably not much of a competitive advantage, but every little bit helps. -
About the author Fred Cohen is a senior member of Technical Staff at Sandia National
Auditing the Internet Jon David The audit function is frequently an afterthought in the design and installation of security. The primary goal of security is viewed as the prevention of compromise, and often only after a breach is it realized that existing audit abilities, if at all present, are grossly deficient. Auditlng allows transactions and activities to be tracked - from their point of origin, through intermediate steps, to their final state. Since it is possible to breach any security, an extensive audit ability is necessary to determine how the breach succeeded (i.e. how the intruder/unauthorized user got in) and what damages, if any, were done. While this is true for all systems and networks, it is particularly critical for the Internet. If audit is an afterthought in security design, security itself is an afterthought to Internet operations. Because of the nature of the Internet - the basic design goal is to deliver messages, loose coordination of system administrators, lack of international (or even national) regulation, millions of novice users, etc. - it is easier to compromise the Internet than previous types of systems and networks. This easier compromise demands more and better audit abilities for analysis and evaluation of breaches (and, hopefully, to prevent or at least minimize their number and extent).
01996 Elsevier
Science
Ltd
Laboratories, and a senior partner of Fred Cohen and Associates in Livermore, California, USA, an executive consulting and education group specializing in information protection. He can be reached by sending E-mail to [email protected].
The Air Force undertook a project (OSI, I believe it was called) to try breaking into 705 facilities. Even after extensive break-in attempts, 703 of the 705 did not notice any attacks had been made. Last year I headed a vulnerabilities analysis of a world organization. We had permission to do remote probing prior to the start of on-site work, and had entered and taken over many of their major systems before the official start of our work; our customer not only was unaware of either activities or our accomplishments, but couldn’t find us even after being told we were in there. The top technical representative of that same world organization
later came to us almost hysterical; he claimed to have found many hackers attempting to get into their systems. Examination of the reports he used to come to his conclusions gave us no evidence of any hacking at all. (An extract of this report is given as Figure I.) Later he was equally excited because he found a specific hacker trying to get in from Notre Dame; examination of his information showed that the supposed hacker was actually an in-house employee with a legitimate account at Notre Dame and who was merely trying to use the Notre Dame gopher. The international community of Internet users is in a situation where, in most cases, adequate information is not retained. In the atypical instances where it is retained, it is usually not retained for sufficient periods to be of help in an audit situation. A typical message sent from one user to a second user not serviced by the same Internet service provider (ISP, e.g. Dockmaster, Compuserve, etc.) may transit 30 or so intermediate points getting from Point A to Point B. (The message would go from A(1) to A(2), from A(2) to A(3), ..,, from A(n-1) to A(n), from A(n) to 8.) Each step of this multipoint transmission adds location information to the packets to indicate the transit point. Unless,
11
Network Security
From: Rem Host Device
December 7996
Date
Time
To: Local Host
ttydOp7
94/05/16 13:55:58, ffffffffGabcdds5
ttydOp7
94/05/23 08:58:33, bobc@abcdds5
ttydOp7 94/06/06 09:35:50, sybaseQabcdds5 111.222.1.100 ttyv 94/01/12 111.222.1.100 ttyv 94/01/12 11:48:29, rootQabcdds5 11:48:24, rootBabcdds5 111.222.1.114 pty/ttysO 94/01/03 13:04:09, sybase@abcdfs3 111.222.1.114 pty/ttysl 94/01/18 15:51:58, sybaseBabcdfs3 111.222.163.2 ttyv 94/08/01 01:40:52, guest@abcdds5 111.222.163.2 ttyv 94/08/01 01:40:23, abcd@abcdds5 111.222.163.2 ttys 94/08/09 13:43:51, slavinGabcdds3 111.222.163.2 ttys 94/08/09 13:43:40, sso@abcdds3 111.222.192.2 ttyv 94/06/13 19:48:14, wwQabcdds5 111.222.192.2 ttyv 94/06/13 111.222.43.25 ttys 94/07/15 10:38:18, pennygslBabcdds4 19:48:16, ww@abcdds5 111.222.43.25 ttys 94/07/15 10:38:34, pennygsl@abcdds4 111.222.71.10 pty/ttysO 94/04/20 02:08:20, logout@abcdfs3 111.222.8.237 ttyv 94/01/31 13:21:13, adminGabcdds5 ttyv 94/05/03 16:17:36, odsdba@abcdds5 ODSNYl ODSNYl pty/ttyvl 94/05/03 16:24:50, odsdbaQabcdds5 ODSNYl ttyv 94/05/05 14:52:58, ddd8abcdds5 accnyaal ttyv 94/07/01 17:10:16, rpdnyygl4abcdds5 damnymm2 pty/ttys5 94/03/10 16:34:11, damnymm2 pty/ttys5 94/03/10 16:33:54, sybase@abcdfs3 xyz_hub-2 dc@abcdfs3 pty/ttyvl 94/07/26 12:06:38, rootQabcdds5 xyznyjs2 ttyv 94/06/22 11:14:38, ttyv 94/07/06 19:31:32, xyznymvl@abcdds5 xyznyrcl wwOabcdds5 xyznymvl pty/ttysl 94/03/29 10:02:38, :@abcdfs3 xyznyrcl ttys 94/04/29 19:51:43, asd@abcdds4 ttys 94/04/29 19:51:44, ds4abcdds4 xyznyrcl xyznyrcl ttys 94/04/29 19:37:16, ttys 94/04/29 20:40:25, dsafdsfaoabcdds4 xyznyrcl dsaGabcdds3 xyznyrcl pty/ttysO 94/07/08 17:37:43, sybasde=@abcdfs3 xyznyrc1:O.O ttypl 94/02/15 18:46:30, abcdfs24abcdfs3 xyznyrc1:O.O ttyp4 94/02/15 18:46:37, sdaf@abcdfs3 xyznyscl pty/ttyfO 94/01/19 14:06:17, xyznysclQabcdds3 xyznysc1:O.O pty/ttya3 94/01/20 abcddemo 09:35:04, eoot@abcdds4 pty/ttyvl 94/05/13 17:48:56, xyznyjs2@abcdds5 pty/ttys3 94/01/06 16:10:36, c4abcdfs3 abcddsl abcddsl pty/ttyf2 94/01/06 11:42:14, ste?ress@abcdds4 abcddsl pty/ttysl 94/01/25 17:20:40, tqQabcdfs3 pty/ttysO 94/01/31 13:09:47, sybase@abcdfs3 abcddsl abcddsl ttys 94/02/16 12:00:21, convers@abcdds3 abcddsl pty/ttysO 94/03/09 16:29:44, z@abcdfs3 abcddsl pty/ttysO 94/03/10 11:57:23, user@abcdfs3 abcddsl pty/ttysl 94/03/14 14:26:30, abcddsl ttys 94/08/03 20:47:22, dampwell@abcdds4 abcddsl rootGabcdfs3 ttyv 94/08/03 20:40:17, dampwell@abcdds5 abcddsl pty/ttys3 94/08/12 15:42:29, ?@abcdds3 pty/ttyf2 94/01/07 10:28:45, stress@abcdds3 abcdds2 ttys 94/03/10 abcdds2 abcdds2 12:08:10, root@abcdds3 ttys 94/05/02 10:00:57, ro4abcdds3 abcdds3 pty/ttysO 94/01/18 14:02:44, xyznyscl@abcdfs3 abcdds3 pty/ttysl 94/03/01 15:00:02, pty/ttysO 94/03/01 16:22:38, stress@abcdfs3 abcdds3 stress@abcdfs3 abcdds3 pty/ttysl 94/03/07 09:03:57, michelle@abcdfs3 abcdds3 pty/ttyso 94/05/04 17:51:29, pty/ttysO 94/05/04 17:51:21, root@abcdfs3 xyznyjs2@abcdfs3 abcdds3 abcdds3 ttys 94/05/05 11:00:18, stressQabcdds4 abcdds3 pty/ttysO 94/05/10 10:29:26, rootQabcdfs3 pty/ttysl 94/06/16 03:08:20, rootBabcdfs3 abcdds3 abcdds3 pty/ttys2 94/08/04 11:02:09, xyznyjs2@abcdfs3 abcdfs3 pty/ttys2 94/07/21 18:45:10, root@abcdds3 abcdfs3 ttys 94/08/16 19:34:53, abcdfs3 ttys 94/08/16 19:34:51, wwQabcdds4 pty/ttysO 94/01/05 10:07:18, michelle@abcdfs3 michelle michelle wwQabcdds4 pty/ttyfO 94/01/07 16:53:29, root@abcdds3 michelle pty/ttyfO 94/01/07 16:55:01, ttyv 94/08/06 00:51:34, xyzyykl@abcdds5 nene nene rooMabcdds4 ttyv ttys 94/08/09 13:41:01, dampwlml@abcdds3 94/08/06 01:31:41, proof@abcdds5 nene ttyv 94/08/09 22:44:02, xyznybal@abcdds5 nene ttys 94/08/09 13:41:47, nene prokappaQabcdds3 nnmgr ttyv 94/05/12 16:01:30, smc???es@abcdds5 nnmgr ttyv pennybvl ttys 94/03/17 14:57:20, gal@abcdds4 94/08/10 10:45:35, rootBabcdds5 ttys 94/03/17 14:57:13, ttys 94/03/17 14:57:04, georgeQabcdds4 pennybvl pennybvl ttys 94/06/20 16:20:39, rpdnynal@abcdds4 pennygal@abcdds4 rpdnymkl Figure 7: Hacker (?) Report.
though, each and every one of these intermediate points, points that recognize they are neither the source nor destination of the message, keeps the full transit history (and keeps it for an appropriate time), there will not be a way to track a message back to its true origin (see Figure 2)
12
A few years ago I was phoned by Les Gotch, system administrator at Dockmaster. He’d had a call from system Keith Peterson, simte120, administrator at regarding a posting under my name to a local BBS. He found the posting rather offensive. Les, feeling the posting as reported by
Keith was not my style, checked the Dockmaster audit logs and was able to assure Keith that I hadn’t sent the offending message. In this case I was fortunate in that Dockmaster retains information for a sufficient period that I was ‘covered’ without even getting involved.
01996
Elsevier Science Ltd
December 7996
Network Security
#3 (9 lines in body): Delivery-Date: 21 July 1995 05:21 edt Deliverv-Bv: Network_Server.Daemon ([email protected]@jagor.sr) Date: From: Suzana.Stojakovic-Celustka at Thursday, 21 July 1955 05:19 edt PUBLIC.SRCE.HR (Suzana Stojakovic-Celustka Subject: other Content-Length:
\c - OS Precko) DOCKMASTER.NCSC.MIL
texts 234
To: David
at
#3 (9 lines in body): Delivery-Date: 21 July 1995 05:21 edt Delivery-By: Network_Server.Daemon ([email protected]@jagor.sr) Posted-Date: Sender: Suzana.Stojakovic-Celustka at PUBLIC.SRCE.HR 21 July 1995 05:19 edt (Suzana Stojakovic-Celust \cka - OS Precko) DOCKMASTER.NCSC.MIL July 1995 05:2
Relayed:
\cl edt Suzana.Stojakovic-Celustka
Route: via PUBLIC.SRCE.HR via JAGOR.SRCE.HR via from JAGOR.SRCE.HR to DOCKMASTER.NCSC.MIL with TCP;
Date: Thursday, 21 July 1995 OS:19 edt at PUBLIC.SRCE.HR (Suzana Stojakovic-Celustka
Subject: other texts \c - OS Precko) Access-Class: u DOCKMASTER.NCSC.MIL 7270919.LAAO7295 at JAGOR.SRCE.HR Content-Length:
21
From:
To: David Message-ID:
at
234
1
Figure 2: intermediate This, though, is the rather than the rule.
Points.
exception,
If company A and company B are competitors, company A might send an offensive note to the potential/actual customers of A and B, but send it under company B’s name. Will company B be as fortunate as I was? Similarly, the popularity of the worldwide web (WWW or W3)‘has resulted in many individuals ‘surfing’, i.e. idly or systematically going from place to place, from topic to topic, and both uploading and downloading files. If your organization winds up with a large set of pornographic files, or if your company’s acquisition plans appear on a initial public forum, and investigation suggests employee X requested them, will X, if innocent, be able to obtain proof? If no X is suggested, what can you do? Who’s sending the hate mail? Who’s ordering the expensive goods? Who’s using the expensive toll services? If one has a good understanding of the Internet design and structure, and one then reviews in
01996
Elsevier
Science
Ltd
detail the relevant RFCs (these are the writings on which the Internet design is based), one can find ways to ‘beat the system’, i.e. do such things such as make postings under somebody else’s name, and leave no way to track back to the origin. The knowledge to do this, though, is rare, and even in instances where such is done (and it may not be possible to discover who did something), it will be possible to prove who didn’t initiate a given transmission if proper information is logged, maintained, and able to be displayed in a meaningful manner. Incomplete, inconsistent and sometimes even untrue information may constrain the audit function to sometimes at best being able to disprove an untruth. Lots of times, though, the intelligent logging and presentation of appropriate information can be of major help in many ways, The Internet is imperfect in many ways, and the availability of proper audit information is certainly one of them. This, of course, is complicated by the lack
of expertise of many system administrators. (Remember, there are tens of thousands of hosts involved in Internet transmissions.) Unlike Dockmaster (dockmaster. ncscmil), most of them do not have security as a top priority item, and their system administrators are orientated elsewhere to increased services, to more reliable message throughput, whatever. There are, however, things that can be done. Users that are worried about the confidentiality of individual messages can encrypt them. PGP (Pretty Good Encryption) is free and available via ftp sites on the Internet. As a public key encryption package, it not only keeps message contents private from all but the authorized recipient, it indicates if any message tampering has been done. Further, it allows users to ‘sign’ messages without encrypting them, again indicating if any changes to messages have been made in transit. Since a feature of public key cryptography is certification of both sender and recipient, it offers
13
Network Security
significant protection when audit sequence fails. Message numbering, special handshaking protocols and the like can be used to certify the delivery and receipt of messages sent. As for the audit function itself, users that want or require it (which should be all users, but it may take a disaster to convince them of this) should insist their ISP log and retain appropriate information, and switch ISPs if this is not done. Organizational users with their own system administrators must create and maintain the logs themselves (although some vendor software is often available with the routers, firewalls, etc. being used by the organization). The important thing to do in these cases is to make reported information meaningful, and not subject to easy misinterpretation. There are no formal standards for this, so what gets done, and how it gets done, individual to the is up organizations wanting proper
December
audit abilities. Since transaction audits can suggest potential problems before they become serious, and since potential problems tend to become actual problems unless they’re caught in time, this use of audit as a preventive, rather than detective, tool is very important. “Log everything” is good advice, but it is merely a start. The information must be available on demand to track events - back to discover their origin, and forward to assess their impact. It must also be regularly, even possibly automatically, presented to allow (or designate) discovery of atypical situations (transmissions to and from unusual locations, repeated connection attempts, connections or even connection attempts to sockets not normally used, etc.). It is vital that these information displays be meaningful and not subject to misinterpretation, This, however, goes beyond aesthetics and
Real World Anti-virus Product Reviews and Evaluations - Part 1 Sarah Gordon and Richard Ford This article discusses frequently encountered errors in the evaluation process relative to anti-virus software selection by examining some of the methods commonly used by corporate and governmental personnel working in the area of Management Information Systems (MIS). In addition to discussing inherent problems, we will suggest alternative methodologies for evaluation. We will examine commercial certification processes, as well as the Information Technology Security Evaluation and Certification (ITSEC) approach, as possible models for anti-virus product evaluation and certlflcation. Finally, we will discuss ways in which the information which is currently available may be used to help select anti-virus software which is both functional and cost efficient.
14
7 996
formatting, and involves the abilities and training of system administrators and incident response teams. (Not every atypical event is a hack or even a misuse.) The audit information, though, is the critical element. Until the day that, forgetting various national laws throughout the world, Internet transmissions are automatically encrypted end-to-end via a means that will certify sender, recipient, delivery and receipt, audit will be a vital part of determining when intrusion attempts are being made, discovering how intrusions were made, and seeing what effects were made by intrusions. Audit is not a de facto component of Internet operations, and it is up to users, via their ISPs and/or their in-house system administrations staffs, to devise and utilize a proper audit function.
Introduction The evaluation of anti-virus software is not adequately covered by any existing criteria based on formal methods. The process, therefore, has been carried out by various personnel using a variety of tools and methods. Some of these tools and methods should be part of the evaluation process; others can provide misleading or damaging information resulting in increased exposure to computer viruses. Areas of the evaluation which are relatively straightforward include the elimination of products which for your unsuitable are environment, the cost of the software, comparison of vendor pricing policies and licensing assessing conditions and compatibility requirements, In all
01996
Elsevier Science Ltd
7 996
Network Security
How good do you have to
be? In information protection, the devil, as they say, is in the details, Successful defences tend not to rely on a few clever tricks, They tend to rely on a steady long-term effort at constant improvement and adaption. Being just a little bit
better than the competition is probably not much of a competitive advantage, but every little bit helps. -
About the author Fred Cohen is a senior member of Technical Staff at Sandia National
Auditing the Internet Jon David The audit function is frequently an afterthought in the design and installation of security. The primary goal of security is viewed as the prevention of compromise, and often only after a breach is it realized that existing audit abilities, if at all present, are grossly deficient. Auditlng allows transactions and activities to be tracked - from their point of origin, through intermediate steps, to their final state. Since it is possible to breach any security, an extensive audit ability is necessary to determine how the breach succeeded (i.e. how the intruder/unauthorized user got in) and what damages, if any, were done. While this is true for all systems and networks, it is particularly critical for the Internet. If audit is an afterthought in security design, security itself is an afterthought to Internet operations. Because of the nature of the Internet - the basic design goal is to deliver messages, loose coordination of system administrators, lack of international (or even national) regulation, millions of novice users, etc. - it is easier to compromise the Internet than previous types of systems and networks. This easier compromise demands more and better audit abilities for analysis and evaluation of breaches (and, hopefully, to prevent or at least minimize their number and extent).
01996 Elsevier
Science
Ltd
Laboratories, and a senior partner of Fred Cohen and Associates in Livermore, California, USA, an executive consulting and education group specializing in information protection. He can be reached by sending E-mail to [email protected].
The Air Force undertook a project (OSI, I believe it was called) to try breaking into 705 facilities. Even after extensive break-in attempts, 703 of the 705 did not notice any attacks had been made. Last year I headed a vulnerabilities analysis of a world organization. We had permission to do remote probing prior to the start of on-site work, and had entered and taken over many of their major systems before the official start of our work; our customer not only was unaware of either activities or our accomplishments, but couldn’t find us even after being told we were in there. The top technical representative of that same world organization
later came to us almost hysterical; he claimed to have found many hackers attempting to get into their systems. Examination of the reports he used to come to his conclusions gave us no evidence of any hacking at all. (An extract of this report is given as Figure I.) Later he was equally excited because he found a specific hacker trying to get in from Notre Dame; examination of his information showed that the supposed hacker was actually an in-house employee with a legitimate account at Notre Dame and who was merely trying to use the Notre Dame gopher. The international community of Internet users is in a situation where, in most cases, adequate information is not retained. In the atypical instances where it is retained, it is usually not retained for sufficient periods to be of help in an audit situation. A typical message sent from one user to a second user not serviced by the same Internet service provider (ISP, e.g. Dockmaster, Compuserve, etc.) may transit 30 or so intermediate points getting from Point A to Point B. (The message would go from A(1) to A(2), from A(2) to A(3), ..,, from A(n-1) to A(n), from A(n) to 8.) Each step of this multipoint transmission adds location information to the packets to indicate the transit point. Unless,
11
Network Security
From: Rem Host Device
December 7996
Date
Time
To: Local Host
ttydOp7
94/05/16 13:55:58, ffffffffGabcdds5
ttydOp7
94/05/23 08:58:33, bobc@abcdds5
ttydOp7 94/06/06 09:35:50, sybaseQabcdds5 111.222.1.100 ttyv 94/01/12 111.222.1.100 ttyv 94/01/12 11:48:29, rootQabcdds5 11:48:24, rootBabcdds5 111.222.1.114 pty/ttysO 94/01/03 13:04:09, sybase@abcdfs3 111.222.1.114 pty/ttysl 94/01/18 15:51:58, sybaseBabcdfs3 111.222.163.2 ttyv 94/08/01 01:40:52, guest@abcdds5 111.222.163.2 ttyv 94/08/01 01:40:23, abcd@abcdds5 111.222.163.2 ttys 94/08/09 13:43:51, slavinGabcdds3 111.222.163.2 ttys 94/08/09 13:43:40, sso@abcdds3 111.222.192.2 ttyv 94/06/13 19:48:14, wwQabcdds5 111.222.192.2 ttyv 94/06/13 111.222.43.25 ttys 94/07/15 10:38:18, pennygslBabcdds4 19:48:16, ww@abcdds5 111.222.43.25 ttys 94/07/15 10:38:34, pennygsl@abcdds4 111.222.71.10 pty/ttysO 94/04/20 02:08:20, logout@abcdfs3 111.222.8.237 ttyv 94/01/31 13:21:13, adminGabcdds5 ttyv 94/05/03 16:17:36, odsdba@abcdds5 ODSNYl ODSNYl pty/ttyvl 94/05/03 16:24:50, odsdbaQabcdds5 ODSNYl ttyv 94/05/05 14:52:58, ddd8abcdds5 accnyaal ttyv 94/07/01 17:10:16, rpdnyygl4abcdds5 damnymm2 pty/ttys5 94/03/10 16:34:11, damnymm2 pty/ttys5 94/03/10 16:33:54, sybase@abcdfs3 xyz_hub-2 dc@abcdfs3 pty/ttyvl 94/07/26 12:06:38, rootQabcdds5 xyznyjs2 ttyv 94/06/22 11:14:38, ttyv 94/07/06 19:31:32, xyznymvl@abcdds5 xyznyrcl wwOabcdds5 xyznymvl pty/ttysl 94/03/29 10:02:38, :@abcdfs3 xyznyrcl ttys 94/04/29 19:51:43, asd@abcdds4 ttys 94/04/29 19:51:44, ds4abcdds4 xyznyrcl xyznyrcl ttys 94/04/29 19:37:16, ttys 94/04/29 20:40:25, dsafdsfaoabcdds4 xyznyrcl dsaGabcdds3 xyznyrcl pty/ttysO 94/07/08 17:37:43, sybasde=@abcdfs3 xyznyrc1:O.O ttypl 94/02/15 18:46:30, abcdfs24abcdfs3 xyznyrc1:O.O ttyp4 94/02/15 18:46:37, sdaf@abcdfs3 xyznyscl pty/ttyfO 94/01/19 14:06:17, xyznysclQabcdds3 xyznysc1:O.O pty/ttya3 94/01/20 abcddemo 09:35:04, eoot@abcdds4 pty/ttyvl 94/05/13 17:48:56, xyznyjs2@abcdds5 pty/ttys3 94/01/06 16:10:36, c4abcdfs3 abcddsl abcddsl pty/ttyf2 94/01/06 11:42:14, ste?ress@abcdds4 abcddsl pty/ttysl 94/01/25 17:20:40, tqQabcdfs3 pty/ttysO 94/01/31 13:09:47, sybase@abcdfs3 abcddsl abcddsl ttys 94/02/16 12:00:21, convers@abcdds3 abcddsl pty/ttysO 94/03/09 16:29:44, z@abcdfs3 abcddsl pty/ttysO 94/03/10 11:57:23, user@abcdfs3 abcddsl pty/ttysl 94/03/14 14:26:30, abcddsl ttys 94/08/03 20:47:22, dampwell@abcdds4 abcddsl rootGabcdfs3 ttyv 94/08/03 20:40:17, dampwell@abcdds5 abcddsl pty/ttys3 94/08/12 15:42:29, ?@abcdds3 pty/ttyf2 94/01/07 10:28:45, stress@abcdds3 abcdds2 ttys 94/03/10 abcdds2 abcdds2 12:08:10, root@abcdds3 ttys 94/05/02 10:00:57, ro4abcdds3 abcdds3 pty/ttysO 94/01/18 14:02:44, xyznyscl@abcdfs3 abcdds3 pty/ttysl 94/03/01 15:00:02, pty/ttysO 94/03/01 16:22:38, stress@abcdfs3 abcdds3 stress@abcdfs3 abcdds3 pty/ttysl 94/03/07 09:03:57, michelle@abcdfs3 abcdds3 pty/ttyso 94/05/04 17:51:29, pty/ttysO 94/05/04 17:51:21, root@abcdfs3 xyznyjs2@abcdfs3 abcdds3 abcdds3 ttys 94/05/05 11:00:18, stressQabcdds4 abcdds3 pty/ttysO 94/05/10 10:29:26, rootQabcdfs3 pty/ttysl 94/06/16 03:08:20, rootBabcdfs3 abcdds3 abcdds3 pty/ttys2 94/08/04 11:02:09, xyznyjs2@abcdfs3 abcdfs3 pty/ttys2 94/07/21 18:45:10, root@abcdds3 abcdfs3 ttys 94/08/16 19:34:53, abcdfs3 ttys 94/08/16 19:34:51, wwQabcdds4 pty/ttysO 94/01/05 10:07:18, michelle@abcdfs3 michelle michelle wwQabcdds4 pty/ttyfO 94/01/07 16:53:29, root@abcdds3 michelle pty/ttyfO 94/01/07 16:55:01, ttyv 94/08/06 00:51:34, xyzyykl@abcdds5 nene nene rooMabcdds4 ttyv ttys 94/08/09 13:41:01, dampwlml@abcdds3 94/08/06 01:31:41, proof@abcdds5 nene ttyv 94/08/09 22:44:02, xyznybal@abcdds5 nene ttys 94/08/09 13:41:47, nene prokappaQabcdds3 nnmgr ttyv 94/05/12 16:01:30, smc???es@abcdds5 nnmgr ttyv pennybvl ttys 94/03/17 14:57:20, gal@abcdds4 94/08/10 10:45:35, rootBabcdds5 ttys 94/03/17 14:57:13, ttys 94/03/17 14:57:04, georgeQabcdds4 pennybvl pennybvl ttys 94/06/20 16:20:39, rpdnynal@abcdds4 pennygal@abcdds4 rpdnymkl Figure 7: Hacker (?) Report.
though, each and every one of these intermediate points, points that recognize they are neither the source nor destination of the message, keeps the full transit history (and keeps it for an appropriate time), there will not be a way to track a message back to its true origin (see Figure 2)
12
A few years ago I was phoned by Les Gotch, system administrator at Dockmaster. He’d had a call from system Keith Peterson, simte120, administrator at regarding a posting under my name to a local BBS. He found the posting rather offensive. Les, feeling the posting as reported by
Keith was not my style, checked the Dockmaster audit logs and was able to assure Keith that I hadn’t sent the offending message. In this case I was fortunate in that Dockmaster retains information for a sufficient period that I was ‘covered’ without even getting involved.
01996
Elsevier Science Ltd
December 7996
Network Security
#3 (9 lines in body): Delivery-Date: 21 July 1995 05:21 edt Deliverv-Bv: Network_Server.Daemon ([email protected]@jagor.sr) Date: From: Suzana.Stojakovic-Celustka at Thursday, 21 July 1955 05:19 edt PUBLIC.SRCE.HR (Suzana Stojakovic-Celustka Subject: other Content-Length:
\c - OS Precko) DOCKMASTER.NCSC.MIL
texts 234
To: David
at
#3 (9 lines in body): Delivery-Date: 21 July 1995 05:21 edt Delivery-By: Network_Server.Daemon ([email protected]@jagor.sr) Posted-Date: Sender: Suzana.Stojakovic-Celustka at PUBLIC.SRCE.HR 21 July 1995 05:19 edt (Suzana Stojakovic-Celust \cka - OS Precko) DOCKMASTER.NCSC.MIL July 1995 05:2
Relayed:
\cl edt Suzana.Stojakovic-Celustka
Route: via PUBLIC.SRCE.HR via JAGOR.SRCE.HR via from JAGOR.SRCE.HR to DOCKMASTER.NCSC.MIL with TCP;
Date: Thursday, 21 July 1995 OS:19 edt at PUBLIC.SRCE.HR (Suzana Stojakovic-Celustka
Subject: other texts \c - OS Precko) Access-Class: u DOCKMASTER.NCSC.MIL 7270919.LAAO7295 at JAGOR.SRCE.HR Content-Length:
21
From:
To: David Message-ID:
at
234
1
Figure 2: intermediate This, though, is the rather than the rule.
Points.
exception,
If company A and company B are competitors, company A might send an offensive note to the potential/actual customers of A and B, but send it under company B’s name. Will company B be as fortunate as I was? Similarly, the popularity of the worldwide web (WWW or W3)‘has resulted in many individuals ‘surfing’, i.e. idly or systematically going from place to place, from topic to topic, and both uploading and downloading files. If your organization winds up with a large set of pornographic files, or if your company’s acquisition plans appear on a initial public forum, and investigation suggests employee X requested them, will X, if innocent, be able to obtain proof? If no X is suggested, what can you do? Who’s sending the hate mail? Who’s ordering the expensive goods? Who’s using the expensive toll services? If one has a good understanding of the Internet design and structure, and one then reviews in
01996
Elsevier
Science
Ltd
detail the relevant RFCs (these are the writings on which the Internet design is based), one can find ways to ‘beat the system’, i.e. do such things such as make postings under somebody else’s name, and leave no way to track back to the origin. The knowledge to do this, though, is rare, and even in instances where such is done (and it may not be possible to discover who did something), it will be possible to prove who didn’t initiate a given transmission if proper information is logged, maintained, and able to be displayed in a meaningful manner. Incomplete, inconsistent and sometimes even untrue information may constrain the audit function to sometimes at best being able to disprove an untruth. Lots of times, though, the intelligent logging and presentation of appropriate information can be of major help in many ways, The Internet is imperfect in many ways, and the availability of proper audit information is certainly one of them. This, of course, is complicated by the lack
of expertise of many system administrators. (Remember, there are tens of thousands of hosts involved in Internet transmissions.) Unlike Dockmaster (dockmaster. ncscmil), most of them do not have security as a top priority item, and their system administrators are orientated elsewhere to increased services, to more reliable message throughput, whatever. There are, however, things that can be done. Users that are worried about the confidentiality of individual messages can encrypt them. PGP (Pretty Good Encryption) is free and available via ftp sites on the Internet. As a public key encryption package, it not only keeps message contents private from all but the authorized recipient, it indicates if any message tampering has been done. Further, it allows users to ‘sign’ messages without encrypting them, again indicating if any changes to messages have been made in transit. Since a feature of public key cryptography is certification of both sender and recipient, it offers
13
Network Security
significant protection when audit sequence fails. Message numbering, special handshaking protocols and the like can be used to certify the delivery and receipt of messages sent. As for the audit function itself, users that want or require it (which should be all users, but it may take a disaster to convince them of this) should insist their ISP log and retain appropriate information, and switch ISPs if this is not done. Organizational users with their own system administrators must create and maintain the logs themselves (although some vendor software is often available with the routers, firewalls, etc. being used by the organization). The important thing to do in these cases is to make reported information meaningful, and not subject to easy misinterpretation. There are no formal standards for this, so what gets done, and how it gets done, individual to the is up organizations wanting proper
December
audit abilities. Since transaction audits can suggest potential problems before they become serious, and since potential problems tend to become actual problems unless they’re caught in time, this use of audit as a preventive, rather than detective, tool is very important. “Log everything” is good advice, but it is merely a start. The information must be available on demand to track events - back to discover their origin, and forward to assess their impact. It must also be regularly, even possibly automatically, presented to allow (or designate) discovery of atypical situations (transmissions to and from unusual locations, repeated connection attempts, connections or even connection attempts to sockets not normally used, etc.). It is vital that these information displays be meaningful and not subject to misinterpretation, This, however, goes beyond aesthetics and
Real World Anti-virus Product Reviews and Evaluations - Part 1 Sarah Gordon and Richard Ford This article discusses frequently encountered errors in the evaluation process relative to anti-virus software selection by examining some of the methods commonly used by corporate and governmental personnel working in the area of Management Information Systems (MIS). In addition to discussing inherent problems, we will suggest alternative methodologies for evaluation. We will examine commercial certification processes, as well as the Information Technology Security Evaluation and Certification (ITSEC) approach, as possible models for anti-virus product evaluation and certlflcation. Finally, we will discuss ways in which the information which is currently available may be used to help select anti-virus software which is both functional and cost efficient.
14
7 996
formatting, and involves the abilities and training of system administrators and incident response teams. (Not every atypical event is a hack or even a misuse.) The audit information, though, is the critical element. Until the day that, forgetting various national laws throughout the world, Internet transmissions are automatically encrypted end-to-end via a means that will certify sender, recipient, delivery and receipt, audit will be a vital part of determining when intrusion attempts are being made, discovering how intrusions were made, and seeing what effects were made by intrusions. Audit is not a de facto component of Internet operations, and it is up to users, via their ISPs and/or their in-house system administrations staffs, to devise and utilize a proper audit function.
Introduction The evaluation of anti-virus software is not adequately covered by any existing criteria based on formal methods. The process, therefore, has been carried out by various personnel using a variety of tools and methods. Some of these tools and methods should be part of the evaluation process; others can provide misleading or damaging information resulting in increased exposure to computer viruses. Areas of the evaluation which are relatively straightforward include the elimination of products which for your unsuitable are environment, the cost of the software, comparison of vendor pricing policies and licensing assessing conditions and compatibility requirements, In all
01996
Elsevier Science Ltd