by NORMAN R. NIELSEN, BRIAN RUDER and DAVID H. BRANDIN Stanford Resea.rch Tnstitute
Menlo Park, California
ABSTRACT
This paper reports the findings of a project to identify types of computer system integrity safeguards that would have been effective in preventing, detecting, or mitigating the effects of actual reported incidents of computer system integrity violations. More than 350 cases were analyzed and categorized among one of 26 types of violations and among one or more of 34 types of applicable safeguards. Brief definitions are provided for all categories, and distributions of incidents over the various violation categories and over the applicable safeguards are presented.
The analysis revealed that most safeguards have a surprisingly narrow range of applicability, whether measured by number of cases or by number of tion categories affected. However, much broader viola-tion coverage is possible through use of combinaviola-tions of small numbers of safeguards. Directions for fur-ther research are discussed, including the need to de-velop measures of violation category importance and to include a consideration of safeguard cost, effec-tiveness, and operability factors.
INTRODUCTION
The history of computing is marked by periods of spe-cialized concerns, such as those for the development of high level programming languages and time-sharing systems. Currently, there is intense interest in com-puter security and related topics such as privacy and data confidentiality. A number of research projects have been and are being conducted in such areas as physical security equipment, secure operating system kernels, program certification, data encryption, opera-tions procedures, personal identification, and audit practices. While the developments in all these areas are effective against certain types of problems, no general appraisal has been made of their effectiveness against actual computer security problems.
System integrity is used herein to refer to the re-lated and overlapping concerns of:
• Security (protecting system integrity from com-promise)
75
• Audit (verifying the continued existence of sys-tem integrity)
• Recovery (restoring system integrity and oper-ability in the event of the loss of such integrity).
Computer system is broadly defined to encompass not only the computer hardware and software but also the computer facility itself. Thus the operations associ-ated with that facility are included, from the initial capture of input data to the final usage of output in-formation by the user. Within the broad perspective of computer system integrity maintenance, the ques-tions of interest concern:
• The safeguards that the user should implement first
• The areas in which development efforts should be focused
• The directions in which future research should be guided.
This paper reports an effort to identify the types of system integrity safeguards that would have been ef-fective in preventing, detecting, or mitigating the effects of actual reported computer system integrity violations. Although the representativeness of the known cases of system violation relative to the total population of actual violations is unknown, this paper does provide some initial information concerning the types of safeguards applicable to the types of viola-tions that are occurring. The scope of potential threats to computer system integrity is vast; hence if a system integrity maintenance budget is to be allocated mean-ingfully, attention must be focused on the likely threats and the relevant tools for defending against those threats.
The second section describes the integrity violation information used in this research, the third section the categorizations of violations, and the fourth sec-tion the safeguards. The fifth secsec-tion discusses the relationship of the types of violations being experienced to the various types of safeguards. The directions sug-gested for further research are indicated in the last section.
CASE FILE OF COMPUTER SYSTEM INTEGRITY VIOLATIONS
The computer abuse case file collected by Donn B.
Parker was used as the basis for categorizing both violations and safeguards. This file, described by Parker! in 1973, now contains information on more than 350 computer incidents. The cases have been collected over a number of years, with information ob-tained from newspaper articles and other published reports, from personal contacts, and from a number of in-depth interviews with victims and perpetrators.
The information available about an incident ranges from a two-inch newspaper clipping to several hun-dred pages of transcripts and investigatory notes.
It is suspected that, in the history of computing, there have been far more than 350 cases of system in-tegrity violations. However, most of these incidents, for various reasons, have not been reported and in some cases have been actively suppressed. Hence, small as the 350-case sample may be, it represents the most complete coverage available of the known com-puter system integrity violations.
Each case in the file was studied, and a one-page summary data sheet was filled out. Exhibit I shows
1.
2.
3.
4.
8.
9.
10.
EXHIBIT I-Computer Incident Summary Sheet Questionnaire Date _ _ Analysis Complete 0 Analysis Incomplete 0 Case Number 5. Categories: _ _ _ _ _ Source
Discovery Date Event Date/Duration
Accidental 6. Type of person (s)
in-Intentional volved: _ _ _ _ _ _ _
Unauthorized use of
au-thorized facility 7. Number involved: _ _ _ Intent of perpetrator:
Success of perpetrator:
Brief description:
11. Follow-up information: _ _ _ _ _ _ _ _ _ _ _ _ _ 12. Preventive measures: _ _ _ _ _ _ _ _ _ _ _ _ _ _
the form that was used for this purpose. The collec-tion of summary sheets then became the primary data base on which the remainder of the investigation was based.
INTEGRITY VIOLATION CATEGORIES
In analyzing the types of system integrity violations against which various types of safeguards might be effective, it is helpful to be able to deal with classes or categories of violations rather than with a long list of specific violations. Accordingly, the violation case file was categorized by type of violation.
Each case was studied and given a brief descriptive label. These labels were then collected, refined, and consolidated to form a tentative set of 26 violation categories. Each case was then re-examined by a dif-ferent analyst and placed into one of the new cate-gories. Differences in placement between the original assignment and the reassignment were resolved, so that there was consensus over the assignment of each case to one and only one of the violation categories.
It should be noted that the choice of 26 categories is not sacred. The categories simply represent a con-densation of the various violations for the convenience of this study. It would have been possible to develop only ten categories or as many as 50 categories, if we had found that helpful.
There is as yet no definitive and universally ac-cepted mechanism for determining the precise viola-tion occurring in a given case. Most cases represent a combination of violations. For example, a person enters a restricted area (e.g., a computer room) with-out authorization, which can be considered one type of violation. Having gained access, the perpetrator then uses the computer in an unauthorized manner or for an unauthorized purpose, which can be considered a different type of violation. The problem is determin-ing which type of violation was the "real" violation.
As a result of such ambiguities, the assignment of cases to the various violation categories is a subjective process. While the placements we have made may not be suitable for all purposes, the subjective nature of our assignment process does not detract from the value of these data to the study. It must be remembered that the categorization of violations serves only to stimulate the isolation or development of safeguard concepts having practical application to the problems actually being experienced.
After all the cases had been reviewed and catego-rized, 62 were discarded from further consideration.
Most of those discarded cases were eliminated because the available information was too sketchy or so vague that it would have been impossible to identify appli-cable safeguards. A small number of cases were also eliminated because they closely paralleled other cases for which more extensive information was available.
The distribution of the 293 remaining cases across
Effective Safeguards for Computer System Integrity 77 activities taking place outside the computer itself.
However, lest incorrect conclusions be drawn, it is im-portant to note that the distribution figures represent incidents and not a random sampie of the full popula-tion of incidents. Thus, the concentrapopula-tion of cases noted above may indicate that a preponderance of vio-lations are of this type or that a greater percentage of the violations in these categories are reported or otherwise become known.
SAFEGUARD CATEGORIES
In analyzing the types of system integrity violations against which various safeguards might be effective, it is helpful to be able to deal with classes or categories of safeguards rather than with a long list of specific safeguards. In the early stages of analysis, it is more helpful to deal, for example, with a category called
"personal identification procedures" than it is to deal with a list of specific safeguards such as "badge with photograph, machine readable badge, handprint, fin-gerprint, signature, and password." Accordingly, the
T ABLE I-Case Distribution Over Violation Categories Number of
Cases 1. Application Software :Manipulation 29
2. System Software Manipulation 18
3. Contract Mistakes 3
4. Improper Lse of Personal Identification 2 5. :Misuse of System Authorization 4
12. Unauthorized Building Access 20
13. Violation of Operating Procedures 20 14. Unauthorized Use of Terminal Area 4 15. Misuse of Communications Equipment 4 16. Management Inaction or Misaction 3 1. Application Software ManipUlation-Direct manipulation
or change of application programs, in the design, imple-mentation, or maintenance stages.
2. System Sofbvare Manipulation-Direct change to or non-standard use of operating system functions or utilities, 3. Contract IVlistakes-Poor contract specifications, permitting
integrity violations.
4. Improper Lse of Personal Identification-Use of personal identification mechanism (e.g., a badge) by an unauthorized person to obtain information or money.
u. ~lisuse of System Authorization--... A;r..n other,Xlise authorized person performing a legitimate task, but one for which he or she is not authorized.
6. Destruction of Data-Physical or logical destruction of data.
7. Unauthorized Copying of Data-Copying files or other data for personal use or resale without authorization.
8. Misuse of Passwords-Unauthorized use of passwords to gain access to computer system.
9. Direct Change of I/O Data-Alteration of computer input data before its entry into the computer system.
10. Adding to I/0 Data-Adding data to the computer input stream or to computer outputs after processing.
11. Personnel Practices-Errors or oversights that result in improper privilege level assignments to staff members.
12. unauthorized Building Access-Unauthorized building access for theft or vandalism.
13. Violation of Operating Procedures-Authorized persons violating computer room procedures or access controls for theft of hardware supplies or for vandalism.
14. Unauthorized Use of Terminal Area-Unauthorized access to the terminal area or use of terminal equipment in un-authorized ways.
15. :Misuse of Communications Equipment-:vlisuse of com-munications equipment such as lines, multiplexors, and front-ends but excluding terminals.
16. Management Inaction or Misaction-Failure of management to act or improper action because of lack of understanding of computing.
17. Unauthorized Use of Services-Use of computer sex-v"ices in an unauthorized manner (e.g., without payment).
18. Unethical Behavior-Violation of the "reasonable man"
ethical standard.
19. Software Theft-Theft of programs or program documen-tation.
20. Improper Training-Errors made by personnel receIvmg inadequate or improper training for their assigned duties.
21. Katural Disasters-Damage arising from earthquake, fire, or explosion, flood, etc.
24. Accident-Accidental damage to or destruction of data.
25. Negligence-Destruction of data, supplies, or equipment through negligence of personnel.
26. Miscellaneous-violations that do not fit into any of the above categories.
violation case file was categorized by the types of safe-guards that would have been effective in preventing, detecting, or mitigating the effects of those violations.
Each case was studied and given a set of brief de-scriptive labels. Each label described a safeguard that, had it been applied, would have altered the outcome of
the incident. Generally two to four safeguards were identified for each case. These labels were then col-lected, refined, and consolidated, and a tentative set of safeguard categories was formed.
The safeguard categories were themselves analyzed and organized into a set of four generic categories.
Each generic category was re-expanded into a set of carefully defined subcategories. Each case was then re-examined and recategorized using the refined cate-gories. This reassignment of cases resulted in one additional round of refinements before the present 34 subcategories were defined and established.
The four generic categories of safeguards are:
• ]danagementsafeguards
• Systems safeguards
• Industrial security safeguards
• Legal and educational safeguards
Figure 1 illustrates the hierarchical organization of the safeguard categories, and Exhibit III provides a brief definition of each. Systems safeguards constitute the principal technical defense against computer sys-tem integrity violation. Management safeguards are more conventional and less difficult to implement. In-dustrial security safeguards are the familiar and well understood "physical security" safeguards. The legal and educational safeguards are essentially longer term
measures that apply to society as a whole rather than to the environment of a specific organization.
The determination of helpful safeguards for cases faces subjective problems similar to those encountered in assigning cases to violation categories, although the freedom to specify several safeguards eliminates the problem of specifying the safeguard for multiple vio-lation situations (i.e., a situation in which viovio-lation A was committed so as to be able to commit violation B).
However, the categorization problem for each specific safeguard proposed still remains, analogous to the cate-gorization problem for each violation. Consider the specification of a test procedure to be used as a safe-guard in the installation of operating system modifica-tions. Is such a safeguard more appropriately classified as a management procedure, an operations procedure, or a software interface procedure? Thus, a large de-gree of subjectivity exists in the selection of applicable safeguard categories for cases.
Table II shows distribution of cases across the vari-ous types of safeguards that might have been appli-cable in defending against the violation that occurred.
Note that the total number of applicable safeguards is 738, making an average of 2.5 safeguards for each of the 293 cases. It is interesting to note that the two types of safeguards identified as being applicable to the largest number of cases (Audit Procedures, Data
Figure I-Safeguard schematic
Effective Safeguards for Computer System Integrity 79
EXHIBIT III-Protective Categories MANAGEMENT SAFEGUARDS
• Audit-Use of internal and external audits to validate the EDP system.
• Procedures and Operations-Establishment of management procedures that define and enforce operational procedures.
• Insurance Protection-Maintenance of adequate EDP in-surance protection.
• Personnel Practices-Investigation of new employees, moni-toring of anomalous behavior, and use of effective dismissal techniques.
• Contractual Protection-Use of contracts that address de-liverables, specifications, and liabilities.
• Inventory Control-Identification and control of all com-putational resources and hard copy forms.
SYSTEMS SAFEGUARDS Hardware
• Hardware Monitors-Use of independent devices for mea-suring system activity.
• Hardware Privilege-Use of hardware to control access to and use of system resources.
• Identification-Use of hardware devices to identify equip-ment and people accessing a computer system.
Software
• Detection and Prevention-Use of software to monitor and check program accesses to I/0 programs, utilities, and spe-cial hardware.
• System Software Interface-Use of software controls to monitor and limit references to operating system com-ponents and system utilities.
• Restricted Language Processors-Development and use of families of language processors (and loaders) with in-creasing levels of priviiege.
• Transaction Logs-Use of serialized logs to record trans-actions, log-ons, I/O, and detected unauthorized accesses.
Systems and Operations Procedures
• Procedures and . Operations-Identification of work re-sponsibilities, separation of rere-sponsibilities, procedures for handling data, and increased sensitivity to security during abnormal times.
• Maintenance and Services-Use of procedures to ensure timely preventive maintenance and good quality control procedures for software maintenance.
• Quality Control-Use of stringent testing procedures for operating system software and assignment of quality con-trol to separate teams of programmers.
Reliability Safeguards
• Availability-use of environmental safeguards and archi-tectural configurations that facilitate modular recovery.
• Backup-Restart-Establishment and testing of restart pro-cedures, proper hardware/software backup, and a carefully monitored checkpoint/restart program.
Input/Output Safeguards
• Data Handling-Verification of input data, special handling of extraordinary input, shredding of surplus output, proper storage and backup of data and program files, and limited transmission of output to remote devices.
• Password Controls-Development and enforcement of pass-word procedures, updating of passpass-words, monitoring of invalid log-ons, and the use of passwords to verify devices and users.
• Communication Safeguards-Establishment of secure com-munications, hardwired lines, and use of intelligent front-end processors to supplement mainframe coding.
• Encryption-Encryption of sensitive files, including data, password, and accounting files.
INDUSTRIAL SECURITY SAFEGUARDS Environmental Safeguards
• Physical Integrity-"Cse of procedures to protect the physi-cal environment of the facility, the use of UPS, and the housing of computing facilities in structurally secure build-ings.
• External Support-Establishment of relationships with local police and fire agencies as well as monitoring vendor and other outside personnel in a computing facility.
• Business Threats-Management procedures for anticipating potential threats from competiti~le and other forces.
• Disaster Control-Establishment of provisions for reacting to natural disasters, e.g., drainage in the event of floods.
Recovery Safeguards
• Relocation and upgrade-Use of detailed procedures for maintaining system integrity during hardware upgrade or system relocation and comprehensive testing of all system modifica tions.
• Storage and Backup-Enforcement of operational pro-cedures for storing systems and data backup and documen-tation in off-site vaults, and the logging of all vault traffic.
Access Control Safeguards
• Guards-Use of building guards to control building access, monitor visitors, and to patrol restricted areas.
~ Alarms and Locks-Use of alarms to detect unauthorized entry and locks to limit traffic.
• Visitor Control-Use of proper identification procedures for all persons in the facility, validation of the purpose of all visitors, and investigation of all packages moving in and out of a computing facility.
• Surveillance and Monitoring-Use of surveillance and log-ging equipment to monitor activities in and around the computing facility.
LEGAL AND EDUCATIONAL SAFEGUARDS
• Legislative Safeguards-Formulation of civil and criminal codes that aid in apprehension and recovery in the event of viola tions.
• Education-Education of computer practitioners, the public, and law enforcement authorities, curricula developments in protective procedures, and improved professionalism.
Handling) are two areas that are not commonly treated by security research efforts aimed at develop-ing new tools and techniques. It is also interesting that none of the reported violations could have been aided by the application of system availability safe-guards. A third observation concerns the large num-ber of cases for which it was judged that some form of procedural development would have been effective, as opposed to some type of hardware or software tool or technique.
Care must be exercised in drawing conclusions from Table II, since the underlying cases do not necessarily represent a random sample of the full population of
Care must be exercised in drawing conclusions from Table II, since the underlying cases do not necessarily represent a random sample of the full population of