Electronic Data Processing Security System and Method

The invention relates to a method and system for preventing unauthorized alteration, destruction, removal or reproduction of data stored or processed by a data processing unit and more particularly to a data processing security system which provides a control technique for sensing information entering into the CPU and comparing the information to developed standards. The comparison makes possible a determination by the secondary computer whether unauthorized or improper use of the CPU has been attempted so as to violate the security of the information therein and if such violation is detected, to take a predetermined counteraction to preclude alteration, destruction, removal or reproduction of information.

The Prior Art

The widespread use of computers which has developed in recent years has given rise to a growing body of information retained in computerized form, some of which has enormous value. businesses have taken a variety of steps to protect the integrity of their valuable information. Typically, computer centers are kept under constant television surveillance, computer rooms are sealed off to all except authorized personnel and round-the-clock security guards are posted at critical stations. All of these steps limit access to the computer but do not limit opportunity to appropriate information from a computer by various methods of remote access.

There are several ways in which data can be appropriated. The first technique is to tamper-change computer programs and swap them for the originals with the objective of misrepresenting actual transactions to the audit department. This technique accommodates draining bank accounts, payment of fictitious employees, purchasing non-existent or fraudulently expensive materials, crediting unpaid accounts, insuring nonentites and collecting damages and purchasing from illegitimate suppliers.

A second and more subtle method of obtaining valuable information without authorization is to request a work order for the computer to reproduce the confidential information in such a way that loss of the information cannot be detected. For example, the computer can be caused to copy confidential files onto separate disk packs during regular business operations so that the disk packs can be removed from the premises at any convenient time. Because the data still remains in memory in the computer, there is no indication that the data has been stolen unless the disk packs are discovered leaving the premises.

A third way in which data can be violated so as to cause injury to the owners is to gradually substitute false data and programs until enormous confusion exists. Factual data upon which contracts are bid can be altered so as to make it unable to compete in the marketplace.

Most of the existing auditing systems are virtually incapable of detecting tampering internal of the CPU. By way of example, a deck of punched cards requesting some routine computer operation can be delivered to the computer dispatch desk during regular working hours as is commonly done. The routine card deck could contain a second card deck which functions as a "plant". The cards are then placed into the card reader hopper and processed like any other work order.

The plant can then be removed from the collection bin. The result is that the computer program has been altered to include a processing step not otherwise recognized by company management.

Thereafter, when highly confidential information (e.g. on a magnetic disk) is read into computer memory for processing, the entire context of the confidential information can be recorded by copying it to a preselected section of one of the other disk packs on the handler. The second disk pack, now having the recorded confidential information thereon, can be easily removed from the computer area, leaving the original one to avoid detection.

In this instance, it is apparent that the opportunity to steal or tamper the data originates with a valid work order.

A variation on the plant is to administer modifications to computer programming while it is resident in the program library. Since programs are normally kept in stored files on disk packs, they are usually entered individually into the computer memory only when their turns comes to run. Modifications which alter the program permanently are called, in this specification, patches.

A practical way in which data tampering or alteration of the kind described above can be detected is through continuous electronic surveillance of the operating control statements. A number of attempts have been made recently to provide an electronic way of preventing central processing units from exceeding the bounds assigned to a problem process for security purposes. Most prior art devices are based upon the problems of simultaneous multiple processing within the same CPU such as where one problem process encroaches into the memory areas or terminal devices of a second causing destruction and failure of the second process. For example, see U.S. Pat. Nos. 3,368,207; 3,573,855; 3,371,744; 3,328,768; and 3,473,159.

While these devices serve a functional hardware purpose in modern computer technology, no present prior art system continually senses operating control statements. Rather, they sense encroachment across physical address boundaries (including memory addresses, terminal device addresses and library device addresses). Further, none of the known prior art devices accommodates comparing information with predetermined standards and reacting to prevent unauthorized alteration, removal, destruction and/or inspection of information.

The present invention relates to precluding unauthorized removal, alteration, destruction and inspection of problem data and/or procedures in a CPU by monitoring operating control statements with a secondary computer system. Because data processing has come to require the performance of multiple processes in complex order within a short span of time (problem processing) a higher level or operating process has developed for control.

It is a feature of the present invention to achieve data processing security in the problem process by controlling the operating process. The controlling step includes monitoring information, comparing the information with predetermined standards and, in selected instances, following a predetermined counteraction plan.

It is, therefore, a primary object of the present invention to provide a novel data processing security system.

It is another primary object of the present invention to provide an improved method for controlling problem processing in a CPU to prevent unauthorized tampering of information.

One still further object of the invention is to prevent program changes without detection and to prevent undetected processing of forbidden operating control statements without authority.

It is a further important object of the present invention to provide a novel method for monitoring the operating process (OP) of a CPU.

These and other objects and features of the present invention will become more fully apparent from the following description and appended claims taken in conjunction with the accompanying drawigns.

FIG. 1 is a functional block diagram of a general purpose digital computer and an associated security system.

FIG. 2 is an interconnection diagram particularly illustrating interfacing between the host system and the security system.

FIG. 3 is an interconnection diagram particularly illustrating interfacing hardware within the security system.

FIG. 4 is a detailed interconnection diagram of the modules within the alarm console of the security system.

FIG. 5 is a timing chart representing the queuing sequence for electronic modules and registers under ther supervision of the controller within the alarm console of the security system.

FIG. 6 is a block diagram illustrating the timing sequence within the security system for detecting unauthorized problem steps in the host CPU.

FIG. 7 is a block diagram illustrating the flow of information pulses upon initiation of IPL.

FIG. 8 is a procedural flow diagram illustrating the timing sequence of the security system for detecting modifications in a host CPU problem process.

FIG. 9 is a procedural flow diagram illustrating the use of authority codes and cards at three distinct operating times.

FIG. 10 is a perspective illustration of a presently preferred embodiment of the alarm console.

FIG. 11 is a fragmentary perspective illustration of a preferred embodiment of the register status indicator panel on the alarm console.

Reference is now made to the figures illustrating presently preferred embodiments of the invention, corresponding apparatus and parts thereof being identified with like numerals throughout.

Reference is now made to FIG. 1 which illustrates a host central processing unit (CPU) generally designated 10. The illustrated CPU has been schematically separated into its two principal operational subdivisions: the problem process 11 and the operating process 12. The problem process 11 serves the data processing function by transforming problem data in bulk storage 22, taken as input, into results representing the desired objective by predetermined steps. These objectives can then be stored in the same or different bulk storage, for reuse. Thus, the problem process 11 takes raw material (problem data input) and by predetermined steps accomplishes the objectives (problem results).

In the development of modern computer technology, it has become necessary in the problem process 11 to perform multiple processes in complex order within a very short span of time. In order to control the priority and scheduling of problem processes, an operating process 12 is included. In modern data processing systems, all problem processes must be governed by an operating process 12, which must be established first in the host CPU 10 by an initial program load (IPL) which will be susequently more fully described.

The operating process responds to information given in operating statements to determine the priority of problem processes, bulk storage needed, and the problem steps (e.g. programs) needed to accomplish the problem process, as described above. The operating statements originate at a suitable control device 30 which may include, for example, a card reader or an operator keyboard.

In this specification, problem steps means all computer oriented subtasks catalogued on the library device necessary to accomplish the objective of a problem process including computer instruction sequences, subroutines, programs and any and all combinations thereof and computer operating control statements, punctuation, and characters and any combination thereof. The problem steps are loaded from the library device 23 to implement the problem process 11. The objective of maintaining security in the problem process 11 is obtained by monitoring information at the operating process level.

Monitored information is analyzed by a secondary computer system generally designated 34. The secondary computer 34 is electronically coupled to the host CPU 10 so as to monitor all of the operating statements from control devices 30. In addition, the operating statements from control devices 30. In addition, the secondary computer is electronically coupled to the host CPU 10 so as to monitor and authenticate problem steps in the library device 23 prior to instituting any problem process.

The secondary computer 34 may interrupt the CPU and drain or ignore any illegal operating statements and prevent the loading of problem steps from the library device 23. Additionally, or, alternatively, if desired, where there has been a failure of comparison between operating statements or problem steps and a predetermined standard, the secondary computer 34 responds by initiating an alarm and a descriptive printout at a remote alarm console 46.

Referring now to FIG. 2, the central processing unit (CPU) generally designated 10 is a host computer which may be any one of a variety of known units such as, for example, the IBM 360. Conventionally, the CPU host is connected to a bulk storage unit 22 which represents disk packs, magnetic tapes or other information storage devices. A library device 23 is illustrated connected to the CPU as a separate device to facilitate discussion or problem step monitoring as described in connection with FIG. 1, above. However, devices 22 and 23 could be located together. The bulk storage units and library device are connected by a selector channel 24 to the CPU so that information in the bulk storage unit can be retrieved or transmitted on command of the CPU.

In addition, the CPU is connected by a multiplexer channel 26 to at least one control device 30. Control device 30 includes any one of a variety of conventional apparatus such as a card reader or operator keyboard.

Operating statements in channel 26 and problem steps stored in library 23 are monitored by the secondary computer generally designated 34 at 25 and 27, respectively. If desired, information from the library device 23 could be received in the host 10 and communicated to the secondary computer 34 through line 32. Preferably, lines 32 and 33 are contained in a tamper-proof sheath so that signals in the channels are directed simultaneously to the CPU 10 and the secondary computer 34 without opportunity for alteration of the electronic signals.

The secondary computer 34 may be of any suitable variety, normally having a much smaller memory capacity than the CPU host 10. The PDP 11 manufactured by Digital Equipment Corporation has been found to be adequate. The IPL button 38 of the CPU initiates the operating process in the CPU through line 39. The electronic impulse from the IPL button is sensed by the secondary computer 34 through line 41.

The secondary computer 34 has a secondary or bulk storage unit 40 comprising a magnetic tape unit which may be, for example, the DEC tape units manufactured by Digital Equipment Corporation.

The secondary computer is also connected to an alarm console generally designated 46 by line 48 which is confined in a tamper-proof sheath to prevent tampering with signals between the secondary computer and the alarm console. It is presently preferred that a conventional printing unit 50 such as Model No. ASR33 manufactured by Teletype Corporation be connected through line 52 to the alarm console. The printer 50 will develop a printed log 54 which permanently registers events communicated from the secondary computer to the alarm console 46.

The keyboard 36 of the secondary computer 34 is preferably associated with the alarm console 46 for the purpose hereinafter more fully defined. The keyboard incorporated in the ASR33 manufactured by Teletype Corporation has been found suitable.

In the illustrated embodiment, an IBM 360 is interfaced to a PDP 11 as illustrated in FIG. 3. More specifically, the PDP 11 (secondary computer 34) is conventionally provided with a direct memory access (DMA) channel 60 which is, in turn, electronically coupled into interface 62. Interface 62, for the illustrated embodiment, may be the Peri-Phonics model IU 360 or a suitable equivalent. The interface is also coupled to the multiplexer channel 25 forming part of the CPU host 20. As has been heretofore described, the multiplexer channel is also connected to control devices 30.

With continued reference to FIG. 3, the secondary computer 34 is interfaced to the alarm console 46 with teletype interfaces 64 and 66 and tamper interrupt interface 68. Teletype interfaces 64 and 66 are conventional and, for example, are manufactured by Digital Equipment Company to make electronic connection with the ASR33 Teletype made by Teletype Corporation. The information transferred between the secondary computer 34 and the alarm console 46 is transferred bit serially. Teletype interface 64 operates at the usual 10 characters per second (CPS) transfer rate. However, the teletype interface 66 is simply modified to operate at 100 characters per second, a much higher rate than normally encountered with a teletype. The modification is easily accomplished by substituting higher rate oscillators for the 10 CPS oscillators in interface 64.

Information transferred from the secondary computer 34 to the alarm console 46 is received by a serial to parallel interface forming part of the receiver module 70 illustrated in FIG. 4. This loads registers 84-87 under control of controller 72. Every register except 85 has a corresponding visual indicator 94 that is illuminated when the bit is set. When sending information to a particular register or module (as hereafter more fully described) any address byte is sent first, followed by a data byte. The data byte is routed according to the last address byte received by the controller. This sequence is shown best in FIG. 5.

In general, information transmitted to the secondary computer 34 (FIG. 4) by the transmitter module 82 will be from the operator keyboard 36 through the controller 72 to the transmitter module 82. This information will be in the form of an ASCII character, as in the usual teletype transfer. However, certain ASCII characters have been pre-empted for special purposes. For example, the ASCII character for ? is used to mean that the secondary computer is requested to read the console status register 84 (FIG. 5). Information contained in this register 84 informs the secondary computer 34 the nature of a requested operation.

In addition, the alarm console contains a tamper register 76 (FIGS. 4 and 5), the binary contents of which can also be sent to the secondary computer.

In this embodiment, a plurality of tamper-sensors 75 has been provided for connection at a variety of locations, the actual number of available sensors being determined by the size of register 76. If any of the sensors trigger because of tampering with the sensor connection, an appropriate bit pattern appears in tamper register 76 and an immediate interrupt signal is energized through line 77 to tamper interface 68. The response of the secondary computer is to request (by sending a request command to receiver module 70) the binary contents of the tamper register to be transmitted through controller 72 and transmitter module 82 for determination of the cause of the tamper condition.

The controller 72 operates by passing a "select" timing signal through each device which can accept or transmit data or control bytes. priority is determined by position in the daisy chain connection of modules and registers illustrated in FIG. 5. In order of priority, the address selector module 80 is followed by the receiver module 70, the transmitter module 82, the interrupt module 74, tamper register 76, console status register 84, console fault register 85, mode register 86, alarm register 87 and keyboard interface 88. Registers 84-87 are illustrated as a single block in FIG. 4. When the select signal reaches a module or register, it can seize control and prepare to transmit information, or raise an "allow send" signal and prepare to receive information. It is clear from reference to FIG. 4, that certain modules can only transmit data and some can only receive. Once a module receives the select signal and has a request, it can seize control. When control is seized, the select signal is reset and a timing sequence is initiated by the master timing generator 90 (FIG. 5) to provide a transfer pulse followed by a reset pulse to prepare all modules and registers for another cycle.

Information transferred from the alarm console 46 to the secondary computer 34 is first passed through the transmitter module 82 (FIGS. 4 and 5) which comprises a parallel to serial converter so that the output from the transmitter module 82 is serial.

In summary, the input information to the alarm console 46 can be received from several sources. More specifically, the alarm console can receive serial information into its receiver module 70 directly from the secondary computer 34. The alarm console 46 can also receive a byte in parallel from keyboard 36 (FIG. 4) which makes the information available in parallel form through the interface 88. Finally, tamper sensors are connected into the tamper register 76. An appropriate bit pattern appears in this register and an interrupt signal is communicated through 77 to the interface 68 of the secondary computer 34. The response of the secondary computer to this interrupt is to read the tamper register over the serial lines to the interface 66 to determine the cause of the interrupt.

Outputs from the alarm console 46 can exit in three ways. First, the serial output to the seondary computer 34 through the transmitter module 82 transfers information contained in the registers 84-87 as well as tamper and keyboard information from the register 76 and keyboard 36, respectively. Secondly, outputs from the alarm console 46 can be transferred to the visual indicators 94 (shown more particularly in FIG. 11). Finally, the audible alert alarm 96 can be sounded by output from the alarm console 46.

In order to obtain the objective of preventing the unauthorized alteration, removal, destruction or inspection of problem data and/or steps in the host computer, it is necessary first to establish a decontamination of the host 10. This can be accomplished by examining the operating process 12 (FIG. 1) of the host and performing a comparison test against a known base copy of the operating process. Next, each problem step is compared against a known base copy. The decontamination procedure detects the presence of any plant or patch or other alteration in the host memory and library devices and establishes a clean base for monitoring subsequent transactions of the host 10.

The decontamination of the host 10 is not valid if the host itself performs the comparison because the comparing program is subject to unauthorized alteration. Accordingly, the secondary computer 34 is used to decontaminate the host CPU. The secondary computer is connected strategically to the multiplexer channel of the host and would require a base copy of the host operating process for comparison. The base copy must not be vulnerable to substitution itself, which means that it would have to be held within the secured memory of the secondary computer 34. Where the memory capacity of the secondary computer is small, however, it is observed that this is a physical impossibility because of the great size of the operating process of the host. Therefore, a technique called "checksum" may be used to compact the base copy into a unique statistical base that can always be calculated from the base copy.

The term "checksum technique" is defined herein to mean a control technique for authenticating the legitimacy of a structurally complex arrangement having a measurable number of subdivisions. The checksum technique is performed by sensing the order of predetermined collections of subdivisions and comparing this order with a statistical summary of the expected base copy. The collection or accumulation of subdivisions is called herein "checksum" or sometimes "statistic". The checksum technique can best be understood by referring to an example of proving that a book is unaltered from its first published state. Without being able to compare the book word for word, the assignment at first seems impossible. However, suppose the book is considered an arrangement of words, each having a measurable number of letters. The order of words can be statistically captured by accumulating the number of letters in every 50 words in a finite accumulator register subject to overflow. If the words are accumulated in a different order, random mix of words will cause different filling and overflow conditions. Each sum of the letters in 50 words represents a statistical base or checksum in the summary of the expected base copy of the book. Where the sum of the letters exceeds the register capacity, the sum will be decreased by the amount of overflow. Clearly, if the book is longer than 50 words, there will be more than one checksum statistic for the book. The last checksum statistic covers whatever odd number of words are left over after the groups of 50 are removed. Thereafter, any copy of the book can be obtained and the letter count of the words accumulated in the accumulator register. If exactly the same checksums result, the probabilities that the book has not been altered are extremely high. This is particularly true if someone attempting to change the book copy without detection did not know how the statistics were counted (i.e. the number of words in each collection).

Computer problem steps are complex arrangements (of bytes) which, for purposes of this example, are similar to books. It is possible to accumulate checksums made from base copies of problem steps and operating processes of the host computer even in a small computer. The checksums are, for example, the accumulated number of information bits in a predetermined set number of bytes, possibly decreased by any overflow resulting from the finite capacity of the accumulator register. To perform the checksum technique, a questionable copy taken from the library device during initial program load (IPL), as will be subsequently more fully described, is resubjected to the same statistical analysis by the secondary computer as was applied to the base copy. If differences are found, an illegitimate copy is assumed and a predetermined counteraction may be initiated.

The checksum technique is performed by the secondary computer after any regeneration of the host operating process 12 or problem steps 23 (FIG. 1) in order to compute new statistical bases which are retained in a collection called sum file. The sum file must be kept secure from alteration or inspection.

The checksum technique, as used with the illustrated embodiment, can best be understood by reference to FIG. 6. At IPL, or at any other appropriate selected time, the secondary computer requests retrieval of problem steps from the host's library device 23 as at 300. The particular problem step to be examined is thus identified. Its expected statistical base or checksum is extracted from the sum file at 302 and placed in a comparator register at 304.

As part of the same process, the problem step subdivision is examined (as set forth more particulary in the description of FIGS. 7 and 8 below) at 306 and the actual statistical base or checksum of the subdivision is placed in a comparator register at 308. Both the expected and actual statistical bases are brought together in a comparator 310.

If the actual and expected statistical bases match, the problem step subdivision is regarded as uncontaminated and eligible for use in implementing problem processes (see FIG. 1). The next problem step subdivision can then be examined. If the actual and expected statistical bases do not match, a counteraction impulse 312 is communicated to the alarm console. The process continues until all problem steps in the library devices have been examined. The operating process is handled in the same manner and is normally resident in a predetermined location in the library device.

A computer operator prepares a computer for use by making an initial program load (IPL). IPL retrieves a fresh copy of the operating process from the library device in the computer. IPL is usually made for any one of a number of reasons, most commonly including returning the computer to a secured running condition after a debugging period and also for recovering after a system crash. conventionally, a system crash defines that circumstance where the operating process has completely failed and is no longer usable for processing information. The IPL procedure can best be understood by reference to FIG. 7 Conventionally, IPL is initiated by actuating a button 38 (also shown in FIG. 1) at the host control panel thereby energizing the host hardware loader 102. The host hardware loader has the function of loading a starter program. The hardware within the loader 102 is conventionally a read-only memory within the host which in turn reads three load-unit switches set on the operating panel (not shown). A starter series of instructions are then read by the read-only memory from the device indicated by the load-unit switches (not shown) which device in turn retrieves a fresh copy of the operating process. The described process of serially implementing larger and more complex programs with the next preceding program is called boot-strapping.

When the secondary computer 34 is coupled to monitor the CPU host 10, additional functions are inserted into the IPL procedure which have the principal purpose of authenticating the new operating process copy against a known statistical base (determined by checksums) in order to be certain that it is legitimate.

The secondary computer 34, in the FIG. 7 embodiment, is the device referred by the host load-unit switches described above. The starter series of instructions 104 from the secondary computer 34 are loaded from the host hardware loader 102 establishing a toehold in the host 10. The starter instructions are such that they perform a checksum technique essentilly the same as that described in FIG. 6 except that the statistical base may be carried with the starter instructions rather than stored in the sum file.

After authentication, the starter instructions initiate loading of the operating process from the library device 12 into the host at 106. If authentication fails, a response is sent to the alarm console 46.

The first operation of the operating process is to establish the loading of a resident representative program 108 normally retained in the secondary computer and sent to the host 10 in response to the load request. The function of program 108 is to transmit the sum file at 314 from the library device 23 to the secondary computer 34 (see also FIG. 1). The structure accommodating the checksum technique which begins at this point can best be understood by reference to FIG. 8.

The secondary computer 34 retrieves the sum file base table 318 from the host library device 23 using the services of the resident representative 108. The sum file base table 318 is stored in the memory 320 of the secondary computer. Using the sum file table 318, the secondary computer selects the next problem process name and statistical base at 322 and extracts the name from the sum file base table in the secondary memory and requests the steps of this problem process at 324 from the resident representative (see FIG. 7). The secondary computer 34 then extracts the statistical base and stores same in register 304 (see also FIG. 6). The expected statistical base is now stored in comparator register 304.

When the process steps 316 are received from the host 10, they are examined at 306 and the actual statistical base of this copy of the problem process is placed in register 308. The actual and expected statistical bases are compared in comparator 310. If they match, the process is continued at 326. If they do not match, the alarm console counteraction 312 takes place and an impulse is transferred to the alarm console 46. Also, where desired, loading of the problem process is suppressed at 328 in the host 10. Causing the suppression in the host 10 is one of the functions of the resident representative 108.

Referring again to FIG. 7, once the operating process has been established as legitimate, every problem step stored by the host 10 on its library device 23 is read and authenticated against their known statistical bases to prove they are unaltered from their original state. Authenticating problem steps and the operating process is defined herein to mean decontamination of the host.

When the normal IPL has been completed, the normal data processing operations begin. In the event the load unit switches were set to a unit other than the secondary computer, it will not be selected to supply starter instructions. The host 10 recognizes this condition because it receives an impulse from IPL button 38 and after a reasonable delay, issues an alarm at 46 that the secondary computer 34 was not selected for IPL.

As previously mentioned, the statistical bases used during the checksum technique are stored in the sum file on library device 23. The sum file is initialized at the time that a new version of the operating system in the host is generated at the completion of the generation process. The sum file is built into the host library device 23 in the form of a large binary table wherein each position in the table carries the name of a problem step and its statistical base quantities.

In order to protect the sum file from alteration without contamination in the host library device 23, each statistical base is given a periodic bias. The sum file bias is a code initiated at the security keyboard 36 (see FIG. 3) and transmitted through the resident representative 108 to the host 10. The sum file bias is used because the statistical bases are placed in an environment where illegitimate programs may exist in the host computer 10. Accordingly, it is conceivable that the statistical base for any particular program could be detected, altered and/or counterfeited. This opportunity is minimized by requiring a sum file bias.

The sum file bias can best be understood by observing the example where the statistical base is stored in a six-place shift register in binary form. For example, the value of a register representing a statistical base may, for example, be numerically represented as follows:

As can be readily observed, the value of this shift register numerically is equal to 51. The sum file bias represents a rotation of the positions from the illustrated normal position. For example, a parameter given to the security keyboard 36 during IPL to the resident representative 108 could be 8, which is used as the number of rotational positions from the normal. This means that the statistical base is revolved through eight positions after it is computed so that it would be represented in the shift register as follows:

Clearly, because of the sum file bias, the numerical value represented by the shift register differs depending upon which particular bias is used even though the statistical bases remain identical. Unless the sum file bias is known, the actual statistical base recorded in memory with its corresponding name cannot successfully be used without causing checksum failure.

There is no restriction on the frequency or extent of additions, alterations or deletions within the system of the host computer. However, it is required to call a checksum program to compute new statistical bases for inclusion in the sum file after each revision or update or introduction of a new problem process step.

Once the host 10 has been decontaminated, it is necessary to maintain the state of decontamination. This is accomplished by monitoring or scanning all operating statements from control device 30 as shown in FIG. 1.

In general, operating statements are divided into two categories: those which are never permitted and those which are permitted if the proper degree of authority can be shown. Any number of levels of authority can be predetermined, ranging from a classification "maximum" to a classification "minimum" (including "none").

Any operating statement found to be prohibited causes an alarm and descriptive message to be transmitted to alarm console 46, and normally causes the offending statement to be suppressed before its effect is allowed to take place in the host 10.

Any other operating statement is acceptable only if accompanied by the appropriate corresponding authority. Without the proper authority, these statements are handled in the same manner as the forbidden statements described above.

In the illustrated embodiment of the invention, where operating statements are made through punched cards, rules are imposed upon the deck of punched cards to allow authority to be shown. Any request from the card deck for compilation or loading of programs in the CPU is a forbidden statement, regardless of any authority and will trigger an alert to the secondary computer as will be subsequently more fully described. The purpose for these prohibited steps is to prevent untested programs from entering the decontaminated domain in the host. Every step or execute card must be accompanied by an authority card. Each authority card is recognized by a unique passcode which must be given or an alarm will be registered at the secondary computer alarm console and the statement normally will be prevented from taking effect. The described authority policy may, if desired, include a variety of authority degrees based on passcode assignments.

A suitable authority card is preferably designed to prohibit counterfeiting or re-use of cards that may be lost or stolen. The authority cards are prepared by punching passcodes into the cards, each card having a different passcode. The cards may, for example, be punched by the CPU host based on enabling codes submitted by a security officer through the keyboard of the secondary computer. These same codes are retained in the secondary computer as a means for authenticating the legitimacy of authority cards. It is recommended that special card stock be used which is prominently marked so as to distinctive from other cards. Moreover, the punched authority card deck should be carefully guarded to prevent card theft and authority codes should be changed at unpredictable times to minimize counterfeiting.

The authority cards may be used only once, If an attempt is made to re-use an authority card, an alarm will be transferred to the secondary computer in a manner subsequently more fully described. Thus, it is not necessary to recollect the authority cards or extract them from the job decks. In one presently preferred embodiment, the authority serial number consists of four hexidecimal digits punched into the card at variable column positions from column 16, surrounded by as many as 12 false cover punches to conceal its actual location. An authority deck covers a serial code range starting with the lowest allowed passcode. However, the deck, punched in random (non-serial) order, omits the use entirely of a given digit which may be deleted to minimize predictability. For example, if the digit 7 were removed, the numbers 7, 17, 77, 710 and all other numbers with the digit 7 would be bypassed.

The process of authorizing operating statements is defined herein as authority card technique. The structure accommodating the authority card technique can be best understood by reference to FIG. 9. FIG. 9 illustrates operation which can take place at three possibly distinct time periods 500, 502 and 504.

At IPL or some other convenient time, enabling codes are typed into the alarm console 46 and are received by the secondary computer 34 and an authority code table at 400 is developed for storage in memory 402. The authority code table is developed by providing four enabling codes: (a) the lowest allowed passcode, (b) the number of authority cards needed, (c) the digit to be deleted, and (d) the concealed position on the card. The code table is a sequential assignment of passcodes beginning at the lowest and excepting omissions caused by the deleted digit.

When the table is developed the cards are punched correspondingly at 401 to form a deck 403, there being only one punched card for each passcode in the table. This deck 403 is then guarded until its use, as described above.

At some other time (see 502) a statement authority card deck 405 is prepared as the enabling deck defining the authority policy, i.e. which of all possible statements are prohibited or require a specific authority level. These statements are developed into a statement authority table at 404 and stored in memory 406. This table remains in memory more or less permanently and is changed only as specific circumstances warranting same are required.

The host problem processing 11 takes place in time period 504 and attention is again drawn to FIG. 1. It will be remembered that the problem processes 11 of the host 10 are controlled by monitoring the operating process 12. This process is shown also in FIG. 7 at the termination of the IPL.

Referring again to FIG. 9, operating statements 30 are transferred to comparator 408 which requests the authority table from memory 406. If there is no match, the operating statement is acceptable without authority and the secondary computer moves to the next statement. If there is a match, then the statement is either forbidden or requires authority. The secondary computer then scans for an accompanying authority card 412 which is brought to comparator 410 for comparison against authority code table 402.

If a corresponding authority passcode is found, the operating statement is accepted. If not found at 415, an impulse is sent to the alarm console 46 for counteraction, as at 416 (FIG. 7). This will normally result in suppression of the statement and prevent its taking effect in the host 10.

At 413 (FIG. 9) each authority passcode as found in authority code table 402 is so marked that it may not be used again. At 409 (FIG. 9) if a match is found but the statement is forbidden regardless of authority, the counteraction is taken in alarm console 46, immediately.

Two typical types of operating statement languages are given by the IBM job control language (JCL) and the IBM timesharing option language (TSO). These and any other operating statement languages can be scanned or monitored as above described. Authority is shown by interspersing authority passcodes among the operating statements at the required points. In the case of JCL, the authority passcodes are punched into authority cards as described and physically inserted into the operating statement punch card deck on the required locations.

In the case of TSO, the equivalent of authority cards are typed among operating statements at a user keyboard terminal.

The secondary computer 34 communicates with an authorized person at a secure alarm station which is preferably remote from the host computer 10 and, if desired, may be remote from the secondary computer (see FIG. 2). The alarm station includes the alarm console 46 schematically illustrated in FIG. 10. With continued reference to FIG. 10, the alarm console 46 comprises a keyboard 36 which may be a conventional teletype keyboard as described above. Also included is a numerical button array 37 which is an extension on the numerikeys on keyboard 36 and which accommodates communication of numerical codes and the like into the alarm console 46 and also the secondary computer 34 (FIG. 2). A screen 204 may be used to accommodate backlight instructions or, where desired, may present a cathode ray tube for displaying the output of television surveillance cameras at other locations such as at the site of the host 10.

Indicator lights generally designated 206 are arranged in an array for communicating information to the operator. The array 206 is best illustrated in FIG. 11. The meaning and function of the array and its components will be discussed more particularly hereafter. Preferably, the console 46 has a teletype printout 50 which records all or selected portions of the information communicated to the console 46.

The secondary computer is placed in the response-required mode by typing in an appropriate code on the numeric array 37 of the console 46. In the response-required mode, the console 46 must be monitored continuously by a security person. To assure this, the control console 46 makes an attendant check from time to time by lighting the attendant check light 210. The attendant responds to the challenge by typing his identification code number into the console at 37 (FIG. 10). The use of an attendant is recommended for periods of high security precaution only. If desired, the secondary computer may be placed in a response-not-required mode which will then not require the consistent presence of an attendant. The attendant check light 210 comprises one of a series of five status lights in row 212. The row of lights at 214 indicates the alarm console mode and the row of lights at 216 indicates alarm levels. In addition to the alarm level lights in row 216, alarm tones may be provided by the console, each tone having a different pitch corresponding to a specific alarm condition.

The alarm console 46 has three alarm levels that indicate an increasing severity of security violation. Each alarm level is accompanied by a typed message from the teletype portion 50 of the console 46. The higher alarm levels may be accompanied by warning lights and audible tones. Each level of alarm requires resetting of the alarm console by one or more persons who have knowledge of a predetermined reset sequence.

As the operating statements are monitored from control device 30, the console 46 makes no acknowledgment statements that do not violate security but writes these on a magnetic tape log 40 (FIG. 2). Thus, all of the operating statements can be retained for audit.

When minor deviations are detected in operating statements that are being transferred to the host, a level 1 alarm is registered. The level 1 alarm includes a light at 218 in row 216 and a briefly sounded tone such as the margin bell on a typewriter. This signal alerts an authorized person that minor deviations in operating statements are being communicated to the host without authority. The captured mag tape log 40 (FIG. 2) assigns a special character ahead of the statement to identify the precise deviating statement. The deviating statement can be easily reviewed by an authorized security person.

A level 2 alarm is higher level alert. It could be caused by any one of a wide variety of faults, depending upon the established authority policy. In a level 2 alarm, a light appears at 219. The mag tape 40 records a description of the particular fault or error and precedes the description with a suitable designation for alarm levels. Both the security person and a data processing supervisor must punch their own personal clearing codes into the console 46 in order to reset the alarm at levels 2 and 3.

A level 3 alarm is the highest level as specified by the authority policy. The level 3 alarm triggers an illuminator at 220. The alert light at 217 may accompany the level 2 and 3 alarms and may produce an audible tone. The tone ceases when the acknowledge light 221 is energized by supplying a proper identification code.

All of the foregoing alarm signals are activated both when the alarm console is in the response-required and not-required mode.

As a special operational authority policy, codes input at 37 can require a full authority indicated at 223 which overrides the statement authority table 406 (FIG. 9) or any other authority policy thereby requiring an authority passcode for every operating statement. This allows a temporary maximum surveillance condition that may trap any offenders of the authority policy who are familiar with the system. Nevertheless, the mag tape continues to capture all operating statements as well as all alarms that occur.

When any identification or other codes are entered into the console 46, the code is checked for validity against an authorized table in a manner analagous to the authority passcode technique described with FIG. 9. When desired, the accumulated magnetic tape log can be typed on printer 50 or transferred to storage from the host.

It should be recognized that the invention lies in the electronic system defined by the claims. However, a certain amount of programming is required to adapt the data security system to a particular use. In order to fully disclose one embodiment of the invention, the following program listings are submitted. The first source program has been found desirable when an IBM-360 computer is the host system. The second source program has been employed for a Digital PDP-11 operating as the secondary computer. ##SPC1## ##SPC2## ##SPC3## ##SPC4## ##SPC5## ##SPC6## ##SPC7## ##SPC8## ##SPC9## ##SPC10## ##SPC11## ##SPC12## ##SPC13## ##SPC14## ##SPC15## ##SPC16## ##SPC17## ##SPC18## ##SPC19## ##SPC20## ##SPC21## ##SPC22## ##SPC23## ##SPC24## ##SPC25## ##SPC26## ##SPC27## ##SPC28## ##SPC29## ##SPC30## ##SPC31## ##SPC32## ##SPC33## ##SPC34## ##SPC35## ##SPC36## ##SPC37## ##SPC38## ##SPC39## ##SPC40## ##SPC41## ##SPC42## ##SPC43## ##SPC44## ##SPC45## ##SPC46## ##SPC47## ##SPC48## ##SPC49## ##SPC50## ##SPC51## ##SPC52## ##SPC53## ##SPC54## ##SPC55## ##SPC56## ##SPC57## ##SPC58## ##SPC59## ##SPC60## ##SPC61## ##SPC62## ##SPC63## ##SPC64## ##SPC65## ##SPC66## ##SPC67## ##SPC68## ##SPC69## ##SPC70## ##SPC71## ##SPC72## ##SPC73## ##SPC74## ##SPC75## ##SPC76## ##SPC77## ##SPC78## ##SPC79## ##SPC80## ##SPC81## ##SPC82## ##SPC83## ##SPC84## ##SPC85## ##SPC86## ##SPC87## ##SPC88## ##SPC89## ##SPC90## ##SPC91## ##SPC92## ##SPC93## ##SPC94## ##SPC95## ##SPC96## ##SPC97## ##SPC98## ##SPC99## ##SPC100## ##SPC101## ##SPC102## ##SPC103## ##SPC104## ##SPC105## ##SPC106## ##SPC107## ##SPC108## ##SPC109## ##SPC110## ##SPC111## ##SPC112## ##SPC113## ##SPC114## ##SPC115## ##SPC116## ##SPC117## ##SPC118## ##SPC119## ##SPC120## ##SPC121## ##SPC122## ##SPC123## ##SPC124##

Of course, many other programming languages could be used to meet the requirements set out in this specification and claims.

In addition, it should be noted that any ordinarily skilled systems programmer may construct source programs which would accomplish the same ends within the scope of the claims as are accomplished by the preceding program embodiments.

The invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive and the scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.