SUPER WORM ANALYSIS MECHANISM Prof Jerry Breecher SWAMI

SUPER WORM ANALYSIS MECHANISM Prof. Jerry Breecher SWAMI 1

MARKETING REQUIREMENTS DOCUMENT PRODUCT MOTIVATION This document describes the need for a product that will detect suspicious and foreign processes running on Super Computer Company Hardware. Recent events in the UNIX world have shown that undesirable elements can run amok when given unlimited processing power. SCC customers have expressed great concern that their machines may be attacked by such a mechanism. SWAMI 2

MARKETING REQUIREMENTS DOCUMENT PRODUCT DESCRIPTION/REQUIREMENTS To meet this need, it is proposed that SCC Engineering undertake a project to produce SWAMI, the Super Worm Analysis Mechan. Ism. 1. SWAMI should be able to detect the presence of a foreign process before it has done serious damage to the SCC machines. The procedure for doing this is currently undefined and will be determined by engineering. 2. SWAMI should be a standalone package, requiring no other SCC software. 3. SWAMI should require no user interaction during normal operation; only in the case of intruder detection should interaction be necessary. 4. Intruder detection should be signaled in an auditory and/or visual and/or sensual fashion. SWAMI 3

MARKETING REQUIREMENTS DOCUMENT PRODUCT DESCRIPTION/REQUIREMENTS 5. The intruder must be detected before damage can occur. 6. Although SWAMI is continually monitoring, it is essential that it use less than 5% of the CPU on the machine; less than 1% would be ideal. 7. The time from intruder detection to alert received must be less than 5 seconds. 8. The time from intruder detection to termination of intruder must be such that the intruder can do no damage. 9. The amount of memory/disk/other resources used must be ½ that of the competition. 10. The number of false alarms/month allowed is 0. SWAMI 4

MARKETING REQUIREMENTS DOCUMENT COMPETITION: The_Competition has recently introduced its TGIF system (The_Competition Guts Intruders Fast ). The_Competition customers have expressed satisfaction with the functionality (no intruders have been reported in the first three months of operation. ) These same customers have not been happy with performance however; hearsay evidence has it that TGIF can require up to 10% additional CPU power on a The_Competition system. The_Competition is reportedly planning a performance release to address customer concerns. SWAMI 5

PROJECT PLAN DESCRIPTION OF PROJECT COSTS DO NOT READ AHEAD UNTIL YOU HAVE COMPLETED THE EXERCISE FOR THE MRD SWAMI 6

FUNCTIONAL SPECIFICATION FUNCTIONAL DESCRIPTION: In order to keep monitoring activity to a minimum, the legality of a program is verified when a program is first executed. This is a one-time verification cost and was chosen over the more costly mechanism of scanning/verifying all processes at fixed time intervals. Legality of a program to run on a particular system is given at either link time or via a "legalize_executable" command. In other words, an executable becomes legal on a system either by virtue of having been linked on that system or by being imported and then "legalized" by an authorized individual. SWAMI 7

FUNCTIONAL SPECIFICATION GURU: GURU (Global Universal Resource Unit) is a distributed server, running on all machines of a system. It is responsible for: Maintaining and protecting a 100 -byte unique hardware number, common to all machines in the system. Producing a magic number that is placed in the program image file at link or "legalize_executable" time. Verifying that the magic number in a program image is OK. SWAMI 8

FUNCTIONAL SPECIFICATION VARIOUS DETAILS: Communication with GURU is via a pipe. Set up this pipe with GURU using open_pipe on the file >system>guru_pipe_file. When a machine comes on line within a system, a mechanism is provided which will synchronize the GURU programs running on each machine and guarantee that they all have the same hardware number. A system call, get_guru_hardware_number allows the GURU server to obtain the hardware number stored in the system. The Operating System guarantees that it really is GURU asking for this information. SWAMI 9

FUNCTIONAL SPECIFICATION LEGALIZATION: Program legalization occurs either at link time or at "legalize_executable" time. The steps used are as follows: Either the linker or the legalize-pm program sends a pipe request to GURU using msg_send, with the "message" parameter containing: • The key word "LEGALIZE<null>". • Creation time in ASCII format YY-MON-DD: HH: MM: SS<null>. • The program name followed by a <null>. • The complete pathname of the directory, in which the executable file will be placed, followed by a <null>. The linker or the legalize_executable program receives a reply back from GURU using msg_receive_reply, with the "message" parameter containing: • The 100 byte magic number that is to be placed in the program image file. SWAMI 10

FUNCTIONAL SPECIFICATION VERIFICATION: Program verification occurs at execution time. The steps to be followed include: 1. The Operating System sends a request to GURU using msg_send, with the "message" parameter containing: • • • The key word "VERIFY<null>". Creation time in ASCII format YY-MON-DD: HH: MM: SS<null>. The program name followed by a <null>. The complete pathname of the directory, in which the executable file is located, followed by a <null>. The 100 byte magic number that was found in the program image file. 2. The system obtains an answer from GURU using msg_receive_reply, with the "message" parameter containing: • "MAGIC NUMBER INVALID<null>". VERIFIED<null>" SWAMI or "MAGIC NUMBER 11

DESIGN SPECIFICATION DO NOT READ AHEAD UNTIL WE HAVE COMPLETED THE EXERCISE FOR THE FUNCTIONAL SPEC SWAMI 12

DESIGN SPECIFICATION DESIGN DESCRIPTION GURU (Global Universal Resource Unit) is a distributed server, running on all machine of a system. It is responsible for: · Maintaining and protecting a 100 -byte unique hardware number, common to all machines in the system. · Producing a magic number that is placed in the executable file at link or "legalize_executable" time. · Verifying that the magic number in an executable is OK. SWAMI 13

DESIGN SPECIFICATION LEGALIZATION AND VERIFICATION: GURU receives requests using a msg_receive; the parameters received were described in the functional spec. If the keyword is "LEGALIZE", then • • • Multiply together the ASCII values of the creation_time, program name, and creation directory. Multiply the product just obtained with the 100 -byte hardware number to produce the magic number. Use a msg_send_reply to return the magic number. SWAMI 14

DESIGN SPECIFICATION LEGALIZATION AND VERIFICATION: GURU receives requests using a msg_receive; the parameters received were described in the functional spec. If the keyword is "VERIFY", then • • Multiply together the ASCII values of the creation_time, program name, and creation directory. Multiply the product just obtained with the 100 -byte hardware number to produce the magic number. Compare the magic number produced here, with the magic number submitted by the requestor. Use n msg_send_reply to return the appropriate answer to the requestor. SWAMI 15

DESIGN SPECIFICATION INITIALIZATION: When GURU is initialized upon machine startup, it obtains the 100 -byte hardware number using a get_guru_hardware_number. It opens pipes with the GURU incarnations on all the other machines of the system and broadcasts its 100 -byte number. The other servers respond either with an "OK" or with a "WE'VE GOT A PROBLEM". In the latter case, the system administrator will get involved and sort everything out. SWAMI 16