Super Worm Analysis MechanIsm - Computer Systems Performance Evaluation - Lecture Slides, Slides of Computer Science

Download Super Worm Analysis MechanIsm - Computer Systems Performance Evaluation - Lecture Slides and more Slides Computer Science in PDF only on Docsity!

SUPER WORM ANALYSIS

MECHANISM

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.

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.

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.

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.

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.

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".
• Creation time in ASCII format YY-MON-DD:HH:MM:SS.
• The program name followed by a .
• The complete pathname of the directory, in which the executable file will be placed, followed by a .

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.

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".
• Creation time in ASCII format YY-MON-DD:HH:MM:SS.
• The program name followed by a .
• The complete pathname of the directory, in which the executable file is located, followed by a .
• 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 VERIFIED" or "MAGIC NUMBER

INVALID".

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.

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.

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.