PTO/SB/16 (07-05)
`Approved for use through 7131/2006. OMB 0651-0032
`U.S. Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE
`Under the Paperwork Reduction Act of 1995, no persons are required to respond to a collection of information unless it displays a valid OMB control number.
`PROVISIONAL APPLICATION FOR PATENT COVER SHEET
`This is a request for filing a PROVISIONAL APPLICATION FOR PATENT under 37 CFR 1.53(c).
`---------------------------------------
`Express Mail Label No. EV735323442US
`
`Direct all correspondence to:
`
`0 The address corresponding to Customer Number: . . . . . - - - - - - - - - - - - - - - ,
`
`CORRESPONDENCE ADDRESS
`
`OR
`
`D Finn or
`
`Individual Name
`
`Address
`
`219
`
`CD(s), Number of CDs
`.---=======-----~
`
`L . . . I ______ __ __ _ __J
`
`D Other (specify)
`
`Application Size Fee: Filing Fee of $200 ($100 for small entity). If the specification and drawings exceed 100 sheets of paper, an
`application size fee due, which is $250 ($125 for small entity) for each additional 50 sheets or fraction thereof. See 35 U.S.C. 41 (a)(1 )(G)
`
`0 A check or money order is enclosed to cover the filing fee and application size fee (if applicable).
`D Payment by credit card. Form PT0-2038 is attached.
`0 The Director is hereby authorized to charge the filing fee and application size fee (if applicable) or credit any overpayment to Deposit
`08-0219
`
`A duplicative copy of this form is enclosed for fee processing.
`
`Account Number:
`
`The invention was made by an agency of the United States Government or under a contract with an agency of the United States Government.
`f)(l Yes, the name of the U.S. Government agency DARPA _ F
`_
`_
`_
`02
`2
`0209
`~ and the Government contract number are:
`
`D No.
`
`30602
`
`TYPED or PRINTED NAME
`
`George L. Kanabe
`
`Date
`REGISTRATION
`NO.
`(if appropriate)
`
`TELEPHONE
`
`(212) 230-8800
`Docket Number:
`USE ONLY FOR FlUNG A PROVISIONAL APPUCATION FOR PATENT
`[Number 1 of 1 )
`
`Express Mail Label No. EV735323442US Dated: October 25 2005
`
`5350558
`
`October 25, 2005
`
`51,858
`
`19240.533-U$1
`
`Columbia Ex 2028-1
`Symantec v Columbia
`IPR2015-00375
`
`

`
`Attorney Docket No. 19240.533-US 1
`
`Express Mail Label No. EV 735323442 US
`Patent
`
`SYSTEMS AND METHODS FOR DETECTING
`ANOMALOUS PROGRAM EXECUTIONS
`
`[0001]
`
`The present invention relates to computer security. More particularly, the p.resent
`
`invention relates to systems and methods for detecting anomalous program executions and
`
`protecting computers against the same.
`
`[0002]
`
`According to various embodiments, systems and methods are provided that model
`
`application level compp.tations and running programs, and that detect anomalous executions by,
`
`for example, instrumenting, monitoring and analyzing program function calls and/or arguments.
`
`Such an approach may be sufficient for certain purposes in order to detect anomalous program
`
`executions that may be indicative of a malicious attack or program fault, in which case it may not
`
`be necessary to use other approaches such as payload anomaly detection, or operating system
`
`(OS) level system call anomaly detection. Alternatively, for example, application level
`
`computation modeling and payload anomaly detection may be used in combination.
`
`[0003]
`
`The anomaly detection algorithm being used may be, for example, the
`
`Probabilistic Anomaly Detection algorithm (PAD), which is described in the document titled
`
`"One Class Support Vector Machines for Detecting Anomalous Windows Registry Accesses,"
`
`by Katherine Heller et al., which is hereby incorporated by reference herein in its entirety and is
`
`annexed hereto at Appendix A. As described in this document, an exemplar application ofP AD
`
`relates to Registry Anomaly Detection (RAD). RAD is also described in the document titled
`
`"Detecting Malicious Software by Monitoring Anomalous Windows Registry Accesses," by
`
`Frank Apap et al., which is hereby incorporated by reference herein in its entirety and is annexed
`
`hereto at Appendix B.
`
`[0004]
`
`In addition to being applied to Windows Registry anomaly detection, PAD may
`
`be applied to process execution anomaly detection, file system access anomaly detection, and
`
`network packet header anomaly detection. Moreover, as described herein, according to various
`
`embodiments, PAD may be applied to program execution state information. For example, as
`
`explained in greater detail below, PAD may model information on the program stack to detect
`
`anomalous program behavior.
`
`1
`
`!EST- AVAJLABLE COPY
`
`Columbia Ex 2028-2
`Symantec v Columbia
`IPR2015-00375
`
`

`
`Attorney Docket No. 19240.533-USl
`
`Express Mail Label No. EV 735323442 US
`Patent
`
`[0005]
`
`In various embodiments using PAD to model program stack information, such
`
`stack information may be extracted using, for example, Selective Transactional EMulation
`
`(STEM), which permits the selective execution of certain parts, or all, of a program inside an
`
`instruction-level emulator. In this manner, it is possible to determine dynamically (and
`
`transparently to the monitored program) the necessary information such as stack frames,
`
`function-call arguments, etc. For example, one or more of the following may be extracted from
`
`the program stack specific information: function name, the argument buffer name it may
`
`reference, and other features associated with the data sent to or returned from the called function
`
`(e.g., the length in bytes of the data, or the memory location of the data). STEM is described in
`
`the document titled "Building a Reactive Immune System for Software Services," by Stelios
`
`Sidiroglou et al., which is hereby incorporated by reference herein in its entirety and is annexed
`
`hereto at Appendix C.
`
`[0006]
`
`PAD may be applied, for example, by extracting data pushed onto the stack, and
`
`creating a data record provided to the PAD module for processing. According to various
`
`embodiments, in a first phase, PAD models normal program execution stack behavior. In the
`
`detection mode, after a model has been computed, PAD detects any stacked function references
`
`as anomalous with respect to the training data.
`
`[0007]
`
`Once an anomaly is detected using PAD, according to various embodiments,
`
`Selective Transactional Emulation (STEM) and Error Virtualization may be used to reverse
`
`(undo) the effects of processing the malicious input (e.g., changes to program variables or the file
`
`system) in order to allow the program to recover execution in a graceful manner. It will be
`
`understood that, in this manner, the precise location of the failed (or attacked) program at which
`
`an anomaly was found may be identified. It will also be understood that the application of PAD
`
`to function calls enables rapid detection of malicious program executions, such that it is possible
`
`to mitigate against such faults or attacks (e.g., by using patch generation systems, or content
`
`filtering signature generation systems). Moreover, given precise identification of the vulnerable
`
`location, the performance impact may be reduced by using STEM for parts or all of a program's
`
`execution. More information on reversing the effects of processing malicious input is provided
`
`in the document titled "Methods and Systems for Repairing Applications," which is hereby
`
`incorporated by reference herein in its entirety and is annexed hereto at Appendix D.
`
`2
`
`Columbia Ex 2028-3
`Symantec v Columbia
`IPR2015-00375
`
`

`
`Attorney Docket No. 19240.533-USl
`
`Express Mail Label No. EV 735323442 US
`Patent
`
`[0008]
`
`As explained above, anomaly detection involves the use of detection models.
`
`According to various embodiments, systems and methods are now described that may be used in
`
`connection with the automatic and unsupervised learning of anomaly detection models.
`
`According to various embodiments, these systems and methods are designed to detect "mimicry
`
`attacks," which might otherwise thwart OS system call level anomaly detectors by using normal
`
`appearing sequences of system calls. For example, mimicry attacks are less likely to be detected
`
`when the system calls are only modeled as tokens form an alphabet, without any information
`
`about arguments. Therefore, according to various embodiments, the models used are enriched
`
`with information about the arguments (data) such that it may be easier to detect mimicry attacks.
`
`[0009]
`
`According to various embodiments, systems and methods are provided that
`
`employ model sharing, which are designed to benefit from the fact that there are often many
`
`instances of applications operating on a network (collectively referred to as an "application
`
`community''). In particular, individual application instances may be configured to share models
`
`with each other and/or update each others' models such that the learning of anomaly detection
`
`models is relatively quick. For example, instead of running a particular application for days at a
`
`single site, according to various embodiments, thousands of replicated applications are run for a
`
`period of time (e.g., one hour), and the models created based on the distributed data are shared.
`
`While only a portion of each application instance may be monitored in this example, for
`
`example, the entire software body is monitored across the entire community. This process
`
`enables the rapid acquisition of statistics, and relatively fast learning of an application profile by
`
`sharing, for example, aggregate information (rather than the actual raw data used to construct the
`
`model).
`
`[0010]
`
`It will be understood, however, that model sharing as described immediately
`
`above results in one standard model that an attacker could potentially access and use to craft a
`
`mimicry attack. Therefore, according to various embodiments, unique and diversified models
`
`may be created. For example, such unique and diversified models may be created by randomly
`
`choosing particular features from the application execution that is modeled, such that the various
`application instances compute distinct models. In this manner, attacks must avoid detection by
`
`multiple models, rather than a single model. It will be understood that creating unique and
`
`diversified models not only has the advantage of being more resistant to mimicry attacks, but
`
`3
`
`Columbia Ex 2028-4
`Symantec v Columbia
`IPR2015-00375
`
`

`
`Attorney Docket No. 19240.533-USl
`
`Express Mail Label No. EV 735323442 US
`Patent
`
`also may be more efficient. If only a portion of an application is modeled by each member of the
`
`application community, monitoring will generally be simpler (and cheaper) for each member of
`
`the community. In the event one or more members of the application community are attacked,
`
`according to various embodiments, the attack (or fault) will be detected, and patches or a
`
`signature may be provided to those community members who are blind to the crafted attack (or
`
`fault). More information regarding patches is provided in the document titled "Countering
`
`Network Worms Through Automatic Patch Generation," by Stelios Sidiroglou et al., which is
`
`hereby incorporated by reference herein in its entirety and is annexed hereto at Appendix E.
`
`Additional benefits and possible uses associated with patches are described further below.
`
`[0011]
`
`The random (distinct) model building described above, and the associated random
`
`probing, may be controlled by a software registration key provided by the commercial off-the(cid:173)
`
`shelf (COTS) software vendor or some other data providing "randomization." For example, for
`
`each member of the application community, some particular randomly chosen function or
`
`functions and their associated data may be chosen for modeling, while others may simply be
`
`ignored. Moreover, because vendors generate distinct keys and serial numbers when distributing
`
`their software, this feature can be used to create a distinct random subset of functions to be
`
`modeled. Also, according to various embodiments, even community members who model the
`
`same function or functions may exchange models.
`
`[0012]
`
`According to various embodiments, when an application execution is being
`
`analyzed over many copies distributed among a number of application community members as
`
`described above to profile the entire code of the application, it is determined whether there are
`
`any segments of code that are either rarely or never executed, and a MAP is provided of the code
`
`layout identifying "suspect code segments" for deeper analysis and perhaps deeper monitoring.
`
`Those segments identified as rarely or never executed may harbor vulnerabilities not yet
`
`executed or exploited. Such segments of code may have been designed to execute only for very
`
`special purposes such as error handling, or perhaps even for triggering malicious code embedded
`
`in the application. Since they are rarely or never executed, one may presume that such code
`
`segments have had less regression testing, and may have a higher likelihood of harboring faulty
`
`code.
`
`4
`
`Columbia Ex 2028-5
`Symantec v Columbia
`IPR2015-00375
`
`

`
`Attorney Docket No. 19240.533-USl
`
`Express Mail Label No. EV 735323442 US
`Patent
`
`[0013]
`
`It is noted that rarely or never executed code segments may be identified and may
`
`be monitored more thoroughly through, for example, emulation. This deep monitoring may have
`
`no discernible overhead since the code in question is rarely or never executed. But such
`
`monitoring performed in each community member may prevent future disasters by preventing
`
`such code (and its likely vulnerabilities) from being executed in a malicious/faulty manner.
`
`Identifying such code may be performed by a sensor that monitors loaded modules into the
`
`running application (e.g., DLL loads) as well as addresses (PC values) during code execution and
`
`creates a "frequency'' map of ranges of the application code. For example, a set of such
`
`distributed sensors may communicate with each other (or through some site that correlates their
`
`collective information) to create a central, global MAP of the application execution profile. This
`
`profile may then be used to identify suspect code segments, and then subsequently, this
`
`information may be useful to assign different kinds of sensors/monitors to different code
`
`segments. For example, an interrupt service routine (ISR) may be applied to these suspect
`
`sections of code.
`
`[0014]
`
`It is noted that a single application instance may have to be run many times (e.g.,
`
`thousands of times) in order to compute an application profile. However, distributed sensors
`
`whose data is correlated among many (e.g., a thousand) application community members would
`
`compute a substantially accurate code profile in a relatively short amount of time. This time may
`
`be viewed as a "tr-aining period" to create the code map.
`
`[0015]
`
`According to various embodiments, the systems and methods provided herein
`
`may also be configured to automatically update models as time progresses. For example,
`
`although a single site may learn a particular model over some period of time, application
`
`behavior may change over time. In this case, the previously learned model may no longer
`
`accurately reflect the application characteristics, resulting in, for example, the generation of an
`
`excessive amount of false alarms (and thus an increase in the false positive rate over time). A
`
`possible solution to this "concept drift" issue entails at least two possible approaches, both
`
`intended to update models over time. A first approach to solving (or at least reducing the effects
`
`of) the "concept drift" issue involves the use of"incrementallearning algorithms," which are
`
`algorithms that piecemeal update their models with new data, and that may also "expire" parts of
`
`5
`
`Columbia Ex 2028-6
`Symantec v Columbia
`IPR2015-00375
`
`

`
`Attorney Docket No. 19240.533-US 1
`
`Express Mail Label No. EV 735323442 US
`Patent
`
`the computed model created by older data. This piecemeal incremental approach is intended to
`
`result in continuous updating using relatively small amounts of data seen by the learning system.
`
`[0016]
`
`A second approach to solving (or at least reducing the effect of) the "concept
`
`drift" issue involves combining multiple models. For example, presuming that an older model
`
`has been computed from older data during some "training epoch," a new model may be
`
`computed concurrently with a new epoch in which the old model is used to detect anomalous
`
`behavior. Once a new model is computed, the old model may be retired or expunged, and
`
`replaced by the new model. Alternatively, for example, multiple models such as described above
`
`may be combined. In this case, according to various embodiments, rather than expunging the old
`
`model, a newly created model is algorithmically combined with the older model using any of a
`
`variety of suitable means. In the case of statistical models that are based upon frequency counts
`
`of individual data points, for example, an update may consist of an additive update of the
`
`frequency count table. For example, PAD may model data by computing the number of
`
`occurrences of a particular data item, "X." Two independently learned PAD models would thus
`
`have two different counts for the same value, and a new frequency table can be readily computed
`
`by summing the two counts, essentially merging two tables and updating common values with
`
`the sum of their respective counts.
`
`[0017]
`
`According to various embodiments, the concept of model updating that is readily
`
`achieved in the case of computed PAD models may be used in connection with model sharing.
`
`For example, rather than computing two models by the same device for a distinct application,
`
`two distinct models may be computed by two distinct instances of an application by two distinct
`
`devices, as described above. The sharing of models may thus be implemented by the model
`
`update process described herein. Hence, a device may continuously learn and update its models
`
`either by computing its own new model, or by downloading a model from another application
`
`community member (e.g., using the same means involved in the combining of models).
`
`[0018]
`
`In the manners described above, an application community may be configured to
`
`continuously refresh and update all community members, thereby making mimicry attacks far
`
`more difficult to achieve.
`
`6
`
`Columbia Ex 2028-7
`Symantec v Columbia
`IPR2015-00375
`
`

`
`Attorney Docket No. 19240.533-US 1
`
`Express Mail Label No. EV 735323442 US
`Patent
`
`[0019]
`
`As mentioned above, it is possible to mitigate against faults or attacks by using
`
`patch generation systems. In accordance with various embodiments, derivative capabilities
`
`associated with patches are now explained. More particularly, when patches are generated,
`
`validated, and deployed in accordance with the present invention, the patches and/or the set of all
`
`such patches may serve the following derivative purposes.
`
`[0020]
`
`First, according to various embodiments, each patch may be used as a "pattern"
`
`to be used in searching other code for other unknown vulnerabilities. It will be understood that
`
`an error (or design flaw) in programming that is made by a programmer and that creates a
`
`vulnerability is likely to show up elsewhere in the code. Therefore, once a vulnerability is
`
`detected, the system may use the detected vulnerability (and patch) to learn about other (e.g.,
`
`similar) vulnerabilities, which may be patched in advance of those vulnerabilities being
`
`exploited. In this manner, over time, a system may automatically reduce (or eliminate)
`
`vulnerabilities.
`
`[0021]
`
`Second, according to various embodiments, previously generated patches may
`
`serve as exemplars for generating new patches. For example, over time, a taxonomy of patches
`
`may be assembled that are related along various syntactic and semantic dimensions. In this case,
`
`the generation of new patches may be aided by prior examples of patch generation.
`
`[0022]
`
`Additionally, according to various embodiments, generated patches may
`
`themselves have direct economic value. For example, once generated, patches may be "sold"
`
`back to the vendors of the software that has been patched.
`
`[0023]
`
`As mentioned above, in order to alleviate monitoring costs, instead of running a
`
`particular application for days at a single site, many (e.g., thousands) replicated versions of the
`
`application may be run for a shorter period oftime (e.g., an hour) to obtain the necessary models.
`
`In this case, only a portion of each replicated version of the application is monitored, although
`
`the entire software body is monitored using the community of monitored software applications.
`
`Moreover, according to various embodiments, if a software module has been detected as faulty,
`
`and a patch has been generated to repair it, the software module itself may no longer need to be
`
`monitored. In this case, over time, patch generated systems may have fewer audit/monitoring
`
`points, and may thus improve in execution speed and performance. Therefore, according to
`
`7
`
`Columbia Ex 2028-8
`Symantec v Columbia
`IPR2015-00375
`
`

`
`Attorney Docket No. 19240.533-USl
`
`Express Mail Label No. EV 735323442 US
`Patent
`
`various embodiments, software systems may be improved, where vulnerabilities are removed,
`
`and the need for monitoring is reduced (thereby reducing the costs and overheads involved with
`
`detecting faults).
`
`[0024]
`
`It is noted that, although described immediately above with regard to an
`
`application community, the notion of automatically identifying faults of an application,
`
`improving the application over time by repairing the faults, and eliminating monitoring costs as
`
`repairs are deployed may also be applied to a single, standalone instance of an application
`
`(without requiring placements as part of a set of monitored application instances).
`
`[0025]
`
`As referred to above and described in the document at Appendix C, the use of
`
`Selective Transactional Emulation (STEM) and Error Virtualization is beneficial as a general
`
`mechanism for reacting to detected failures/attacks in software. According to various
`
`embodiments, the present invention provides improvements relating to the use of STEM and
`
`Error Virtualization, including faster detection of some types of attacks, and better reaction
`
`mechanisms to some types of attacks/failures that can be used instead of or in conjunction with
`
`the techniques mentioned above and in the document at Appendix C.
`
`[0026]
`
`A learning technique is applied over multiple executions of a piece of code (e.g., a
`
`function or collection of functions) that may previously have been associated with a failure, or
`
`that is being proactively monitored. By retaining knowledge on program behavior across
`
`multiple executions, certain invariants (or probable invariants) may be learned, whose violation
`
`in future executions indicates an attack or imminent software fault.
`
`[0027]
`
`In the case of control hijacking attacks, certain control data that resides in
`
`memory is overwritten through some mechanism by an attacker. That control data is then used
`
`by the program for an internal operation, allowing the attacker to subvert the program. The
`
`various forms of buffer overflow attacks (stack and heap smashing, jump into libc, etc.) all
`
`operate in this fashion. Using StackGuard or one or more similar mechanisms, such attacks are
`
`detected when the corrupted control data is about to be used by the program (i.e., after the attack
`
`has succeeded). This is because these schemes do not retain knowledge about program behavior
`as the program is executing when not under attack. In the case of control-data corruption, it is
`
`desirable in various embodiments to be able to detect whether such control data (e.g., memory
`
`8
`
`Columbia Ex 2028-9
`Symantec v Columbia
`IPR2015-00375
`
`

`
`Attorney Docket No. 19240.533-USl
`
`Express Mail Label No. EV 735323442 US
`Patent
`
`locations or registers that hold such data) is about to be overwritten with "tainted" data, or data
`
`provided by the network (which is potentially malicious).
`
`[0028]
`
`In accordance with various embodiments, an alternative to using StackGuard as
`
`mentioned above is using TaintCheck. It is noted that TaintCheck keeps track of how data
`
`modifications propagate throughout program execution by maintaining a memory bit for every
`
`byte or word in memory. This bit is set for a memory location when a machine instruction uses
`
`as input data that was provided as input to the program (e.g., was received over the network, and
`
`is thus possibly malicious) and produces output that is stored in this memory location. If a
`
`control instruction (such as a JUMP or CALL) uses as an argument a value in a memory location
`
`in which the bit is set (i.e., the memory location is "tainted"), the program or the supervisory
`
`code that monitors program behavior recognizes an anomaly and raises an exception.
`
`[0029]
`
`Detecting corruption before it happens, rather than later (when the corrupted data
`
`is about to be used by a control instruction), makes it possible to stop an operation and to discard
`
`its results/output, without other collateral damage. Furthermore, in addition to simply retaining
`
`knowledge of what is control and what is non-control data, according to various embodiments,
`
`knowledge of which instructions in the monitored piece of code typically modify specific
`
`memory locations is also retained. Therefore, it is possible to detect attacks that compromise
`
`data that are used by the program computation itself, and not just for the program control flow
`
`management.
`
`[0030]
`
`According to various embodiments, the inputs to the instruction(s) that can fail (or
`
`that can be exploited in an attack) and the outputs (results) of such instructions are correlated
`
`with the inputs to the program at large. Inputs to an instruction are registers or locations in
`
`memory that contain values that may have been derived (in full or partially) by the input to the
`
`program. By computing a probability distribution model on the program input, alternate inputs
`
`may be chosen to give to the instruction or the function ("input rewriting" or "input
`
`modification") when an imminent failure is detected, allowing the program to "sidestep" the
`
`failure. However, because doing so may still cause the program to fail, according to various
`
`embodiments, micro-speculation (e.g., as implemented by STEM) is optionally used to verify the
`
`effect of taking this course of action, and to use the same recovery technique (with different
`
`9
`
`Columbia Ex 2028-10
`Symantec v Columbia
`IPR2015-00375
`
`

`
`Attorney Docket No. 19240.533-USl
`
`Express Mail Label No. EV 735323442 US
`Patent
`
`input values) or another recovery technique (e.g., error virtualization). Alternatively, for
`
`example, the output of the instruction may be caused to be a value/result that is typically seen
`
`when executing the program ("output overloading").
`
`[0031]
`
`In both cases (input modification or output overloading), the values to use may be
`
`selected based on several different criteria, including but not limited to one or more of the
`
`following: the similarity of the program input that caused to failure with other inputs that have
`
`not caused a failure; the most frequently seen input or output value for that instruction, based on
`
`contextual information (e.g., when particular sequence of functions are in the program call
`
`stack); and most frequently seen input or output value for that instruction across all executions of
`
`the instruction (in all contexts seen). For example, if a particular DIVIDE instruction is detected
`
`in a function that uses a denominator value of zero, which would cause a process exception, and
`
`subsequently program failure, the DIVIDE instruction may be executed with a different
`
`denominator (e.g., based on how similar the program input is to other program inputs seen in the
`
`past, and the denominator values that these executions used). Alternatively, the DIVIDE
`
`instruction may be treated as though it had gave a particular division result. The program may
`
`then be allowed to continue executing, while it behavior is being monitored. Should a failure
`
`subsequently occur while still under monitoring, a different input or output value for the
`
`instruction may be used, for example, or a different repair technique may be used. According to
`
`various embodiments, if none of the above strategies is successful, the user or administrator may
`
`be notified, program execution may be terminated, a rollback to a known good state (ignoring the
`
`current program execution) may take place, and/or some other corrective action may be taken.
`
`[0032]
`
`According to various embodiments, the techniques used to learn typical data can
`
`be implemented as designer choice. For example, if it is assumed that the data modeled is 32-bit
`
`words, a probability distribution of this range of values can be estimated by sampling from
`
`multiple executions of the program. Alternatively, various cluster based analyses may partition
`
`the space of typical data into clusters that represent groups of similar/related data by some
`
`criteria. Vector Quantization techniques may also be implemented to learn a cookbook
`
`representing common and similar data based on some "similarity'' measure or criteria.
`
`10
`
`Columbia Ex 2028-11
`Symantec v Columbia
`IPR2015-00375
`
`

`
`Attorney Docket No. 19240.533-US 1
`
`Express Mail Label No. EV 735323442 US
`Patent
`
`[0033]
`
`Various approaches for anomaly detection that may be incorporated into the
`
`embodiments of the invention described above are explained in the document titled "Apparatus,
`
`Method, and Medium for Identifying Files Using N-Gram Distribution of Data," which is herein
`
`incorporated by reference in its entirety and annexed hereto at Appendix F, and in the document
`
`titled "Anomalous Payload-Based Network Intrusion Detection," by Ke Wang et al., which is
`
`herein incorporated by reference in its entirety and annexed hereto at Appendix G.
`
`[0034]
`
`Moreover, various approaches for protecting computers (e.g., through the use of
`
`checkpointing) and for sharing information among collaborating computers (or computer
`
`systems) that may be incorporated into the embodiments of the invention described above are
`
`explained in the document titled "Systems and Methods for Correlating and Distributing
`
`Intrusion Alert Information Among Collaborating Computer Systems," which is herein
`
`incorporated by reference in its entirety and annexed hereto at Appendix H.
`
`[0035]
`
`The many features and advantages of the embodiments of the present invention
`
`are apparent from the detail description provided above, and thus, it is intended to cover all such
`
`features and advantages of the invention that fall within the true spirit and scope of the invention.
`
`All suitable modifications and equivalents may be resorted to, falling within the scope of the
`
`invention.
`
`USIDOCS 5349331vl
`
`11
`
`Columbia Ex 2028-12
`Symantec v Columbia
`IPR2015-00375
`
`

`
`APPENDIX A
`
`Columbia Ex 2028-13
`Symantec v Columbia
`IPR2015-00375
`
`

`
`One Class Support Vector Machines for Detecting Anomalous Windows Registry
`Accesses
`
`Katherine A. Heller
`
`Krysta M. Svore
`Angelos D. Keromytis
`Dept. of Computer Science
`Columbia University
`1214 Amsterdam Avenue
`New York, NY 10025
`{heller,kmsvore,angelos,sal} @cs.columbia.edu
`
`Salvatore J. Stolfo
`
`Abstract
`
`We present a new Host-based Intrusion Detection Sys(cid:173)
`tem (IDS) that monitors accesses to the Microsoft Windows
`Registry using Registry Anomaly Detection ( RAD ). Our sys(cid:173)
`tem uses a one class Support Vector Machine (OCSVM) to
`detect anomalous registry behavior by training on a dataset
`of normal registry accesses. It then uses this model to de(cid:173)
`tect outliers in new (unclassified) data generated from the
`same system. Given the success of OCSVMs in other ap(cid:173)
`plications, we apply them to the Windows Registry anomaly
`detection problem. We compare our system to the RAD sys(cid:173)
`tem using the Probabilistic Anomaly Detection (PAD) algo(cid:173)
`rithm on the same dataset. Surprisingly, we find that PAD
`outperforms our OCSVM system due to properties of the hi(cid:173)
`erarchical prior incorporated in the PAD algorithm. In the
`future, these properties may be used to develop an improved
`kernel and increase the performance of the OCSVM system.
`
`1. Introduction
`
`One of the most popular and most often attacked oper(cid:173)
`ating systems is Microsoft Windows. Malicious softwa