LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 510.84 I Zbr no.7£2-727 cop 2. Digitized by the Internet Archive in 2013 http://archive.org/details/comprehensivesec725grap 5/0, * is the "protection of data against accidental or intentional disclosure to unauthorized persons, or unauthorized modification or destruction." As is easily seen, there are many levels of security. As shown in Figure 1 those different levels of security could be broken into k classes, as follows. A. The Legal and Societal Environment This refers to the environment that must surround the concern for security. To be able to speak about security as a positive goal, it must first be seen as a desirable thing within the society. It is not worth it to speak about security if the society just doesn't need it. Once society's needs for security have been established, some legislation is required, such as, for example, to formalize what we mean by a robbery where no actual physical object is stolen, i.e., data or information robbery. H c5 -P 0) •H O O ra -p (h T3 CD O H Sh bO > CD ^S c3 +3 o3 >»tj O 05 O >s 3t*i +3 O -H 3 •H O -p !h ctf -P 03 p _, H !» O CD ■g-d m 03 3 ,o hO CI H 1>j W -H ct3 -P H W o •H O oa •H h h OJ P -P O 03 b> O fl o £ 1^,18, 19,23] whose main concern is to expose the reader to the security problems. Most of them are directed to management and the exposition of the problem is their only concern with very little discussion of solutions. Others, after a brief exposition, attack one of the problems in a stronger fashion (as for example: the problem of confidentiality of individual records in data storage and retrieval for statistical purposes [1^] or ways of encoding data [7]). None of them tries to give a comprehensive solution to the security problem and we will not discuss them further. The category of sales includes those papers [3] whose main intention is to describe a working comprehensive system, but their description is so vague and short that it sounds basically like a commercial where everything works nicely. For example, the 1 1/2 page description of the RUSH time-sharing system [3] includes a sentence "This protection is now available in RUSH, and guarantees full security to time-sharing users, program, data, and program/data files. " which is just too nice to be true. 7 Obviously, these papers too won't be included in the following discussion even though they refer to a comprehensive system. The third and most important category, for our purposes, is the "comprehensive systems" category. As will be explained later there does not exist such a thing as a comprehensive security system, but the systems described next are really trying to approach it, and hence the name. Within this category I will describe the following papers: 1. multi-dimensional security program for a generalized information retrieval system [8], 2. the formulary model for flexible privacy and access controls [15] > 3. on the implementation of security measures in information systems [10]. h. security controls in the ADEPT-50 time-sharing system [2k], 5. protection in an information processing utility [13]. The approach that I will take will be first of all to give a brief description of each one of the 5 systems (Chapter II), then to try to evaluate each one (Chapter III), and finally to give a short summary (Chapter IV) of the state-of-the-art as pointed out by the systems discussed. II. THE SYSTEMS A. Multi-dimensional Security Program for a Generalized Information Retrieval System The authors have developed a generalized information retrieval system (GIRS [8] ) at the University of Western Ontario, in London, Ontario, Canada. The system was programmed in FORTRAN ("for maximal portability among computer systems") on a PDP-10 computer. The GIRS's security provisions include three levels of security: 1. level 1 protection - to specify which of the ten available processing functions (CREATE, DISPLAY, SEARCH, etc.) can the user exercise. 2. level 2 protection - will give information about which portions of records are available to a particular user. 3. level 3 protection - will establish which records within a file can be seen by that user. The data structure of GIRS is a forest, with as many trees as data bases are required. Each tree (data base) is divided into two parts: header and data. The data is divided into records (up to 99*998). Each record is further divided into items (up to 10) and each item into lines (up to 10). Each line contains 72 characters and could be subdivided into elements by the use of delimiters. Thus, each line could be described by a unique 7-digit number (5 for record, 1 for item, 1 for line). The header contains information about passwords, protection keys, details about items (number of lines, protection, elements, and item's name) and index to data records (this index is set up to reference every (l60n)th record where n is a user parameter). There is one further restriction on this structure — all records in a file must have the same number of items and they must be present in the same order in all records. Protection 1 is obtained by setting one bit in the appropriate place of the header for each function that each user can perform. Protection 2 is obtained in a similar fashion, setting a bit for each of the items available. The level 3 protection is obtained by associating a security clearance number to each user, as well as to each line (from the 80 columns in a card image only 72 are used for actual data, the other 8 are used for identification and level 3 security number). A user can then see all records with security clearance number less than or equal to his own clearance number. An optional lock system is also available for additional level 3 protection, i.e., some records can be completely locked for given users. This is obtained by associating with each user one or two sets of modulo-remainder (M-R) pairs. The user will only get access to those records whose remainder modulo M is R, e.g., M = 2, R = gives access to all even number records. 10 The authors conclude by claiming that GIRS "provides a test bed for continuing experimentation with security provisions for multiple -ace ess computer communications systems. By such experimentation, it is anticipated that the optimal trade offs between security and economy can be determined for a wide range of information retrieval applications. " B. The Formulary Model for Flexible Privacy and. Access Controls The present paper [15] is a condensation of the author's Ph.D. thesis; the main motivation being to implement a security system for the student health system at Stanford University. His main goal was to create a model independent of both machine and data base which could help answer questions such as "How much does technique X cost? " In the "formulary" method the decision to grant or deny access is made at data access time by a program, thus giving as much flexibility as possible. For any particular interpretation, the installation must supply the following procedures : 1. at least one TALK procedure, 2. coding for the ACCESS algorithm, 3. primitive operations: FETCH and STORE, h. at least one formulary, consisting of: - CONTROL procedure - VIRTUAL procedure - SCRAMBLE procedure (may be null) - UNSCRAMBLE procedure (may be null) 5. a FORMULARY BUILDER procedure. n Each of. these procedures has a strictly delimited function, described later. The basic idea behind the formulary method is that a user, a terminal, and a previously built formulary must be linked or attached together, in order for a user to perform any data manipulation. At run time this information (user, terminal and formulary), is kept in the User Control Block (UCB) in central core. Figure 2 will help to make clear the user/data-base interface. The TALK procedure is in charge of the interactive conversation between system and user or user program. TALK should get from the user or his program: datum description in a user-oriented language, operation to perform, identification, and other information about user and terminal. TALK then calls ACCESS passing three parameters: datum description in an internal fashion, operation desired and proper user and terminal identification. There is no limit to the number of TALK procedures which can exist, and it is a user decision which TALK procedure to call. The ACCESS procedure uses the UCB and the information given by TALK to try to honor the users request. ACCESS will first call CONTROL, passing the internal name of the datum and the desired operation. CONTROL decides whether or not to allow the request—it could interact with the user before arriving at a decision, and thus the arrow between formulary and user in Figure 2. CONTROL will basically return a yes signal or a no signal including the reason why the operation is denied. If CONTROL says yes, VIRTUAL is called. VIRTUAL should return the resulting virtual address for the requesting datum. 12 user or user's program TALK, the conversational storage and retrieval procedure access system procedure fetch fetch requests control and other procedures of the attached formulary store quests Figure 2. User/data Base Interface in the Formulary Model 13 At this moment ACCESS performs the required operation and, if necessary, calls SCRAMBLE or UNSCRAMBLE which encrypts or decrypts data. FETCH and STORE are the actual procedures which read or write from/into the data-base. The last procedure, FOPMULARYBUILDER, interacts with the system programmer to make the appropriate attachments of formularies to user- terminal combinations. The model includes provisions for concurrent requests, obtained by including the FETCHLOCK, STORELOCK, UNLOCKFETCH, and UNLOCKSTORE operations. There also exists a default formulary which should be called whenever an unspecified user-terminal combination is found for the first time; this default formulary should either attach a formulary to the new combination or deny access. The paper goes into great detail in the explanation of the procedures, including the presentation of an ALGOL algorithm for the ACCESS procedure and a more precise definition of the parameters for each procedure. Using the formulary method, an experiment was run on the IBM 360/91 computer at the SLAC facility at Stanford. The experiment was designed to measure overhead obtained by using encoding, and early results showed that they seem relatively small. C On the Implementation of Security Measures in Information Systems This paper [10] should be read in conjunction with a closely related paper by the same authors: "Selective Security Capabilities in ASAP" [9]. The work was done at Cornell University. 11+ The article starts by defining what they mean by information security ("procedures to ensure that privacy decisions are in fact enforceable and enforced") and the authors' general approach to the problem. They list the requirements that information systems have for selective security and state that to the best of their knowledge, no security system exists with such provisions. Conceptually,, in their model, the privacy decisions for a particular data bank may be recorded in a "security matrix. " The columns of this matrix correspond to particular data structures in the system- -not necessarily disjoint—and the rows of the matrix correspond to potential users of the system. Each element in the matrix, d. ., is a decision rule embodying a specific privacy decision, specifying the conditions under which user i is entitled to access to the data structure j and the actions that i is permitted to perform upon j. Even though the above model could work, it is, in general, a prohibitively large solution. A practical implementation of the security matrix is established by the "careful analysis of when and how the matrix should be interrogated and its specification employed. " Their analysis shows that the security matrix is, in general, very sparse — most of the entries are denials of access — and that only a very small part of the security matrix is relevant at a particular moment. Thus, the appropriate solution could be to have a very small controlling submatrix which could be identified and remain in control for a significant amount of processing time. 15 All the previous ideas are put together into the authors' "functional model of a security matrix" described next. The functional model includes the security matrix and four functions: F and S , the translation-time fetch and store correspondingly, and F and S , the run-time fetch and store functions, r r The four functions have two arguments, user and datum name, thus, reflecting a particular element of the security matrix. At translation time F is called each time that a fetch is referenced in the source code. F then takes one of the following actions: 1. If user is permitted data independent fetch to the datum, the conventional object code is generated. 2. If user is denied any kind of access to the datum, the translation is aborted and the system is alerted to perform threat monitoring. 3. If user has a data dependent request to access the datum, object code is emitted to call F at run-time. S, and S are handled similarly, t r Thus, if we are dealing with data- independent security checking then F, and S, represent a very slight overhead at translation- time and none at execution- time. The overhead work of the functions F and S is then r r only performed at run-time when it cannot be done at translation-time. Except for minor changes this model is actually running in the ASAP file maintenance system [10]. After the feasibility of the model has been shown, the authors go a little further and attack the problem of general implementation in 16 languages such as PL/ I, FORTRAN, and COBOL and operating systems such as the OS/360. This extension was somewhat expected, since their model works only if embedded in a secure-translator environment. After they point out the inefficiency of any implementation that doesn't distinguish between data independent and dependent decisions and treats them all as run-time decisions. They consider alternative ways of implementing F, and S + : toy modifying the standard compiler or by interposing a preprocessor in front of the standard compiler. Even though the first is more efficient, they recommend the second since no deep modifications in the interior of sophisticated compilers should be permitted, and maintenance is much more difficult if local patches are made. The preprocessors could basically be the same compilers, excluding the code generation part, which means that the syntactic analysis is done twice. But this could "readily" be tolerated, and they give as an example a preprocessor for PL/ I based on Cornell's PL/C compiler which can scan 15,000 PL/ I scource statements per minute on a 360/65. With either a preprocessor or a modified compiler certain serious problems would remain, such as detection of invalid indexes in arrays, improper use of pointers (in PL/l), etc. which could only be controlled by limiting the freedom of the programmer to use the full facilities of the source language, and/ or generating extra code (i.e., SUBSCRIPTRANGE enabled in PL/ I for invalid index detection) and thus, overhead. 17 D. Security Controls in the ADEPT- 50 Time -sharing System The ADEPT-50 time- sharing system was implemented by C. Weissman [2k] on an IBM 360/5O with partial support by the Advanced Research Projects Agency of the Department of Defense, so the military orientation is very obvious. Weissman' s model, slightly different from the actual ADEPT implementation explained later, is very straightforward. He establishes four important objects of security—users (u), terminals (t), jobs (j) and files (f) — and three security profiles- -Authority (A), Category (C) and Franchise (F). The basic problem is then defining how the matrix of objects by profiles should be filled (a k by 3 matrix). Authority is related to government and military classification (Top Secret, Secret, etc. ) and is defined as a set (A) of hierarchically ordered security jurisdictions (A = {a < a < ... < a }). Category refers to the host of special control compartments (projects or access by project and area) and is viewed as a discrete set of specific compartments, c (C = {c , c , ... c V }). Franchise is a security jurisdiction privileged to a given set of users, (F = (u|u is user] ). For a user, u, the authority, A , and category C , are given constants; for completeness the Franchise is itself, P = u. A and C, , the authority and category for a given terminal t, are also given constants. F, is the set of users {u, ) authorized to use that terminal. Jobs are initialized by users through some terminal, then it seems logical to define A. as the minimum authority of user and J 18 terminal (min (A , A , )), and the category, C., as the intersection of 11 t j categories (C . = C C, ). The franchise. F., is a collection of users u. (in the actual implementation u. = u). We Consider two cases: new files and files that already exist. For existing files the authority and category, A_ and C , are given constants, and F„ is a list of users with access to that file. In the case of new files a new concept is established, the history. The authority history (A f ) is just the maximum authority of the files accessed by a job. The category history ((0 is the union of all the files categories. F remains with the same interpretation as above, mainly F_ = u. (in the implementation F f for a new file is then u). The above explanation is all we need to understand the model. At log-in time to the system, the franchise of the terminal is verified to see if he is a legal user for the system and the terminal. If such is the case jobs are accepted from that terminal but A. and C. are first 3 J computed. A given job will only get access to those files with appropriate jobs category (C„ c C.) which require no higher authority than the job has (which should be less than or equal to the user and the terminal). If the user creates a new file, new A„ and C are assigned according to the hisotry concept; clearly, the new file could have at most the same authority and category as the job has. The actual implementation is very similar to the above explanation, but it has many interesting extensions which we will now describe briefly. Authority and category are implemented, basically as defined. F is only an entry in the user dictionary U. Since the tables are 19 organized by user, instead of having a list of users for each terminal, F, , ADEPT has a list of terminals for each user. F. is simplified to the user that ordered the job. F„ is implemented in a more extensive fashion, F- = ( (u,,, q ), ... (u , q )}, that means as a set of pairs user-quality of access, where the quality of access could be: read, read and write, write or read and write with lockout override. If the file is public or private (all or only one user), it is indicated in the control data for that file; otherwise (the case of a semi-private file) the actual set of pairs is kept for run-time verification. All tables are initialized by a SYSIDG program, which will include for each user who may be granted access to the file: up to 6*4- use-only-once passwords, categories of terminals, terminals for that user, authority of that user, etc. At run-time all files must be opened, giving the opportunity for the file's franchise to be verified. New files must be cataloged in such a way that the new authority and category for that file can be assigned (using the history concept). The ADEPT system also uses hardware assistance to attain its objectives. A number of machine instructions are "privileged" to the supervisor state only. Instructions that change the machine state and those dealing with input/ output are privileged. Main memory is selectively protected against unauthorized change (write protected). The ADEPT'S 360/50 was also modified to include fetch protection, which guards against unauthorized reading of (or executing from) protected memory. The memory protect instructions are also privileged. All security-vulnerable 20 functions including hardware errors,, external timer and keyboard actions, user program service request, illegal instructions, memory protect violations, and input/ output are called to the attention of ADEPT by the system/360 interrupt system. The burden for security integrity is then one for ADEPT software. The ADEPT-50 system provides an interpreter for dynamic debugging which checks all requests for legality based on range checks on the data addresses. Input/ output is handled by two subroutines of the system. The first is a special- purpose compiler whose output references the second subroutine — an I/O supervisor. Legality checks are always performed- -this includes examination of device address, machine state of calling program, location of specified buffer areas, etc. The problem of classified residues is also taken into consideration. Core pages (main core and drum) are always cleared to zeros before assignment, and always full pages are swapped. Disk files are kept as "dirty" memory due to the expense of erasing all of it, but the system always assumes that an end of file (EOF) exists immediately after the last record written in a file, and prohibits reading beyond that EOF. Contaminated tracks allocated to new files cannot be read until they are first written. The two highest authorities are reserved for system files and the highest of all is for the SYSLOG file only. Access to these files are restricted to the system only, and special access checks are made: First a special user code (not in U) is required. Second the programs 21 making the OPEN must "be in supervisor mode, and third, the program making the OPEN must be a member of a short list maintained by the supervisor. Finally, ADEPT also provides a variety of service commands that involve security control, including AUDIT (for security audit recording), CREATE (to establish users and access rights for semi-private files), etc. As an indication of performance, Weissman says that the ADEPT'S overhead CPU cost is estimated to be one or two percent of total CPU time for normal operation, and that the overhead in checking I/O channel programs is between 5 and 10 msec per call. E. Protection in an Information Processing Utility This paper [13] is a description of the security measures existing in MIT's MULTICS system, a primary goal of that system being to provide a number of different users with flexible, but controlled, access to shared data and procedures. The MULTICS approach is strongly based on hardware assistance, and again, it is a straightforward implementation of a simple model. The key component of the model is the segment, a contiguous block of words whose length may vary during the execution of a process. The segment is the logical unit of information of concern to the user. All addressing is done by using an ordered pair of integers (S, w) by first using the descriptor base register and S to find the appropriate segment descriptor, which will contain the current location in memory which, together with w, will guide us to the proper place. So far we have not said anything about security, but it is easily introduced using the concept of rings. Rings are an ordered set of 22 classes numbered from to some maximum. An inner ring i (i > 0) has more authority than an outer ring i+j (j > l). Loosely speaking, a segment running in ring i can access all segments in outer rings, but has, at most, very restricted access to segments in inner rings as explained later. Making the rings disjoint, i.e., no program can cross a ring boundary, and assigning each segment to a unique ring is sufficient to solve the problem of disjoint and non- communicating programs, but is not sufficient to solve the problem of sharing segments. That is why more than one ring number is attached to each segment, as described later. As we mentioned above, each segment will have a descriptor; each descriptor will contain information about initial absolute address of the segment, length, access indicator and. ring numbers (or ring bracket). The access indicator will specify whether the segment may be accessed in slave mode, written or executed. If the segment is a procedure (execute bit on) it will indicate if it should be executed in master or slave mode. Finally, it includes a fault bit which, when nonzero, causes a fault on any attempt to reference the segment, even when in master mode. The execution of a program implies the execution of one or more code segments. Associated with each program there exists a location counter, which contains current ring number, current segment number (of segment being executed) and current word number (within that segment). Each segment has an ordered. 3-vector (n , n„, n ) called a ring bracket where n < ru < n_. Basically a segment must always execute between rings n and n p , and may not be called by any program outside of n , i.e., a program running in a ring number bigger than n , as indicated by the program's location counter. Thus: 23 1. If the segment is called from inside n it runs at level n, . 2. If called from between n_ and n it runs at the caller's level. 3. If called from between n p and n it runs at level n p . In this case, a program called the gatekeeper is used to verify that the call goes to one of the legal entry points to this segment. k. Access from outside n is denied. In cases 1 and 3 the current ring number, in the location counter, of the program is changed to n or n p . Not doing so in case 1 would permit the called procedure to break the ring barrier, since it would be running with a lower ring number than authorized. Failing to change the program's ring number in case 3 would probably make it impossible for the called segment to accomplish its work due to lack of authority. The MULTICS policy is to change the current ring number as little as possible, i.e., by the smallest margin. In summary, in case 2 no modification in status is needed. In all other cases an interrupt occurs. If it turns out to be case 1, only same information is kept in a running stack for the return moment, and the current ring number is changed to n, . If it happens to be case 3 or k, then the special monitor, the gatekeeper, is called to verify if the intended entry is one of the valid points, or gates, and as a result either acting as in case 1 (honoring the call but changing the current ring number by a minimal margin, i.e., to n ) or denying the access (case k) . 2k Data segments have a different interpretation. If our program is running in ring i we can read, and write data in segments with i < n , only read if n < i < n and no access is granted if i > ru. In the MULTICS system all programs and files are kept as segments in disk memory when inactive, so the ring mechanism provides file security and access control verification and enforcement. Just one question remains. How should arguments be passed? If we change the ring number we could get into a situation where the arguments are inaccessible for the callee. This imposes the necessity of copying the arguments which is what MULTICS does. 25 III. COMMEJNTS A. Multi-dimensional Security Program for a Generalized Information Retrieval System The idea of a multi-dimensional security program for a generalized information retrieval system (GIRS) [8] is a very valuable approach to solving security problems within data-banks, but not within a complete and multi-purpose system. We obtain some security only if we work within the GIRS system, but the security of the GIRS system itself is undefined. I must say that I do not like the implementation made by Carroll, et al. It simply is too restrictive in many directions and I can't find a justification for such restrictions—the answer could probably lie in the PDP-10 system which I do not know. First of all, I do not understand why they restrict themselves "to 99>998 records. The only places where they use such a figure is in the determination of the 7-digit line number, in the index table (to data records) contained in the header, and explicitly in each line. I do not understand why the index table (to data records) is needed at all, given that all records have the same number of items, that all items have the same number of lines (this is not mentioned but I infer it because the number of lines per item is given once in the header) and that no garbage collection is done on deleted records. Therefore, a very simple 26 way of computing the FORTRAN record number could be used instead. If such an idea is followed, the space used within each line to store the record- number, item-number and line-number is unnecessary and could be removed from the data base. The GIRS system seems to be very batch oriented, with commands that will, in general, refer to the entire data base; thus, a SEARCH command will probably imply a search of the full data base. The optional feature for locking records is something very difficult to use and probably useless. The idea of modulo- remainder is silly. Imagine yourself trying to find an appropriate place for a new register that should be seen by many but not all users. If the data base is rather full and each user has another modulo- remainder pair, the work could be prohibitively large, and we would need a computer to solve it! It seems to me that the GIRS system is somewhat expensive, from the point of view of storage. Having information only in multiples of 72 characters (with 8 additional for other purposes) can be very wasteful, especially if some items are variable length, e.g., if one item usually requires 5 characters but sometimes requires 100 we would always have to allocate 160 bytes. The paper is also a little incomplete, for example, no explanation about how elements are searched or stored is given. My conclusion is then that even though Carroll et al. have a good approach to obtain security within a data-base (and using only one access program), their implementation is rather poor and lacks many ideas of dynamic storage and retrieval commonly used in current systems. 27 B. The Formulary Model for Flexible Privacy and Access Controls As the author mentions [15] > since he does not consider in his model problems associated with operating system software bugs, administrative procedures, personnel, etc., it does not approach a comprehensive system. I must join Conway, et al. [10] in their concern about the implciit overhead not mentioned by the author. The invocation of all the procedures involved imply a run-time overhead that is very costly for situations where data- dependent security is not required. This is probably an important reason which prevented (by April 1972) the full implementation of the model for the Student Health System, since the partial implementation is able only to grant/deny read-only or read/write access to the entire file. Hoffman's paper seems to be the first one to consider data- dependent security and it therefore deserves an important place in the history of security. In summary, the basic limitations of this method as a comprehensive system relate to the author's decision to refer only to data-base security, and his neglect to estimate the implicit overhead caused by complete run-time checking. For a given data-base, this system furnishes security provided all references to the data-base are through legal calls to the author's software . C. On the Implementation of Security Measures in Information Systems I must confess that I like this paper [10] very much and I agree with the vast majority of the ideas that are brought up. 28 The idea of translation time checking is great and seems to me to be a very good solution. The only comments that I can make refer to the general implementation of their ideas. As the authors point out, their model could only be secure if contained within a secure environment. My feeling is that they do not arrive at a comprehensive system at any moment and that the possible problems to be solved before one gets a secure system, listed in section 7^ is rather short and incomplete. Let's take the Burroughs 67OO as an example. The E67OO is a segment oriented machine (no pages involved). Thus, each array, for example, is allocated as the exact number of words required by the system. This forced the B67OO designers to put much more care in the detection of illegal addressing, since, in general, other programs could be affected by this type of error. The solution was then a very strict hardware verification of index bounds, impossible to break. On the other hand, absolute addresses are never handled by a user, and pointers refer only to locations relative to an array. By the above discussion it would seem that the B67OO is an optimal host for the proposed model, since none of the "serious remaining problems" exist. In reality this is not the case and the B67OO is actually an insecure system. The operating system (MCP) could easily be fooled by a specially made tape. The use of the DCALGOL or ESPOL compilers by users could overcome any security measure, etc. 29 What I am trying to say is that Conway, et al. 's approach is really a good one, but still far from comprehensive. I must, however, agree that it is a proper initial step and a big one. A second comment is about the complete lack of hardware considera- tions in the general implementation. Clearly, the combination of hardware and software will give a much stronger basis for solving, in an economic way, the "serious remaining problems. " Finally, I will just make a brief comment about the idea of introducing some security measures into the standard compilers. My feeling is that some security measures are really "correctness measures" and should in any case be incorporated in standard compilers, at least for pedagogical reasons. New students will generally make involuntary mistakes when they produce an invalid index rather than use it as a tricky way for some strange requirement and my question is: Should we detect such errors and notify the user? JD. Security Controls in the ADEPT-50 Time- sharing System The ADEPT-50 [24] seems to be one of the best approaches for comprehen- sive security if we accept the restrictions imposed by current commercial equipment. However, it is still far from being comprehensive. As is easily seen, the ADEPT-50 lacks any type of security below the file level, i.e., no protection against the "Trojan horse" problem is given, and there exists either total or no access to all information. Clearly, no data-dependent or even time-dependent access to files is given, and granting access means granting access to the full data-base 30 which violates the need-to-know property so strongly recommended by the author (unless data duplication is used in such cases). My feeling about the overhead I/O figure, 5 to 10 msec per call, is that it is intolerably high. For a standard industrial moving head disk, assuming no seek time (sequential read), an average access is the order of 12.5 msec per read, which means that we would have as much as kO to 80 percent overhead, if used in ADEPT. This figure is only acceptable if we start with a military system that runs in a sequential one -program- only fashion. Some further work in the hardware area and in the secure-translator field (Conway, et al. [10]) would probably assist in looking for a better solution. From the administrative viewpoint, the ADEPT-50 relies very much on the system programmer's loyality. Giving the system programmer an authority over all other user authorities is risky and would be unacceptable to many security administrators. In summary, this paper describes a very good approach to security within the actual commercial and military environments, but it also seems very rigid and closed to new ideas (such as interprogram communication). The I/O overhead figures leave something to be desired and security below the level of files is missing. E. Protection in an Information Processing Utility Graham's paper [13] describes a very good approach to comprehensive security, with very strong interaction between software and hardware for that purpose. The ideas are simple and seem to work nicely in the environment described. But, once more, it is not as yet a comprehensive system. 31 No provision exists in MULTICS for protection lower than, the file level. The "Trojan horse" problem remains as alive here as in the ADEPT-50, with an all-or-none authorization schema for file accesses. Graham's article is a little incomplete in the sense that no word is mentioned about user codes or passwords to the system or segments, nor about handling memory residues. If we go by what is said there, assigning a ring bracket to a procedure is rather a difficult decision. We are trying to map the security hierarchy into a single line and this may not always be possible. To see this, let's suppose that we have three procedures : A, B and C, each with different users and each with access bracket (nL, n2 , n 3 v ) (k = a, b or c). We want A to call B but not C, B t< call C but not A, and C to call A but not B. Thus, if a, b, and c are the ring numbers that the location counter will have when A, B and C are respectively running, we have : a < n3, , a > n3 (A can call B but not C) — b c b < n3 , b > n3 (B can call C but not A) C £1 c < n3 , c > n3, (C can call A but not B) a d or in another order: a < n3,, n3^ < c, c < n3 , n3 < b, b < n3 , n3 < a D D B. 3, C C which implies a < a and thus, impossible to solve with the described model. In one of the references in the paper Corbato, et al. [11] mentions that in MULTICS a user is assigned to each segment, and the user has the capability of mentioning other users that could use his segment, my feeling is that that idea should have been mentioned in Graham's paper. 32 With the addition of user code there will exist a way of getting by the above problem, namely, to use different user codes for each segment and deny access to the user code corresponding to the segment which is to be denied access. The above example was mentioned to show that assigning of a ring bracket is not trivial, but, if handled carefully and with some help, will make the model workable. The inclusion of the user code for a segment is a must if the ring numbers are going to be assigned by the user, since if two users happen to choose, let's say, the same ring bracket, no protection for one against the other exists. 33 IV. SUMMARY I would say that a system is secure when the access to any one of the machine resources containing user information is controlled by the user who initially stored such information. No access should be granted to information if the proper authorization is not given; this includes main and secondary memory, either in active or inactive (residues) form. As it was pointed out in the introduction, there does not exist a completely secure system. Instead of dealing with an idealized approach to a secure system we should pay attention to minimizing the vulnerability to security hazards. In the introduction I justified restricting myself to security controls built into a data processing system, assuming that all other security types are not a matter of concern- -I further neglect the occurrence of malfunctions. In summary, we are dealing with an idealized system where the only problem is to protect the community of legal users against themselves, and we then try to get to a secure system. Unfortunately, even with all the above assumptions, such a system does not yet exist in a cost-effective version, with the military solution discussed next, being the only one in such a category. The minimization problem should not be viewed as a goal by itself — there are many trade-offs. One extreme is to minimize vulnerability regardless of cost, as in the military solution of a one-program dedicated 3h computer. A computer is assigned to one program at a time, with a memory cleaning phase following such program. The cost involved is clear: underutilization of computer power by not utilizing multiprogram and time- sharing techniques, waste of time in erasing memory, difficulties for sharing, etc . Another extreme could be the current manufacturer's general approach -do as little as possible if it implies any throughput degradation. The cost of leaking information is thus neglected. The cost of the first approach is enormous and the solution introduces other problems such as the difficulty of sharing hardware. In the latter case, the cost, as viewed from a throughput analysis, is practically zero. The security obtained is almost non-existent. It is my belief and, I guess, the unstated belief of the authors of the presented papers, that good solutions exist between these two extremes. A reasonably secure system should clearly satisfy the user's security needs, but efficiency should not be sacrificed by imposing unacceptable additional costs as the military approach does. Identifying the user's security needs is not a simple task--we should start by defining what do we mean by "user. " In the following discussion we will simply identify the word "user" with the community of users of a multipurpose computer. The needs of a community of users are certainly of a diverse nature; some users wish to share data and procedures. Some others, like commercial competitors, would require to be protected against each other. A third group, for example, software producing companies, will have 35 programs that they want to rent. In summary, a community of users needs a flexible but controlled, access to shared information. Now we can expand a little more the concept of a reasonable secure system. It should first of all satisfy the requirements established at the beginning of this section to be called secure. It should try to take advantage of existing computer power (such as multiprogramming) and should finally permit users to share information by imposing selective security. Cost-effectiveness should be used to compare such systems and even to establish their feasibility. The selective security should be contemplated from various levels, starting with the selection of users allowed on the system, to the terminals, then to programs and files, to records within a file, and finally, to fields within a record (the last two are called protection I levels three and two respectively by Carroll, et al. [8]). The vital question arises: How? ... How do we go about implementing such a reasonably secure system? The described papers are an incomplete answer to this question. A real life implementation of a security system is extremely dependent on the actual machine that we are dealing with, but some kind of generalization or compromise must be made for the purpose of this paper. We then impose the Utopian goal of "as machine independent as possible" for the following discussion. By so doing we can concentrate on underlying principles and avoid endless debates on the relative merits of different vendor hardware. The first property of a secure system should be to be able to protect users from each other; more specifically, the initial concern 36 should be to protect the operating system from any other user. Any information inside a computer is managed and moved around by the operating system. Not making the proper distinction between operating system and other programs threatens not only the security but the complete operation of a computer. This fact is widely accepted, and a common solution is to have two system states: master and slave. The computer is in the first one when operating system's code is being executed and in the second one if such is not the case. Furthermore, some instructions could be ■ protected instructions, meaning that they could only be executed in the master state. One common way to break security is to make the operating system fool itself by either writing into space allocated for its code or making it execute code created by the user in one of his data areas. A way of protecting against this danger is mentioned in Graham's paper [13] for the MULTICS system, where various protection bits are assigned to each segment and verified by the hardware each time that a segment is accessed. Each segment contains an "access indicator" which specifies whether the segment may be accessed in slave mode, written or executed. Further, if the segment is a procedure it specifies whether the procedure is to execute in master mode rather than in slave mode. Finally, it includes a fault bit which when nonzero, causes a fault (or trap or interrupt) on any attempt to reference the segment, even when in master mode. In order to protect the operating system as well as concurrent users from each other, a user should not be able to break the barrier of his own environment. His code should allow him access only to his own 37 data (read/write) and procedures (read only) (own in the above context means that he is making legitimate use of it and it could mean the legitimate shared use of somebody else's data or procedures). Invalid index checking should be included. A few alternative solutions are available : using a preprocessor to check legality at compile time, generating additional code (and overhead) to verify legality at run-time (both of them mentioned by Conway, et al. [10]), or to rely on a hardware verification, as the MULTICS and the B67OO machines do. If the operating system is able to protect itself, then many other secondary benefits are gained, as for example, a controlled access to files is almost automatically obtained, since all information needed to deny or grant access to those files could be thought of as data of the operating system. We should then put special emphasis on safeguarding the operating system. All possible dangers should be studied in systems where there exist a super powerful language especially made for the operating system (ESPOL for the B67OO). Its use should either be forbidden or carefully monitored. Simple threatening hazards such as the acceptance of tapes or disk-packs containing code generated elsewhere should not be overlooked, and should either be forbidden or very carefully checked. Sharing of procedures should be enforced, but in a well defined way, MULTICS ' s gatekeeping idea seems reasonable [13]. Clearly, parameter verification should be performed, especially when they are specified by absolute addresses. Data sharing should also be available; this requirement emphasizes the need for some multiaccess control- -many users could be attempting 38 to access and modify the same records simultaneously. Hoffman's paper [15] gives one of the possible solutions, namely, to add such operations as STORELOCK, FETCHLOCK, LOCKLIST, etc. as an integral part of the system. Next, we should take care of inactive information, also known as residues. Weissman's discussion [2h] seemed to be fairly complete, and adopting the proposed ideas would give us the desired protection. Finally, we get to the point where protection types 2 and 3 (as in Carroll, et al. [8]), i.e., from file down, must be taken care of. . Interestingly, the discussed papers seem to obey some strange dichotomy rule : either they attack the security problem from the file level up or else from the file level down, but never both. Conway, et al. [10] is the only one who speaks in a broad, incomplete and quick fashion of the necessity of dealing with the other half of the problem — in his case, protection from the file level up. If we follow the -guidelines of the papers studied, we could approach a comprehensive system in two ways: a) from the top down, by building the file level down protection into one of the available systems: ADEPT-50, MULTICS, etc. or b) from the bottom up, which would require constructing reliable environment for a file level down working subsystem. The latter attack is followed and discussed by Conway, et al. [10] From the available information, it now seems logical to me to suppose that some merging between a file-up and file-down subsystem could lead to a comprehensive secure system, as for example, the combination of Graham's (MULTICS [13]) and Conway, et al. 's [10] systems. Unfortunately, there are many omissions in the literature, and the above conclusion could 39 be false (for example, none of them mentions the word residues or inactive information). A few words about a cost-effective analysis are needed. Even though the above combination could lead us to a comprehensive secure system, it will probably not correspond to the most cost-effective solution. MULTICS is a fairly expensive system, and probably unfeasible for many existing systems with security needs. My feeling is that the next step should be a deeper study of the concepts discussed here, with, probably, a more specific system in mind, which could lead to a well-defined project and perhaps an actual implementation of a comprehensive security system. Uo LIST OF REFERENCES [1] Amir, M. , "Computer Embezzlement - Prevention and Control," The Computer Bulletin , Vol. 15, 11 (Nov. 1971), 397-^00. [2] Anderson, R. E. and Fagerlund, E. , "Privacy and the Computer - An Annotated Bibliography, " Bibliography 30, Computing Reviews , Vol. 13, 11 (Nov. 1972), 551-559. [3] Babcock, J. D., "A Brief Description of Privacy Measures in the RUSH Time- sharing System, " Proc. AFIPS 1967 Spring Joint Computer Conference , Vol. 30, 301-302. [h~\ Bates, W. S., "Security of Computer-based Information Systems," Datamation , Vol. 16, 5 (May 1970), 6O-65. [5] Beardsley, C. W., "Is Your Computer Insecure?" IEEE Spectrum , Vol. 9, 1 (Jan. 1972), 67-78. [6] Boethe, R , "Hello Computers, Goodbye Privacy; or 1984 is Just Around the Corner, " Cosmopolitan , Vol. 166 (June 1969), 116-119, 170-171. [7] Carroll, J. M. and McLelland, P. M. , "Fast 'Infinite-key' Privacy Transformation for Resource Sharing Systems, " Proc. AFIPS 1970 Fall Joint Computer Conference , Vol. 37, 223-230. [8] Carroll, J. M. Martin, R., McHardy, L. and Moravec, H. , "Multi- dimensional Security Program for a Generalized Information Retrieval System, " Proc. AFIPS 1971 Fall Joint Computer Conference , Vol. 39, 571-577. [9] Conway, R. W., Maxwell, W. L. and Morgan, H L. , "Selective Security Capabilities in ASAP - A File Management System, " Proc. AFIPS 1972 Spring Joint Computer Conference , Vol. k-0, II8I-H85. [10] , "On the Implementation of Security Measures in Information Systems, " Communications of the ACM , Vol. 15, k (Apr. 1972), 211-220. [11] Corbato, F. J. and Vyssotsky, V. A., "Introduction and Overview of the MULTICS System, " Proc. AFIPS 1965 Fall Joint Computer Conference , Vol. 27, 185-196. [12] Ervin, S. J., The Computer -individual Privacy. Vital Speeches of the Day, Vol. 33 (May 1967), 421-426. 1+1 [13] Graham, R. M. , "Protection in an Information Processing Utility," Communications of the ACM , Vol. 11, 5 (May 1968), 365-369. [lU] Hansen, M. H. , "Insuring Confidentiality of Individual Records in Data Storage and Retrieval for Statistical Purposes, " Proc. AFIPS 1971 Fall Joint Computer Conference , Vol. 39, 579-585. [15] Hoffman, L. J., "The Formulary Model for Flexible Privacy and Access Controls, " Proc. AFIPS 1971 Fall Joint Computer Conference, Vol. 39, 587-6OI. [16] Lampson, B. ¥., "Dynamic Protection Structures," Proc, AFIPS 1969 Fall Joint Computer Conference , Vol. 35, 27-38. [17] Martin, J., Security, Accuracy and Privacy in Computer Systems , Prentice-Hall, Inc., Englewood Cliffs, New Jersey, 1973. [18] Palme, J., "Software Security, " Datamation , Vol. 20, 1 (Jan. 197*0, 51-55. [19] Parker, D. B. and Nycum, S., "The New Criminal," Datamation , Vol. 20, 1 (Jan. 197*0, 56-58. [20] Schwartz, B., "The Social Psychology of Privacy," American Journal of Sociology , Vol. 73 (May 1968), 7*^1-752. [21] Sodomka, D., "Cable TV of Future Could be Used to Spy," Chicago Daily News Service in Minneapolis Star (Feb. 2, 1972). [22] Trabbold, W. E., "The Privacy Trap," Journal of Commercial Bank Lending , Vol. 51 (Nov. 1968), 37-*+2. [23] Weiss, H. , "Computer Security - An Overview," Datamation , Vol. 20, 1 (Jan. 197*0 *+2-V7. [2k] Weissman, C, "Security Controls in the ADEPT- 50 Time-sharing System," Proc. AFIPS 1969 Fall Joint Computer Conference . Vol. 35, 119-133. [25] Westin, A. P., "The Snooping Machine," Playboy , 5 (May 1968), 130-157. BIBLIOGRAPHIC DATA SHEET 1. Report No. UIUCDCS-R-75-725 2. 3. Recipient's Accession No. i. Title and Subtitle Comprehensive Security in Data Processing Systems - The State of the Art 5- Report Date May 1975 6. '. Author(s) Enrique Grapa 8. Performing Organization Rept. No. }. Performing Organization Name and Address Department of Computer Science University of Illinois Urbana, Illinois 10. Project/Task/Work Unit No. 11. Contract /Grant No. 12. Sponsoring Organization Name and Address Department of Computer Science University of Illinois Urbana, Illinois 13. Type of Report & Period Covered 14. 15. Supplementary Notes 16. Abstracts A search of comprehensive security systems through available literature was performed with emphasis on existing systems. Five systems are presented, and their relative advantages and disadvantages are discussed. Unfortunately, none of them offers comprehensive security. An unexpected dichotomy is described. The papers tend to cover either security from the file up (operating system, memory residues, etc. ) or from the file level down (records within a file, fields within a record, etc. ) Finally, requirements for a comprehensive system are presented. 17. Kcj Words and Document Analysis. 17a. Descriptors Security Comprehensive security Shared information 17b. Idcntif iers /Open-Ended Terms 17c. i os..\ | | | ic Id/Group 18. A\ ailabiliry Stalemcni 19. Security ( lass (This Report) UNCLASSIFIED 21. No. of Pages 20. Security Class (This Page UNCLASSIFIED 22. Price I '"" Nil-, ib 1 10 ,,,, USCOMM-DC 41329-P7I 4» # <0 a. UJ CO