(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2003/0023774 A1
`Gladstone et al.
`(43) Pub. Date:
`Jan. 30, 2003
`
`US 2003OO23774A1
`
`(54) STATEFUL REFERENCE MONITOR
`
`(76) Inventors: Philip J. S. Gladstone, Framingham,
`MA (US); Jeffrey A. Kraemer,
`Wellesley, MA (US)
`
`Correspondence Address:
`WOLF GREENFIELD & SACKS, PC
`FEDERAL RESERVE PLAZA
`600 ATLANTIC AVENUE
`BOSTON, MA 02210-2211 (US)
`(21) Appl. No.:
`10/071,328
`(22) Filed:
`Feb. 8, 2002
`
`Related U.S. Application Data
`(60) Provisional application No. 60/298,590, filed on Jun.
`14, 2001.
`Publication Classification
`(51) Int. Cl. ................................................... G06F 9/00
`(52) U.S. Cl. .............................................................. 709/328
`(57)
`ABSTRACT
`
`A Stateful Reference Monitor can be loaded into an existing
`commercial operating System, and then can regulate acceSS
`to many different types of resources. The reference monitor
`maintains an updateable Storage area whose contents can be
`used to affect access decisions, and access decisions can be
`based on arbitrary properties of the request.
`
`---, m-
`
`a---
`
`... -----97 ---
`
`w-
`
`a
`
`Ox VSee Y
`Console
`
`Altca-17on SP4Ce
`
`- - -
`
`---------- -
`
`- -
`
`... --2D----
`
`-
`
`. .
`
`.
`
`.
`
`.
`
`.
`
`... - - - - - - - - - - - - -r-e-r- -
`
`3...- --d3 ----. - - -
`
`-W- W -
`
`W - - -
`
`
`
`Juniper Ex. 1007-p. 1
`Juniper v Finjan
`
`

`

`Patent Application Publication Jan. 30, 2003 Sheet 1 of 3
`
`US 2003/0023774 A1
`
`7
`
`
`
`state Full peregence 1-10
`r1 on Ted (Q
`
`G.
`
`Juniper Ex. 1007-p. 2
`Juniper v Finjan
`
`

`

`Patent Application Publication Jan. 30, 2003 Sheet 2 of 3
`
`US 2003/0023774 A1
`
`- - - - - - - - - - - - - -
`
`----------97 -
`
`
`
`Altca17on spAge
`
`- -
`
`USee
`Console TT
`
`Juniper Ex. 1007-p. 3
`Juniper v Finjan
`
`

`

`Patent Application Publication Jan. 30, 2003 Sheet 3 of 3
`
`US 2003/0023774 A1
`
`
`
`-ie,
`
`Juniper Ex. 1007-p. 4
`Juniper v Finjan
`
`

`

`US 2003/0023774 A1
`
`Jan. 30, 2003
`
`STATEFUL REFERENCE MONITOR
`
`CROSS-REFERENCE TO RELATED
`APPLICATION
`0001. The present application claims domestic priority
`under 35 U.S.C. S119(e) to copending U.S. provisional
`patent application serial No. 60/298,590 filed Jun. 14, 2001.
`
`BACKGROUND OF THE INVENTION
`0002 The present invention related generally to software
`that controls an operating policy of a computer System. For
`example, access to various System resources, Such as files
`and network connections may be So controlled.
`0.003 Modern computer systems are controlled by two
`levels of Software: an operating System and application
`Software. The operating System maintains a separation in the
`memory of the computer between the operating System, said
`to execute in operating System Space, and the applications,
`Said to execute in applications Space.
`0004. Applications are the Software that provides solu
`tions to business problem, Such as processing e-mail mes
`Sages. Applications perform their work by communicating
`requests for access to resources Such as network connections
`or files Stored on a Storage medium to the operating System,
`which then fills these requests.
`0005. It may be desired to control any one or more of a
`wide variety of operating policies. One common Scenario is
`to control acceSS to Various System resources, as mentioned
`above, for purposes of Securing a System against deliberate
`and malicious attack or for purposes of ensuring correct and
`non-interfering operation of various processes. For purposes
`of illustration, access control for Security purposes is dis
`cussed. However, the skilled artist will understand that the
`discussion has wider implications, as explicitly pointed out
`and as implied in the following discussion.
`0006 Referring to the example of security systems,
`access is conventionally controlled by one or more real-time
`processes, while policy is independently established with the
`assistance of one or more non-real-time processes. In the
`context of this description, a real-time process is one whose
`action is Sufficiently immediate as to imperceptibly affect the
`Speed at which transactions with which the real-time proceSS
`is connected are processed. A non-real-time process is one
`that processes transactions at a Speed Substantially slower
`than the instantaneous rate at which transactions naturally
`OCC.
`0007 Real-time access control processes and data struc
`tures include, but are not limited to reference monitors,
`access control lists, permissions flags, access tokens and
`proceSS ID checking.
`0008. A reference monitor is a component of a computer
`System that determines whether an access by one compo
`nent, for example a user process, of another component, for
`example, a file is permitted.
`0009 AS used hereinafter, dynamic state is a collection of
`information, that is collected in real-time, indicative of a
`condition of a machine or proceSS as a result of a particular
`Sequence of events leading to the condition. A StateleSS
`System or component is one, which does not collect Such
`data.
`
`0010 Conventional reference monitors, herein referred
`to as Stateless reference monitors, are found in the kernels of
`various Operating Systems, including, for example,
`MicroSoft(R) WindowsTM 2000 OR UNIX. They are used to
`determine whether a particular access to a file or other
`resource is permitted.
`0011 Conventional operating systems contain embedded
`StateleSS reference monitors to control access to resources.
`User processes are started and identified to users on the basis
`of the user Supplying certain identity tokens. In most cases
`the access decision is made based on the identity of the user
`whose local program or process makes the request and one
`or more Static permissions flags or an acceSS control list
`asSociated with the resource. For examples, See Unix or
`Windows 2000. The contents of static permissions flags and
`acceSS control lists do not include information representing
`the current State of the System, but rather include informa
`tion that produces identical results regardless of the State of
`the System.
`0012 Most conventional reference monitors deals with a
`Single resource type (such as files or network connections).
`Some, such as eTrust Access Control v.5.1 from Computer
`ASSociates, protect multiple resource types.
`0013 Some operating systems give finer control by asso
`ciating individual permissions with each user, and then
`checking those permissions against the Static access control
`list of the resource. This is an improvement, but typically
`there are only a limited number of permission flags. Secu
`rity-Enhanced Linux is an example of Such an operating
`System.
`0014. There are operating systems that are even finer
`grained, and allow individual users to offer a Set of tokens,
`and if any match those found in the acceSS control list, then
`acceSS is granted.
`0015 There are operating environments that can include
`the origin of the requesting program in their acceSS control
`decision. For example, see Dan Wallach and Edward Felton,
`“Understanding Java Stack Inspection”, IEEE Proceedings
`of Security & Privacy, May 1998.
`conventionally
`0016 Non-real-time
`processes are
`employed to collect date and analyze past events in order to
`establish or modify effective policies, for example Security
`policies. Typical, conventional non-real-time processes
`include intrusion detection Systems, for example.
`0017. One type of intrusion detection system is an
`autonomous agent that polls, monitors and/or periodically
`mines log files for data indicative of an intrusion. A draw
`back of Such non-real-time Systems is that intrusions are
`only detected “after the fact.” The intruder leaves an audit
`trail of actions recorded in log files and elsewhere for which
`the only reasonable explanation is an intrusion. However, by
`the time Such a non-real-time intrusion detection System
`identifies an intrusion, the intruder is long gone and damage
`done.
`0018 For examples, see Peter G. Neumann and Phillip A.
`Porras, “Experience with EMERALD to Date”, 1st USENIX
`Workshop on Intrusion Detection and Network Monitoring,
`April 1999; Eugene Spafford et al. “Intrusion detection using
`autonomous agents' Computer Networks 34 (2000); and
`Steven R. Snapp et al., “DIDS (Distributed Intrusion Detec
`
`Juniper Ex. 1007-p. 5
`Juniper v Finjan
`
`

`

`US 2003/0023774 A1
`
`Jan. 30, 2003
`
`tion System)-Motivation, Architecture, and An Early Pro
`totype', Proceedings of the 14th National Computer Secu
`rity Conference, October 1991.
`0019. The analysis performed by intrusion detection sys
`tems. Such as have been described or referred to above is
`useful for developing policies to be enforced by real-time
`components, Such as also described above. For example,
`there are reference monitors who can follow more complex
`rules based on patterns mined by an intrusion detector from
`past behavior, but they cannot update their State on each
`controlled request. For example, See Debra AnderSon et al.,
`“Next-generation Intrusion Detection Expert System
`(NIDES) A Summary”, SRI International, May 1995.
`0020. The rise of network computing, with the attendant
`dangers of remote hackers, renders the access control deci
`Sion more difficult. Most Systems base their access control
`decisions on the identity of the local requesting program
`which is tied to a particular user, as noted above, and not on
`the presumably unknown identity of the remote hacker.
`0021 Moreover, conventional systems constructed of
`obvious combinations of the foregoing do not detect or
`control access based on pattern of behavior that croSS the
`lines between diverse users, processes, acceSS types, etc.
`Conventional Systems constructed of obvious combinations
`of the foregoing do not adjust policies dynamically, in
`real-time, in response to newly experienced threats.
`0022 Conventional systems suffer from a lack of
`dynamic State inherent to Stateless reference monitors, and
`that they are not very resilient in the face of local application
`programming errors through which a remote attacker can
`Subvert a trusted local program. Application programming
`errors, i.e., bugs, will always continue to exist as the
`programmerS are fallible and the testing cannot reasonably
`anticipate all manner of malicious attackS.
`0023. When conventional reference monitors are used,
`once an attacker has managed to Subvert a local application,
`the attacker typically has all the rights and privileges of that
`application. In the case of an e-commerce Server, this may
`include the ability to look at transaction histories and the
`asSociated credit card information.
`0024 Finally, as already discussed above, conventional
`Systems cannot detect and react to attacks in which diverse
`parts of the attack are performed by Seemingly normal
`operations of diverse programs or processes, that only form
`the attack when taken in combination.
`
`SUMMARY OF THE INVENTION
`0.025 The present invention provides an improved sys
`tem, method and Software product for controlling an oper
`ating policy of a computer System, Such as a Security policy.
`According to one aspect of an embodiment of the invention,
`a real-time reference monitor Software produce comprises,
`on a machine-readable medium, a Sequence of instructions
`defining a storage area where real-time State information is
`Stored and from which the State information is restored; a
`plurality of rules defining allowable activity based on a
`pattern of activity; and plural interceptors identifying and
`governing the activity based on an application of the rules to
`the activity. The Software product may include a process,
`which correlates the State information acroSS different ones
`of the plural interceptorS. At least one of the plural inter
`
`ceptors can be a pre-existing element of a conventional
`computer operating System. The proceSS which correlates
`the State information can include a rule which defines
`permissible resource references in View of activity identified
`by the interceptorS resource reference and the State infor
`mation; and a rule interpreter which applies the rule to the
`activity identified and the state information. The rule can be
`modified without restarting the real-time reference monitor.
`The plural reference interceptors can correspond to more
`than one resource type and wherein the Storage area is a
`Single Storage area. The Storage area contents can be pre
`served when the rules are modified. The Software product
`can further include an application program interface that can
`Send messages to application programs on the same System.
`The Software product can also further include an application
`program interface that can Send messages to application
`programs on other Systems. The plural reference interceptors
`can monitor two or more of file access, registry access,
`network access, object access, System call access, keyboard
`access, external inputs and user input. According to another
`aspect of an embodiment of the invention, a computer
`implemented reference monitor includes a monitoring pro
`ceSS, executing on a computer, which detects plural defined
`events and generate event messages, a Storage device, on the
`computer, in which is Stored information related to the event
`messages generated by the monitoring process, and a rule
`interpreting process, executing on the computer, which
`responds to characteristics of an event message the infor
`mation Stored in the Storage device and a Set of rules by
`modifying operation of the computer. The Set of rules can be
`modified in response to the information stored in the storage
`device. The set of rules can be modified and wherein
`information Stored in the Storage device is preserved when
`the set of rules is modified. Finally, an external event
`message generating proceSS can execute on another com
`puter and can communicate event messages to the rule
`interpreting process.
`0026. According to yet another aspect of an embodiment
`of the invention, a method of implementing a processing
`policy on a computer includes detecting first and Second
`events, each having one of a plurality of defined event types;
`generating first and Second event messages, each containing
`information about a corresponding one of the first and
`Second events, Storing the information about the first event;
`and enforcing the policy responsive to the Stored informa
`tion about the first event and the information about the
`Second event. The method may further include applying one
`of a set of rules to the stored information about the first event
`and the information about the Second event to determine the
`nature of enforcing the policy. The method may yet further
`include executing an operating System on the computer;
`changing the Set of rules without restarting the operating
`System and without losing the Stored information. Finally,
`the method may include changing the Set of rules without
`interrupting the detecting, generating, Storing and enforcing.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0027. In the drawings, in which like reference designa
`tions indicate like elements:
`0028 FIG. 1 is a functional block diagram of a software
`System embodying aspect of the invention;
`0029 FIG. 2 is a detailed functional block diagram of the
`Software system of FIG. 1;
`
`Juniper Ex. 1007-p. 6
`Juniper v Finjan
`
`

`

`US 2003/0023774 A1
`
`Jan. 30, 2003
`
`0030 FIG. 3 is a functional block diagram of a hardware
`system on which the software system of FIGS. 1 and 2 can
`execute; and
`0.031
`FIG. 4 is a functional block diagram of the storage
`system component of the system of FIG. 3.
`
`DETAILED DESCRIPTION
`0.032 The invention will be better understood upon read
`ing the following detailed description of various aspects of
`embodiments thereof.
`0.033 Aspects of an embodiment of the invention are now
`illustrated in connection with FIG. 1. The exemplary
`embodiment is in the computer System Security field, but the
`invention can readily be embodied in systems in other fields
`of endeavor, as will be evident to the skilled artisan.
`0034). In computers, one important aspect of System Secu
`rity is monitoring System events 100, e.g. access requests to
`a resource, and controlling the effect of those events, e.g.
`blocking or allowing the requested access to a resource. In
`order to monitor events, interceptors 101 are inserted in the
`control or communication paths 102 traversed by those
`events. For example, if an event monitored is a network
`access request, the interceptor 101 is inserted in the oper
`ating System at a point where the network access request is
`communicated from one portion of the operating System to
`another. The interceptor 101 generates an event message 103
`for each event 100 intercepted. Event messages 103 are
`communicated to a stateful reference monitor 104, which
`returns a policy message 105 to the interceptor 101. The
`policy message 105 may be an action for the interceptor 101
`to take, Such as allowing an acceSS request event 100 to
`continue along the control or communication path 102 to
`have its intended effect, or not allowing the event 100 to pass
`along path 102. External event messages 106, generated by
`other, unspecified event monitors can also be processed by
`the stateful reference monitor 104. The stateful reference
`monitor 104 also communicates with a user console 107 and
`log files 108.
`0035) The stateful reference monitor 104 of FIG. 1 is
`now explained in further detail, in connection with FIG. 2.
`An exemplary reference monitor 104 is designed to run as
`part of the operating System, as a driver. The exemplary
`reference monitor 104 is referred to herein as a stateful
`reference monitor because it retains and relies on changing
`System State information in implementing decision policies,
`as explained below. The stateful reference 104 monitor
`communicates with other parts of the operating System and
`with applications through communication channels. One
`channel 201 carries event messages 103 and policy mes
`sages 105, as discussed above. The other channel 202 carries
`external event messages 106, as well as other messages to
`and from application Space 203, including but not limited to
`messages to and from the user console 107 and logs 108.
`0.036 Communication channel 201 transfers messages
`into and out of the stateful reference monitor 104 through a
`rule application programming interface (API) 203. Commu
`nication channel 202 transferS messages into and out of the
`stateful reference monitor 104 through a user API 204.
`0037. Within the stateful reference monitor 104, mes
`Sages of all kinds, but particularly event messages 103 and
`external event messages 106 are routed and directed by an
`
`event router 205, between the rule API 203, the user API 2.04
`and other components of the stateful reference monitor 104.
`The event router 205 is the communication center of the
`Stateful reference monitor 104, directing and controlling all
`internal communication.
`0038. The primary operational logic of the stateful ref
`erence monitor 104 is contained in the rule interpreter 206,
`which also makes use of the contents of a state database 207
`and of compiled rule byte-code 208. The rule interpreter 206
`can be a Small, Straightforward piece of logic that can be
`made extremely bug-proof by design. The state database 207
`is Simply a repository of dynamic State information, and thus
`also easily bug-proofed. The state database 207 may reside
`at least in part in a persistent memory or Storage location So
`that it Survives an operating System reboot.
`0039. The compiled rule byte-code 208 represents the
`operational policies to be enforced and against which activi
`ties and State in the System are checked. AS Such, much of
`the complexity of the System can reside in the byte-code
`208. Although the byte-code 208 also should yield to design
`techniques that reduce or eliminate bugs, it is worth noting
`that bugs in the byte-code 208 cannot cause the operating
`System to crash, but can merely result in improper policy
`decisions. Thus, a more robust System results from the
`partitioning of the rules into the byte-code 208 and the
`interpretive logic into the rules interpreter 206.
`0040 State information can be, but is not limited to,
`information that a certain event occurred within a certain
`time of the present time. Suppose a prohibited combination
`of events is denoted X-Y-Z. That is, Event X, Event Y and
`Event Z. must occur within a certain timeframe to produce a
`bad result. Then, if the state database 207 holds information
`X-Y, a rule in byte-code 208 will prohibit Z. But, another
`rule in byte-code 208 will cause event X and/or event Y to
`be purged from state database 207 after a suitable time.
`Events X, Y and Z. need not be associated with the same user
`or process, or may be So associated, depending upon the type
`of behavior to be controlled. Finally, the stateful reference
`monitor 104 includes mappable memory 209, to aid with
`communication between the stateful reference monitor 104
`and applications in application Space 203 or accessible
`through a network 210. Mappable memory 209 is simply a
`portion of system memory addressable by both the stateful
`reference monitor 104 and other applications, Such that data
`transfer may be easily accomplished by writing to and
`reading from a predetermined location, without requiring
`Special communication apparatus, mechanisms or protocols.
`0041
`Interceptors 101, like the stateful reference monitor
`104, are also implemented in the exemplary embodiment as
`drivers loaded with, but independent of, the operating Sys
`tem kernel. Interceptors 101 interact with the operating
`System at a very low level, by intercepting various types of
`operating System requests, etc., referred to herein as events,
`for example requests for access to operating System
`resources Such as a file or network connection. When an
`interceptor 101 intercepts an event, it generates an event
`message 103, as discussed above. Each intercepted event is
`treated by the stateful reference monitor 104 as a request for
`an interpretation of the event in light of the rules represented
`by the rules byte-code 208 and the contents of the state
`database 207. The result of the stateful reference monitor
`104 applying the rules contained in the byte-code 208 to the
`
`Juniper Ex. 1007-p. 7
`Juniper v Finjan
`
`

`

`US 2003/0023774 A1
`
`Jan. 30, 2003
`
`event message 103 and the contents of the state database 207
`is a policy message 105, which is sent to the interceptor 101.
`The interceptor 101 then implements the contents of the
`policy message 105, for example blocking or allowing a
`CSOCC CCCSS.
`0.042
`Interceptors 101 can take other forms, as well.
`They may simply be APIs allowing the stateful reference
`monitor 104 to observe Some aspect of operating System
`behavior and to modify that behavior accordingly. For
`example, with Suitable modification, an interceptor 101 can
`detect an operating System performance characteristic and
`tune a related parameter, in response.
`0.043
`Interceptors 101 need be inserted only in paths
`affecting resources important to the purpose for which the
`stateful reference monitor 104 is intended. In a security
`application, Such resources may include but are not limited
`to, one or more of Windows Registry acceSS requests,
`network acceSS request, windowS/System/32 directory
`access requests and Outlook personal address books acceSS
`requests. InterceptorS 101 can also extract inputs from other
`Sources, Such as a virus Scanner log file.
`0044 AS indicated above, access to user-level applica
`tions or to the stateful reference monitor 104 through
`user-level applications is given through the application
`Space 203. A graphical user interface (GUI) running on a
`user console 107 may give the user access to the Stateful
`reference monitor 104, for example to monitor performance,
`to View logs and to adjust operational parameters and
`policies. The GUI accessed through the user console 107
`may be a conventional browser, for example, or may be a
`proprietary Software program designed for the purpose. A
`database or file System holding operational logs, error logs
`and the like 108, is also accessible through application Space
`203. The use of logs and the specific types of logs used will
`be defined by the skilled artisan based upon Specific indi
`vidual requirements. Network connections 210 are also
`accessed by the stateful reference monitor 104 through
`application space 203. These network connections 210 are
`those over which external event messages 106 arrive.
`0.045 Now, the detailed operation of the stateful refer
`ence monitor 104 is described. Operations may be divided
`into two classes, normal operations and boot-time opera
`tions.
`0046. During normal operations, an event is intercepted
`by an interceptor 101, and an event message 103 transmitted
`to the stateful reference monitor 104. Events which are
`normally passed on to other parts of the operating System,
`Such as file access requests and network connection requests
`are temporarily held up by the interceptor 101, so that they
`do not have their ordinary, immediate effect, while the
`stateful reference monitor 104 makes a decision based on the
`processing policy then in effect as to whether to block or
`allow the event to be transmitted.
`0047 Event messages 103 from the interceptors 101 are
`received in the stateful reference monitor 104 by the rule
`API 203. The rule API 203 is a simple interface for receiving
`and transmitting messages to interceptorS 101, which may
`be specially written for compatibility with the stateful ref
`erence monitor 104 or may be a packaged component of the
`operating System or may be provided by any party as an
`add-on component. The rule API 203 simply passes event
`
`messages 103 on to the event router 205. As will be seen
`below, the rule API 203 also passes messages out from the
`event router 205 to the interceptors 101, when required.
`0048. The event router 205 is the communication nerve
`center of the stateful reference monitor 104. Any type of
`message that must be moved from one component to another
`component of the stateful reference monitor 104 is trans
`ferred by the event router 205. Other than moving messages
`as directed, the event router 205 need not perform any other
`processing of messages, although the skilled artisan may
`incorporate other processing in the event router 205 as
`required by a particular application.
`0049. The event router 205 queues messages for the
`receiving components of the stateful reference monitor 104
`according to priority. In the case of event messages 103,
`priority may be based on event type, for example. Thus, a
`network access event that may be time Sensitive may be
`processed ahead of a file access event that has no Such time
`Sensitivity.
`0050 Events are identified in the event messages 103 to
`the application which produced the event, rather than the
`user, as is customary in conventional Systems, which allows
`policies to be set and executed orthogonal to the user
`community. This is in contrast to those conventional Sys
`tems, in which processing policies Such as Security and
`acceSS control policies operate on the basis of the user
`generating an event, and the rights and privileges attributed
`to that user.
`0051 Queued events are picked up in priority order by
`the rule interpreter 206 for processing. First, the rule inter
`preter 206 determines whether the event described by the
`event message is of a type designated as part of the dynamic
`state information to be stored in the state database 207. If so,
`then information about the event is stored in the state
`database 207. The information stored, may include some or
`all of, but not necessarily limited to, time of the event, type
`of event, application generating the event, user owning the
`application and the like.
`0052 Next, the type of the event determines which
`segment of the compiled rules byte-code 208 will be
`addressed by the rule interpreter 206. Within the segment of
`the compiled rules byte-code 208, the rule interpreter 206
`executes a Switch function based on the opcode.
`0053 Within a segment, a sequence of rules is executed
`by following this pseudo-code Sequence:
`
`While (done)
`{ get next instruction
`switch (Opcode)
`{ case 1: Action 1
`case 2: Action 2
`case 3: Action 3
`
`0054) A significant performance improvement may be
`obtained by optimizing the argument of the foregoing
`“switch (Opcode)” statement. Switch statements are most
`efficient when the expected cases are consecutive integers
`beginning with 1. Therefore, in order to manage the values
`
`Juniper Ex. 1007-p. 8
`Juniper v Finjan
`
`

`

`US 2003/0023774 A1
`
`Jan. 30, 2003
`
`of opcodes that must be handled by the Switch function in
`the rule interpreter 206, the opcodes are translated by the
`following pseudo-code before the byte-code is first used:
`
`While (more byte-code instructions)
`{ get next instruction
`switch (opcode)
`{ case realOpcode 1: replace opcode by integer = 1;
`case realOpcode 2: replace opcode by integer = 2;
`
`Boot-time operation is similar to normal operation,
`0.055
`except that different rules may be followed, especially in
`Security applications, in order to specialize policies for what
`could be a particularly Vulnerable process. Moreover, Spe
`cialized boot-time rules can be extremely simple and tightly
`written because the boot-time operating System environment
`is highly controlled.
`0056. In order to provide different sets of rules at different
`times, the compiled rule byte-code 208 is stored in a data
`Structure that permits Selection between an active rule Set
`and inactive rule Sets by use of a Software Switch, as is
`known in the art. Thus, the System is assured to be running
`only one Set of rules at a time, not a mixture of rules.
`Moreover, when rules are loaded, various processes, Such as
`rule checks can be performed. This arrangement is particu
`larly advantageous for having different Sets of rules opera
`tive during boot-time than other times. The rules need not all
`be stored and loaded at boot up, thus Saving Space and time.
`Boot-time rules can be stored in and loaded from the
`Windows-based system. Later, the rules for use when boot
`up is done can be loaded from a network resource or from
`a file. In general, rules byte-code 208 is a downloadable
`program and rules interpreter 206 is a virtual machine. Thus,
`the rules can be changed at any time without Shutting down
`or restarting the operating System. In an alternate arrange
`ment, the compiled rule byte-code 208 can be stored in a
`fixed location that can be overwritten easily without shutting
`down the stateful reference monitor 104 or rebooting the
`operating System.
`0057 AS indicated above, various types of patterns of
`events can be programmed into the rules byte-code 208, for
`detection and action. A simple combination, X-Y-Z, was
`given as an example, earlier. However, the rules can also
`identify as a prohibited pattern, any pattern not seen before.
`This type of rule is useful in an environment where the
`System can first be "profiled, i.e., operated in a State
`collection mode, wherein normal combinations and patterns
`of activity are stored in state database 207. Such a system is
`Subsequently placed into a “lockdown” mode, wherein both
`pre-programmed patterns and unusual patterns are detected
`and acted upon. This type of profiling is preferably done in
`the environment in which the System will be operated, So as
`to capture the true range of behavior. Rules can also be
`tightened or relaxed dynamically through user manipulation
`of the bye-code 208 through a suitable program interface at
`the user console 107.
`0.058. In addition to policy messages 105 and communi
`cation with the user console 107, the stateful reference
`monitor can generate a variety of levels of warning and
`
`alarm, at least Some of which permit the user to Select
`whether to allow a questionable action or not. This feature
`is generally useful, but has particular use in a System, which
`was profiled as, described above. Once in lockdown, there
`may still be unseen, but nominally Safe, behaviors that the
`user can pass judgment on. The Stateful reference monitor
`104 alerts the user as to the condition and can record the
`behavior as permissible or not depending on the rules
`defined in byte-code 208.
`0059 An embodiment of the invention is now described
`in connection with Securing computer Systems against mali
`cious users and Software.
`0060 Security