The New York Public Library
`
`Interlibrary & Document Services
`476 Fifth Avenue, New York, NY 10018
`212.592.7200 0 copies@nypl.org
`http://www.nypl.org/he1p/research-services/inter]ibrary—l0an
`
`Reference:
`
`TN : 497207
`
`To:
`
`Christine Wierzba
`
`» Bryan Cave LLP
`
`Date:
`
`September 2, 2016
`
`As requested, enclosed is a copy of the requested 1 document(s):
`
`IEEE Transactions on Software Engineering, Vol. SE-13, No. 2, February 1987 “Cover (wl date
`stamp), publisher information page, and pages 222-232 inclusive of the article “An intrusion -
`detection model,” by D.E. Denning.” (Inclusive w/ certification),
`
`A
`000001
`
`Symantec 10321
`|PR2015—O1892
`Symantec v. Finjan
`
`.
`
`000001
`
`Symantec 1032
`IPR2015-01892
`Symantec v. Finjan
`
`

`
`X
`
`The New York Public Library
`
`
`
`Interlibrary & Document Services
`476 Fifth Avenue, South Court Mezzanine, New York, New York 10018
`
`212.592.7200 ofax 212.391 .25020 copies@nyp1.org
`https://www.nyp1.org/he]p/research—services/interlibrary-loan
`
`September 1, 2016
`
`AFFIDAVIT
`
`STATE.OF NEW YORK}
`SS2
`
`COUNTY OF ,NEW YORK}
`
`I, Maurice Klapwald, Librarian/lnterlibrary & Document Services, The New York .Public Library,
`being duly sworn, depose and say:
`
`b
`
`That the attached reproductions, as described below, are true copies made from the original in
`the collection of this library.
`
`IEEE Transactions on Software-Engineering, February 1987, Volume SE—13, Number 2.
`Cover (w/date stamp), publisher information page & pages 222 — 232, inclusive of the article “An
`intrusion-detection model,” by D.E. Denning.
`
`
`
`1 £22’
`~
`(2541-c.
`-
`"0
`Maurice B. Klapwald‘
`Assistant Manager/ Librarian
`lnterlibrary & Document Services
`
`Subscribed and sworn to before me
`This 1st day of September 2016
`
`
`
`ALEXANDRA MARIE GR|FF_lYHS
`NOTARY PUBUC-STATE OF NEW YORK
`No. 016126169796
`
`Qualified In Kings County
`My Commlnlon Explre: July 02;
`
`OOOOO2
`
`000002
`
`

`
`H-wt
`
`flVQ*1J'(DG
`
`b'~'<'
`
`)1"
`
`1'6
`
`
`
`ilEEE TRANSACTIONS ON
`SOFTWARE
`gENGINEERIN
`
`
`
`FEB 3-
`1987
`
`NYPL
`
`-
`
`FEBRUARY 1 987
`
`VOLUME SE-"1 3
`
`NUMBER 2
`
`A PUBLICATION OF THE IEEE COMPUTER SOCIETY ®
`
`e(‘|SSN 0098-5589)
`A
`
`SPECIAL ISSUE ON COMPUTER SECURITY AND PRIVACY
`
`Guest Editors’ Note .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. V. D. Gligor and _D. J. Bailey
`
`125
`
`PAPERS
`
`Security Models
`
`'
`
`_
`
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Views for Multilevel Database Security .
`Lunt, M. Morgenstern, P. G. Neumann, and R. R. Schell
`.
`.
`.
`. D. E. Denning, S. G. Akl, M. Heckman, T.
`Extending the Noninterference Version of MLS for SAT .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`. J. T. Haigh and W. D. Young
`Specification and Verification Methods
`_
`.
`.
`.
`Muse—A Computer Assisted Verification System .
`. J. D. Halpern, S. Owre, N. Proctor, and W. F. Wilson
`.
`.
`An Experience Using Two Covert Channel Analysis Techniques on a Real System Design .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`. . .
`.
`.
`.
`.
`. J. T. Haigh, R. A. Kemmerer, J. McHugh, and W. D. Young
`A New Security Testing Method and Its Application to the Secure Xenix Kernel
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`'
`.
`.
`.
`.
`.
`.
`.
`.
`.
`. V. D. Gligor, C. S. Chandersekaran, W. D. Jiang, A.__Johri, G. L. Luckenbaugh, and L. E. Reich
`Towards a Formal Basis for the Formal Development Method and the Ina Jo Specification Language .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`129
`141
`
`151
`.
`157
`
`169
`
`184
`
`202
`
`.
`
`p
`
`I
`
`.
`.
`
`.
`.
`
`.
`.
`
`233
`. D. M. Nessett
`.
`.
`.
`.
`. D. Estrin 249
`
`J’
`Operating System Security
`'
`. R. Y. Kain and C. E. Landwehr
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.3.
`On Access Checking in Capability-Based Systems
`. V. D. Gligor, C. S. Chandersekaran,
`.
`.
`.
`.
`.
`.
`.
`.
`. . .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Design and Implementation of Secure Xenix .
`.
`.
`208
`R. S. Chapman, L. J. Dotterer, M. S. Hecht, W. D. Jiang, A. Johri, G. L. Luckenbaugh, and N. Vasudevan
`An Intrusion—Detection Model
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`. D. E. Denning 222
`Network Security
`Factors Affecting Distributed System Security .
`A Controls for Interorganization Networks
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`Cryptographic Algorithms and Protocols
`.
`.
`.
`.
`.
`Cycle Structure of the DES for Keys Having Palindromic (or Antipalindromic) Sequences of Round Keys .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`. ..:...............................J.H.MooreandG.J.Simmons 262
`The Interrogator: Protocol Security Analysis
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`. J. K. Millen, S. C. Clark, and S. B. Freedman 274
`
`w§J,.--
`A
`ICONCBEPAPERS
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Matching Secrets in the Absence of a Continuously Available Trusted Authority .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`C.MeadowsandD.Mutchler
`289
`. Covert Channels in LAN’s .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`. C. G. Girling 292
`
`. .‘.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`eir
`>a-
`on
`
`
`
`OOOOO3
`
`000003
`
`

`
`
`
`IEEE COMPUTER SOCIETY
`®
`.
`®
`The Computer Society is an association of people with professional interest in the field of computers. All members of the IEEE are eligible for membership in the Society upon payment of the annual Society
`membership fee of $15.00. Members of certain professional societies and other computer professionals are also eligible to be members of the Computer Society. For information on joining. write to IEEE
`Computer Society, I730 Massachusetts Avenue NW, Washington, DC 20036-1903.
`
`EXECUTIVE COMMITTEE
`President: ROY L. Russo
`President Elect: EDwARD PARRISH
`First Vice President for Educational Activities: MICHAEL C. MULDER
`Second Vice President for Technical Activities: KENNETH R. ANDERSON
`Vice President for Conferences and Tutorials: JAMES H. AYLOR
`Vice President for Area Activities: WILLIS K. KING
`Vice President for Publications: J. T. CAIN
`Vice President for Membership and Information; MERLIN G. SMITH
`Vice President for Standards Activities: HELEN M. WOOD
`Secretary: DUNCAN H. LAURIE
`Treasurer: JOSEPH E. URBAN
`Junior Past President: MARTHA SLOAN
`Director, Division V—C0mputer: MARTHA SLOAN
`Director, Division VIII—Computer: H. TROY NAGLE, JR.
`BOARD OF GOVERNORS
`
`,.
`
`,
`
`'
`
`Term Ending December 31, 1988
`Term Ending December 31, 1987
`MARIO BARBACCI
`LAUREL KALEDA
`BARRY W. BOEHM
`BRUCE D. SHRIVER
`VICTOR R. BASILI
`TED LEwIs
`PAUL L. BORRILL
`HAROLD S. STONE
`LORRAINE M. DUvALL
`MING T. LIU
`GLEN G. LANGDON, JR.
`WING N. TOY
`MICHAEL EVANGELIST
`EARL E. SWARTZLANDER, JR.
`DUNCAN H. LAWRIE
`HELEN M. WOOD
`ALLEN L. HANKINSON
`JOSEPH E. URBAN
`SUSAN L. ROSENBAUM
`AKIHIKO YAMADA
`PUBLICATIONS BOARD
`Vice President: J. T. CAIN
`Vice Chair: RICHARD C. JAEGER
`Secretary: WILLIS K. KING
`Publications Finance Chair: J. T. CAIN
`Publications Planning Chair: MICHAEL EVANGELIST
`
`’
`
`Computer:
`IEEE CG&A:
`IEEE Micro:
`IEEE D& T:
`IEEE Software:
`IEEE Expert:
`IEEE TC:
`IEEE TPAMI:
`IEEE TSE:
`CS Press:
`
`Editors-in-Chief
`BRUCE SHRIVER
`JOHN STAUDHAMMER
`JAMES J. FARRELL III
`VIsHwANI Ac.RAwA‘L" —
`TED LEWIS
`DAVID PESSEL
`MING T. LIU
`STEVEN L. TANIMOTO
`C. V. RAMAMOORTHY
`Ez NAHOURAII
`
`Advisory Committees
`Computer/Magazine Advisory:
`DENNIS R. ALLISON ‘
`Transactions Advisory:
`DUNCAN J. LAWRIE
`Computer Society
`Press Advisory:
`
`RICHARD C. JAEGER
`
`»
`
`'
`
`Reps. to IEEE Publications Board: BRUCE SHRIVER, THEO PAvLIDIs
`Rep. to CS TAB: NORMAN F. SCHNEIDEWIND
`Pubs. Rules and Practices Chair: DHARMA P. AGRAWAL
`
`THE INSTITUTE OF ELECTRICAL AND ELECTRONIC ENGINEERS, INC.
`,
`Officers
`
`~
`
`_
`HENRY L. BACHMAN, President
`MERRILL W. BUCKLEY, JR., Executive Vice President
`RAMIRO GARCIA SOSA, Secretary
`EDWARD J. DOYLE, Treasurer
`
`_
`
`RONALD G. HOELZEMAN, Vice President, Educational Activities
`CARLETON A. BAYLESS, Vice President, Professional Activities
`CHARLES H. HOUSE, Vice President, Publication Activities
`ROBERT S. DUGGAN, JR., Vice President, Regional Activities
`EMERSON W. PUGH, Vice President, Technical Activities
`MARTHA SLOAN, Director, Division V—Computer Division
`H. TROY NAGLE, JR., Director, Division VII[—Computer Division
`
`THOMAS W. BARTLETT, Controller
`DONALD CHRISTIANSEN, Editor, IEEE Spectrum
`IRVING ENGELSON, Staff Director, Technical Activities
`.LEO FANNING, Staff Director, Professional Activities
`
`Headquarters Staff
`ERIC HERZ, Executive Director and General Manager
`ELWOOD K. GANNETT, Deputy General Manager
`SAVA SHERR, Staff Director, Standards
`DAVID L. STAIGER, Staff Director, Publishing Services
`CHARLES F. STEWART, JR., Staff Director, Administration
`DONALD L. SUPPERS, Staff Director, Field Services
`THOMAS C. WHITE, Staff Director, Public Information
`
`Publications Department
`Publication Managers: ANN H. BURGMEYER, GAIL S. FERENC, CAROLYNE TAMNEY
`'
`Associate Editor: MINDY ELLIS
`
`IEEE TRANSACTIONS ON SOFTWARE ENGINEERING is published monthly by The Institute of Electrical and Electronics Engineers, Inc. Responsibility for the contents rests upon the authors and not upon
`the IEEE, the Society/Council, or its members. IEEE Headquarters: 345 East 47 Street, New York, NY 10017-2394. NY Telephone: 2l2—705 + extension: Information -7900; General Manager -79l0:
`Controller -7748; Public Information -7867; Publishing Services -7560; Spectrum -7556; Standards -7960: Technical Activities -7890. NY Telecopier: 212-752-4929. NY Telex: 236-41 l (international
`messages only). IEEE Service Center (for orders, subscriptions, address changes, Educational Activities, Region/Section/Student Services): 445 Hoes Lane, Piscataway, NJ 08854-4150. NJ Telephone: 201-
`98I-O060. IEEE Washington Office (for U.S. professional activities): I
`I ll 19th Street, NW, Suite 608, Washington, DC 20036. Washington Telephone: 202-785-0017. Price/Publication lnformatinn:
`.'
`and nonmember subscription prices availableon request. Available in microficheand microfilm. Copyrightand Reprint Permissions: Abstracting is permitted with credit to thesource. ll:ibraries are permitted to
`Individual copies: IEEE members Sl0.00 (lirst copy only). nonmembers $20.00 per copy. (Note: Add $4.00 postage and handling charge to any order from $1.00 to $50.00, including repaid orders.) Member
`j,‘
`photocopy beyond the limits ofthe U.S. Copyright Law For private use of patrons: l) those post-I977 articles that carry a code at the bottom of the first page, provided the per-copy lee indicated in the code is
`_'
`paid through the Copyright Clearance Center. 29 Congress Street, Salem, MA 0 l 970: 2) pre-l 978 articles without fee. Instructors are permitted to photocopy isolated articles for noncommercial classroom use
`without fee. For all other copying, reprint or republication permission, write to: Copyrights and Permissions Department, IEEE Publishing Services, 345 East 47th Street, New York, NY 10017-2394.
`Copyright © I987 by The Institute of Electrical and Electronics Engineers, lnc. All rights reserved. Second-class postage paid at New York, NY and at additional mailing offices. Postmaster: Send address —,
`chang®©6l66fl.NSACTl0NS ON S0I=rwARE ENGINEERING, IEEE, 445 Hoes Lane, Piscataway, NJ 03854.
`
`‘
`
`000004
`
`

`
`‘I
`
`222
`
`IEEE TRANSACTIONS ONISOFTWARE ENGINEERING, VOL. SE—13, NO. 2, FEBRUARY I987
`
`An Intrusion—Detection Model
`.
`,
`t
`_
`
`DOROTHY E. DENNING
`
`I
`
`
`I
`I
`
`P
`C
`a
`T
`
`ii
`' C
`
`5:
`0
`S.
`1''
`
`’
`
`.
`
`t
`
`,
`
`,
`fr
`—,
`I
`
`I
`
`,
`
`s
`
`‘
`
`’
`
`.
`W.
`r
`
`V,
`
`.
`.
`_ Abstract—A model of a r_ea_l-time intriusion-detection expert system gjng into a System through an unauthorized account and
`capable of detecting break-ins, penetrations, and other forms of com-
`password might have a difierent login time, rocation, or
`- puter abuse is described. The model is based on the hypothesis that
`_. Onnecfo t
`f
`th t
`fth
`.
`-
`t,
`1
`.
`.
`— t
`security violations ‘can be detected by monitoring a system’s audit rec-
`C
`_
`-n ype mm a 0,
`6 aCc_0un -S
`eg1_t1m_a e us_er‘
`ords -for abnormal patterns of system usage. The model includes pro-
`In addmona the? Penetrator S behaV1.0r may dlffer Consld‘
`files for representing the 'beliavior of subjects with respect to objects
`erably from that Of the legitimat_e user; in particular, he
`in terms of metrics and statistical models, and rules for acquiring might Spend most of his tjmc browsing through directories
`knowledge aboutlthis behavior from audit records and for detecting
`and executing System Status Commands’ I whereas‘ the le_
`-anomalous behavior. Thexmodel is independent of any particular sys-
`.
`.
`- t
`'
`. ht
`d; .
`-
`.1.
`tem, application environment, system vulnerability, or type" of intru-
`g1tun_a e_ user mlg Concentrate On_e lung or Com?‘ mg
`sion, thereby providing a framework for a general-purpose intrusion-
`and hnkmg Pr0gram5- Many break'1n.S have been d1Sc0V'
`detection expert system.
`ered by security officers or other users on the system who
`have noticed the alleged user behaving strangely.
`M
`0 Penetration by legitimate user: A user attempting to
`penetrate the security mechanisms in the operating system
`might execute different programs or trigger more protec-
`tion violations from attempts to access unauthorized files
`or programs. If his attempt succeeds, he will have access
`to commands and files not normally permitted to-him.
`0 Leakage by legitimate user: A" user trying to leak
`sensitive documents might log into the system at unusual
`times or route-data. to remote printers not "normally used.
`'0 Inference by legitimate user: A_ user attempting to _
`obtain unauthorized data from a database through aggre-
`gation and inference might retrieve more records than
`‘ usual. '
`
`Index Terms—Abnormal behavior, auditing,
`ing,'profiles, security, statistical measures.
`
`intrusions, monitor-
`
`I.
`
`INTRODUCTION
`
`HIS paper describes armodel for a real-time intrusion-
`’ detection. expert system _that aims to detect a wide
`range of security violations ranging from attempted break- -
`ins by outsiders to system penetrations and -abuses by in-
`siders. The development of a real-time intrusion—detec—
`.tiOn system is motivated by four factors: l) most existing
`_systems have security flaws that render- them susceptible
`to intrusions, penetrations, and other forms of abuse;
`finding and fixing all these_deficiencies is not feasible for
`technical and economic reasons; 2) existing systems with
`known flaws are not easily replaced by systems that are
`more secure—mainly because thelsystems have attractive
`features that arexmissing in the more-secure systems, or
`else they canriottbe replaced for economic reasons; 3) de-
`' veloping‘ systems that are absolutely secure is extremely
`diflicult, if not generally impossible; and 4) even the most
`secure systems are vulnerable to abuses by insiders who
`misuse their privileges.
`'
`_ The model is based on the hypothesis that exploitation
`of-a system’svulnerabilities involves abnormal use of the
`system;_ therefore, security violations could be detected
`from_ abnormal patterns of system usage. The following
`examples illustrate:
`.
`_
`° Attempted break-in: Someone attempting to break
`into a system might generate an abnormally high rate of
`password failures with respect to a single-account or the
`system as _a whole.
`0 Masquerading or successful break—in.' Someone log-
`
`
`
`r
`
`.0 Trojan horse: The behaviorof a Trojan horse planted
`in or substituted for a program may differ from the legit-
`imate program in tenns of its CPU time’ or 1/0 activity.
`0 Virus: A-virus planted in a system might cause an
`‘increase in the frequency of executable files rewritten,
`storage used by executable files, or a particular program
`being executed as the virus spreads.
`'
`'
`A
`0 D.enial—0f-Service: An intruder able to monopolize a
`resource (e.g., network) might have abnormally high ac-
`tivity with respect to the resource, while activity for all
`other users is abnormally low._
`'
`-
`Of course, the above forms of aberrant usage can also I
`be linked with actions unrelated to security. They could I
`be a sign of a user changing work tasks, acquiring new
`skills, or making typing mistakes; software updates; or
`changing workload on the system. An important objective
`of our current research is to determine what activities and
`statistical measures provide the best discriminating power;
`that is, have a high rate of detection and a low ‘rate of
`false alarms.
`'
`-
`
`,
`
`, Manuscript received December 20, 1985; revised August 1, 1986. This
`work wastsuppoited by the Space and Naval Warfare Command (SPA-
`WAR) under Contract 83_F830100 and by the National Science Foundation
`under Grant MCS—83l3650.
`.
`.
`i The author is with Sill International, Menlo Park, CA 94025.
`IEEE Log Number 8611562.
`
`'
`
`000005
`
`II. OVERVIEW. OF MODEL
`The model is independent of any particular system, ap-
`plication environment, system vulnerability, or type of in-
`trusion, thereby providing a framework for a general—pur—,
`0098-5589/87/0200—0,222$0l.00 © 1987 IEEE.
`
`000005
`
`

`
`
`
`DENNING: INTRUSION—DETECTlON MODEL
`
`pose intrusion—detection expert system,,which we have
`called IDES. A more detailed description of the design
`and
`application of
`IDES is
`given
`in
`our
`final
`report [1].
`The model has six main components:
`0 Subjects: Initiators of activity‘ on a target system—
`normally users.
`I
`0 Objects: Resources managed by the system—files,
`: commands, devices,'etc.
`'
`j
`0 Audit records.‘ Generated by the target system in re-
`’ sponse to actions performed or attempted by subjects on
`’ objects—user login, Command execution, file access, etc.
`-_ Profiles.‘ Structures that “characterize the behavior of
`subjects with respect-to objects in terms of statistical met-
`rics and models of observed activity. Profiles are auto-
`matically generated and initialized from-templates.
`0 Anomaly records: Generated when abnormal behav-
`ior is detected‘.
`
`nd
`
`'f9I
`
`7
`ies :
`
`,
`
`I
`
`223
`
`clude such entities as files, programs, messages, records,
`terminals, printers, and user— or program—created struc-
`tures. When subjects can be recipients of_ actions (e.g.,
`electronic mail), then those subjects are also considered
`to be objects in the model. Objects are grouped into
`classes by type (program, text file, etc.). Additional struc-
`ture may also be imposed, e.g., records may be grouped
`into files or database rel_ations; files may be grouped into
`directories. Different environments may require different
`object granularity; e.g., for rsomedatabase applications,
`granularity at the record level may be desired, whereas
`for most applications, granularity at the file or directory
`level may suflice.
`'
`’
`
`IV. 'AU)iT RECORDS
`Audit Records are 6—tuples representing actions per-
`formed by subjects on objects:
`<Subject, Action, Object, Exception-Condition,
`Resource-Usage, Time—stamp>
`,
`V
`«
`where
`'0 Action: Operation performed by thensubject on or
`with the object, e.g., login, logout, read, "execute.
`0 Exception—Condition.' Denotes which, if any, excep-
`tion condition is raised on the return. This should be the
`actual exception condition raised by the system, not just_
`the apparent exception condition returned to the subject.
`0 Resource— Usage.‘ List of quantitative
`elements,
`where each element gives the amount used of some re-
`source, e. g. , number of lines o.r pages printed, number of
`records read or written, CPU time or 1/0 units used, ses4
`sion elapsed time.
`A
`_
`_ 0 Time—st'amp.' Unique time/date stamp
`identifying
`_
`when the action took place.
`'
`We assume that each field is self—identifying, either im-
`plicitly or explicitly, e.g., the action field either implies
`the type of the expected object field or else the object field
`itself specifies its type. If audit records are collected for
`multiple systems, then an additional field is needed for a
`system identifier.
`Since each audit record specifies a subject and object,
`it is conceptually associated with some cell in an “audit
`matrix” whose rows correspond to subjects and columns
`to objects. The audit matrix is analogous to the “access—
`matrix” protection model, which specifies the rights of
`: subjects to access objects; that is, the actions that each
`subject is authorized to perform on each object. Our in-
`trusion—detection model differs from the access-matrix
`model by substituting the concept of “action performed”
`A (as evidenced by an audit record associated with a cell in
`the matrix) for “action authorized” (as specified by an
`access right in the matrix cell). Indeed, since activity is
`observed-without regard for authorization, there is an im—,
`plicit assumption that the access controls in the system
`permitted an action to occur. The task of intrusion detec-
`tion is to "determine whether activity is unusual enough to
`suspect an intrusion. Every statistical measure used for
`this ‘purpose is computed from audit records associated
`with one or more cells in the matrix.
`
`le—
`ng
`)v— ‘
`ho
`
`top:|.4
`:c-
`
`[es
`ass
`
`re—
`an _
`
`ed j
`it— I
`.
`an
`
`sov
`ld 5
`:w .
`or:
`vef
`id
`._r;
`Off
`
`ya
`
`
`
`._
`
`S
`
`0 Activity rules: Actions taken when some condition is
`. satisfied“, which update profiles, detect abnormal behav~
`ior, relate anomalies to suspected intrusions, and produce
`-reports.
`I
`I
`‘
`The model can be regarded "as a rule-based pattern
`matching system. When an audit record is generated, it is
`matched against the profiles. Type information in the
`matching profiles then determines what rules to apply to
`: update the profiles,’ check for abnormal behavior, and re-
`port anomalies detected. The security oflicer assists in es-
`tablishing profile templates for the activities to monitor,
`but the rules and profile structures are largely system—in—
`dependent.
`'
`.
`'
`'
`'
`The basic idea is to monitor the standard operations on
`-a target system: logins, command and program execu-
`tions, file and device accesses, etc., looking only_for de-
`viations in usage. The model does not contain any special
`i ‘features for dealing with ‘complex actions that exploit a
`known or suspected security flaw in the target system; in-
`deed, it has no knowledge of the target system’s security
`mechanisms or its deficiencies. Although a flaw—based de-
`tection mechanism may have some value,
`it would be
`‘considerably more complex and would be unable to cope
`= with intrusions that exploit deficiencies that are not sus-
`vpected or with pers0nnel—related vulnerabilities. By de-
`tecting the intrusion, however, the security oflicer may be
`better able to locate vulnerabilities.
`_
`'
`The remainder of this paper describes the components
`of the model in more detail.
`'
`‘
`t
`
`I
`
`I
`
`,7
`
`I
`III. SUBJECTS AND OBJECTS
`Subjects are the initiators of actions in the target sys-
`tem. A subject is typically a terminal user, but might also
`be a process acting on behalf of users or groups of users,
`, Or might be the system itself. All activity arises through
`. Commands initiated by subjects. Subjects may be grouped
`into different classes (e.g., user groups) for the purpose
`..of controlling access to objectsin the system. User groups
`‘ may overlap.
`~
`,
`,
`Objects are the receptors of actions and typically in-
`000006
`
`_
`*’
`
`000006
`
`

`
`224
`
`IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE—13, NO. 2, FEBRUARY 1987
`
`Most operations on a system involve multiple objects.
`For example, file copying involves the copy program, the
`original file, and the copy. Compiling involves the com-
`piler, a source program file, -an object program file,’ and
`possibly intermediate files and additional source files ref-
`erenced through “include” statements Sending an elec-
`' tronic mail message involves the mail program, possibly V
`multiple destinations in the"‘To” and “cc” fields, and
`"possibly “include” files.
`'
`‘Our model decomposes all activity "into single-object.
`actions so that each audit record references only one ob-
`ject. File copying, for example, is decomposed into an
`execute operation on the copy command, a read operation
`on the source file-, and a write operation on the destination
`file". The following illustrates the audit records generated
`in response to a command
`
`COPY GAME.EXE TO <Library>GAME.EXE
`
`issued by usersmith to copy an executable GAME file
`into the <Library> directory; the copy is aborted be-
`cause Smith does not have write permission to <Li-
`brary>:
`'
`
`(Smith, execute, <Library>COPY.EXE,
`I
`CPU=OOOO2, 11058521678)
`(Smith, read, <Smith>GAME.EXE, O,
`RECORDS=O, 11058521679)
`(Smith, write, <Library>GAME.EXE, write-viol,
`. RECOHD—S=O, 11058521680)
`
`0,
`
`Decomposing complex actions has three advantages.
`First, since objects are the protectable entities of a sys-
`tem,-thedecomposition is consistent with the protection
`.mechanisms of systems. -Thus, IDES can potentially dis-
`cover both attempted subversions of the access controls
`(by noting an abnormality in the number of exception ‘con-
`_ ‘ditions returned) and successful subversions: (by noting an
`abnormality ._,i.n"the set of objects accessible to the subject).
`Se‘cond.,_-single-object audit records greatly simplify the‘
`model ‘and its application.~‘Third,- the audit records'pro—
`duced by existing systems generally contain a single ob-
`ject, "although some systems provide away of linking to-
`-getherzthe audit records associated with a “job step”
`(e.g., copy or compile) so that all files accessed during
`execution of a program can be identified.
`‘
`'
`The target system is responsible forauditing and for
`transmitting audit records to the intrusion-detection sys-
`tem for‘-analysis (it may-also keep an independent audit '
`trail). The time at which audit records are generated de-
`termines what type of data is available. If the audit record
`for some action is generated at the time an action is re-
`quested, it isapossible to-"measure both successful and un-
`successful.attempts'to perform the activity, evenif the
`_, action should abort (e.g., because of.a protection viola-
`tion) or cause a system crash.f If it is generated when the
`action completes, it is possible to measure the resources
`consumed by the action and exception conditions that may
`cause the action to terminate abnormally ‘(e. g. , because of
`resource overflow). Thus, auditing an ‘activity after it
`jcomplefiééiabhhe advantage of providing more informa-
`
`V. PRoF1LEs
`An activity profile characterizes the behavior of a given:
`subject (or set of subjects) with respect to a given object
`(or set thereof), thereby serving as a-signature or descrip-
`
`,_
`
`
`
`2
`
`1
`
`‘f
`
`tion, but the disadvantage of not allowing immediate de-
`tection-of abnormalities, especially those related to break-
`ins and system crashes. Thus, activities such as login, ex‘-
`ecution of high risk commands (e.g., to acquire special
`“superuser” privileges), or access to sensitive data should
`be audited when they are attempted so that penetrations
`can be detected immediately; if resource—usage .data are
`also desired, additional auditing can beperformed on
`. completion as well. For example, access to a database
`containing highly sensitive data_ may be monitored when
`the access is attempted and then again when it completes
`to report the number of records retrieved or updated‘. Most
`existing audit systems monitor session activity at both ini-
`tiation (login), when the time and" location of login are
`recorded, and termination (logout), when the resources
`consumed during the session are recorded. They do not,
`however, monitor both the start and finish of command
`and program. execution or file accesses. IBM’s System a ~ v
`Management Facilities (SMF) [2], for example, audit only ;
`the completion of these activities.
`.
`'
`"5
`Although the auditing mechanisms of existing systems
`approximate the model,
`they are typically deficient
`in ii
`terms of the activities monitored and record structures
`generated. For example, Berkeley 4.2 UNIX [3] monitors
`command usage but not file accesses or file protection vi— ,
`olations. Some systems do not record all login failures.
`Programs, including system programs, invoked below the 1
`command level are not explicitly monitored (their activity
`is included in that for the‘ main program). Thelevel at S
`which auditing should take place,- however,
`is unclear,
`since too much auditing could severely degrade perfor-
`mance on the target system or_ overload the intrusion—de-
`tection system.‘
`'
`'
`-
`Deficiencies in the record structures are also present.
`‘Most. SMF audit records, for example, do not contain a —_
`subject field; the subject must be reconstructed by linking in’
`together the records associated with a given job. Protec— _
`tion violations are sometimes provided through separate
`record formats rather than as an exception conditionin a 1
`common record; SVM password failures"-at login, for ex-
`ample, are handled this way (there areseparate. records
`for successful logins and password failures)"
`, Another problem with existing audit records is that they
`contain little or no descriptive inforrnation to identify the
`values contained therein. Every r‘ecord‘typ’e has its own
`structure, and the exact format of each record type must
`be known to interpret the values. A uniformrecord format
`with self-identifying data would be preferable so that the
`intrusion-detection software can be system—independent.
`This" could be achieved either by modifying the software
`that produces the audit records in the target system, or_by
`writing a filter that translates the records into a standard
`format.
`-
`‘
`
`000007
`
`

`
`
`
`’ DENNING: INTRUSION-DETECTION MODEL
`
`a statistical metric and model. A metric is a’ random’ var-
`iable x representing a quantitative measure accumulated
`over a period. The period may be a fixed interval of time
`(minute, hour, day, week, etc.), or the time between two
`audit-relat_ed events (i.e., between login and logout, pro-
`gram initiation and program tennination, file openand file
`close, etc.), Observations (sample points ) x,- ofvx obtained
`from the audit records are used together with a statistical
`‘model to determine whether a new observation is abnor-
`mal. The statistical model makes no assumptions about
`the underlying _distribution of x; all knowledge about x is
`obtained from observations. Before describing the struc-
`ture, generation, and application of profiles, we shall first
`discuss statistical metrics and models._
`A. Metrics
`
`We define three types of metrics‘:
`0 Event Counter: x is the ‘number of audit records sat-
`isfying some property occurring during a period (each au-
`dit record corresponds to an event). Examples are number
`of logins during an hour, number of times some command
`is executed during a login session, and number of pass-
`word failures during a minute.
`A
`g
`M 0 Interval Timer: x is the length of time between two
`related events;
`i.e. ,
`the difference between the time-'
`stamps in the respective audit records. An exarnpleis the
`length of time between successive logins into an account.
`0 Resource Measure: x is the quantity of resources
`consumed by some action during a period as specified in
`the Resource-Usage field of'theia_udit records. Examples
`are the total number of pages printedby a user per day
`and total -amount of CPU -time consumed by some pro-
`gram during a single execution. Note that a resource mea-
`sure in our intrusion-detection model isimplemented as
`an event counter or interval timer on the target system.
`For example, the number of pages printed during a login
`session is implemented’ on the target system as an event
`counter that counts the number of print events between
`login and logout; CPU time consumed by a program as
`an interval timer that runs between program initiation and
`termination. Thus, whereas event counters and interval-
`timers measures events .at the audit-record level, resource
`measures acquire data from events on the target system
`that occur at a level below theaudit records. The Re-
`source-Usage field of audit records thereby provides a
`means of data reduction so that fewer eventsineedbe ex-
`plicitly recorded in audit records.
`’
`
`B. Statistical Models
`
`Given a metric for a random variable x and n observa-
`tions xl‘,
`-
`-
`-
`, x,,, the purpose of a statistical model of ‘x
`is to determine Whether a new observation x,, + leis abnor-
`mal with respect to the previous observations. The fol-
`lowing models may be included in IDES:
`A
`1) Operational Model: This model is based on the op-
`erational assumption that abnormality can be decided by
`
`A
`
`oooooe
`
`are
`Ces
`lot’
`
`1'68
`C)1'S.
`
`presumably, the limitsare detennined from prior obser-
`vations of the same type of va1iable.- The operational
`modelis most applicable to metrics where experience has
`shown that