Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

Techniques which allow definition and enforcement of connectivity-based
action and execution authorization policies. On a computer, an action or
execution attempt is intercepted in real-time. The connectivity state of
the computer, the subject process, the program file of the subject
process, the attempted action and the object of the attempted action are
determined. An authorization policy considering the connectivity state
indicates whether the attempted action is authorized or not. In a
tracking mode, the attempted action and its authorization are logged and
the attempted action is allowed to proceed. In an enforcement mode,
unauthorized attempts are blocked and logged, thereby enforcing the
authorization policy.

Claims:

1. A method of authorizing a file system action on a computer, the method
steps comprising: intercepting a file system action attempt indicating an
action by a process on an object; determining an identifier for the
process; using the identifier to determine a program file representing
instructions being executed by the process; determining a network
connectivity state of the computer, wherein at least one entry in an
authorization policy designates an authorization of a particular action
for the program file based on the network connectivity state and a type
of action associated with the particular action, and wherein a network
connectivity state parameter includes an attribute associated with
whether the computer is connected to a wired network or a wireless
network; determining whether the action is authorized or not based on the
authorization policy, wherein the authorization policy includes the
network connectivity state parameter, a program file parameter, an object
parameter, and an attempted action parameter; allowing the action by the
process to proceed when the action is authorized, as indicated by the
authorization policy; and responding when a determination is made that
the action is not authorized, wherein said responding comprises a first
mode and a second mode, when in the first mode the action is blocked and
an alert is generated, the alert including the type of action and the
network connectivity state at the time the action was attempted, and when
in the second mode the action is allowed to proceed and an alert is
generated.

2. (canceled)

3. A method as recited in claim 1, wherein the determining further
determines one or more attributes of the process or of the program file.

4. A method as recited in claim 1, wherein the action indicates a read
operation on the object.

5. A method as recited in claim 1, wherein the action indicates a write,
append or truncate operation on the object.

6. A method as recited in claim 1, wherein the action indicates a delete,
move or rename operation on the object.

7. A computer-implemented method for authorizing registry actions on a
computer that includes a processor and a non-transitory computer readable
medium, comprising: intercepting a registry action attempt indicating an
action by a process on a registry entry; determining an identifier for
the process; using the identifier to determine a program file
representing instructions being executed by the process; determining a
network connectivity state of a computer, wherein at least one entry in
an authorization policy designates an authorization of a particular
action for the program file based on the network connectivity state and a
type of action associated with the particular action, and wherein a
network connectivity state parameter includes an attribute associated
with whether the computer is connected to a wired network or a wireless
network; determining whether the action is authorized or not based on the
authorization policy, wherein the authorization policy includes the
network connectivity state parameter, a program file parameter, an object
parameter, and an attempted action parameter; allowing the action by the
process to proceed when the action is authorized, as indicated by the
authorization policy; and responding when a determination is made that
the action is not authorized, wherein said responding comprises a first
mode and a second mode, when in the first mode the action is blocked and
an alert is generated, the alert including the type of action and the
network connectivity state at the time the action was attempted, and when
in the second mode the action is allowed to proceed and an alert is
generated.

8. (canceled)

9. A method as recited in claim 7, wherein the determining further
determines one or more attributes of the processor of the program file.

10. A method as recited in claim 7, wherein the action indicates a read,
retrieve, write, create or delete operation on the registry entry.

11. A method for authorizing executions on a computer that includes a
processor and a non-transitory computer readable medium, comprising:
intercepting an execution attempt indicating a process attempting to
execute an executable file; determining an identifier for the process;
using the identifier to determine a program file representing
instructions being executed by the process; determining a network
connectivity state of the computer, wherein at least one entry in an
authorization policy designates an authorization of a particular
execution for the program file based on the network connectivity state
and a type of execution associated with the particular execution, and
wherein a network connectivity state parameter includes an attribute
associated with whether the computer is connected to a wired network or a
wireless network; determining whether the execution is authorized or not
based on the authorization policy, wherein the authorization policy
includes the network connectivity state parameter, a program file
parameter, an object parameter, and an attempted execution parameter;
allowing the execution to proceed when the execution is authorized, as
indicated by the authorization policy; and responding when a
determination is made that the execution is not authorized, wherein said
responding comprises a first mode and a second mode, when in the first
mode the execution is blocked and an alert is generated, the alert
including the type of action and the network connectivity state at the
time the execution was attempted, and when in the second mode the
execution is allowed to proceed and an alert is generated.

12. (canceled)

13. A method as recited in claim 11, wherein the determining further
determines one or more attributes of the process or of the program file.

14. (canceled)

15. (canceled)

16. At least one non-transitory computer readable medium having
instructions stored thereon, the instructions when executed by a
processor cause the processor to: intercept a file system action attempt
indicating an action by a process on an object; determine an identifier
for the process; use the identifier to determine a program file
representing instructions being executed by the process; determine a
network connectivity state of the computer, wherein at least one entry in
an authorization policy designates an authorization of a particular
action for the program file based on the network connectivity state and a
type of action associated with the particular action, and wherein a
network connectivity state parameter includes an attribute associated
with whether the computer is connected to a wired network or a wireless
network; determine whether the action is authorized or not based on the
authorization policy, wherein the authorization policy includes the
network connectivity state parameter, a program file parameter, an object
parameter, and an attempted action parameter; allow the action by the
process to proceed when the action is authorized, as indicated by the
authorization policy; and respond when a determination is made that the
action is not authorized, wherein a response comprises one of a first
mode and a second mode, when in the first mode the action is blocked and
an alert is generated, the alert including the type of action and the
network connectivity state at the time the action was attempted, and when
in the second mode the action is allowed to proceed and an alert is
generated.

17. At least one non-transitory computer readable medium having
instructions stored thereon, the instructions when executed by a
processor cause the processor to: intercept a registry action attempt
indicating an action by a process on a registry entry; determine an
identifier for the process; use the identifier to determine a program
file representing instructions being executed by the process; determine a
network connectivity state of a computer, wherein at least one entry in
an authorization policy designates an authorization of a particular
action for the program file based on the network connectivity state and a
type of action associated with the particular action, and wherein a
network connectivity state parameter includes an attribute associated
with whether the computer is connected to a wired network or a wireless
network; determine whether the action is authorized or not based on the
authorization policy, wherein the authorization policy includes the
network connectivity state parameter, a program file parameter, an object
parameter, and an attempted action parameter; allow the action by the
process to proceed when the action is authorized, as indicated by the
authorization policy; and respond when a determination is made that the
action is not authorized, wherein a response comprises one of a first
mode and a second mode, when in the first mode the action is blocked and
an alert is generated, the alert including the type of action and the
network connectivity state at the time the action was attempted, and when
in the second mode the action is allowed to proceed and an alert is
generated.

18. At least one non-transitory computer readable medium having
instructions stored thereon, the instructions when executed by a
processor cause the processor to: intercept an execution attempt
indicating a process attempting to execute an executable file; determine
an identifier for the process; use the identifier to determine a program
file representing instructions being executed by the process; determine a
network connectivity state of the computer, wherein at least one entry in
an authorization policy designates an authorization of a particular
execution for the program file based on the network connectivity state
and a type of execution associated with the particular execution, and
wherein a network connectivity state parameter includes an attribute
associated with whether the computer is connected to a wired network or a
wireless network; determine whether the execution is authorized or not
based on the authorization policy, wherein the authorization policy
includes the network connectivity state parameter, a program file
parameter, an object parameter, and an attempted execution parameter;
allow the execution to proceed when the execution is authorized, as
indicated by the authorization policy; and respond when a determination
is made that the execution is not authorized, wherein a response
comprises one of a first mode and a second mode, when in the first mode
the execution is blocked and an alert is generated, the alert including
the type of action and the network connectivity state at the time the
execution was attempted, and when in the second mode the execution is
allowed to proceed and an alert is generated.

Description:

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application is related to the following, all of which are
incorporated herein by reference in their entirety:

[0014] Invention relates generally to authorization of actions on computer
systems, and in particular to authorization based on connectivity states.

[0015] 2. Related Art

[0016] Access control is a useful and practical concept in the field of
information technology. The definition, monitoring and enforcement of
access control policies contribute to the predictable and manageable
operation and maintenance of business assets and processes.

[0017] An abstraction central to access control is that of subjects
performing actions on objects. Actions, including those attempted by
human subjects, are ultimately performed by one or more processes running
on the computer. While in traditional access control techniques use
authorization policies that are generally defined for "human" subjects,
and additional techniques that allow program-based authorization are
disclosed in above referenced co-pending U.S. patent application Ser. No.
11/400,085, there is also a need for authorizations that take into
account the connectivity state of a computer.

SUMMARY

[0018] We disclose techniques which allow definition and enforcement of
connectivity-based action and execution authorization policies. On a
computer, an action or execution attempt is intercepted in real-time. The
connectivity state of the computer, the subject process, the program file
of the subject process, the attempted action and the object of the
attempted action are determined. An authorization policy considering the
connectivity state indicates whether the attempted action is authorized
or not. In a tracking mode, the attempted action and its authorization
are logged and the attempted action is allowed to proceed. In an
enforcement mode, unauthorized attempts are blocked and logged, thereby
enforcing the authorization policy.

BRIEF DESCRIPTION OF DRAWINGS

[0019] FIG. 1 is a diagrammatic illustration of an exemplary system for
connectivity-based authorization, in accordance with an embodiment of the
present invention.

[0020] FIG. 2 is a flow diagram showing a method for connectivity-based
action authorization, according to an embodiment of the present
invention.

[0021] FIG. 3 is a flow diagram showing a method for connectivity-based
execution authorization, according to an embodiment of the present
invention.

DETAILED DESCRIPTION

[0022] In the connectivity-based authorization techniques described
herein, a process' attempt to perform an action on an object is
intercepted. The state of connectivity, along with other things such as
the subject program, the object, and the attempted action, are then
determined. By way of example, the interception and subsequent
determinations can be performed by a software agent running on the
computer. Referring to an authorization policy which considers the
connectivity and other determined attributes, a decision is made to
either allow or block the attempted action. In both cases, it may be
desirable to generate a log or alert indicative of the decision.

[0023] FIG. 1 is a diagrammatic illustration of an exemplary system for
connectivity-based authorization, in accordance with an embodiment of the
present invention. Computer 101 comprises a memory component 102 and a
storage component 103, managed by an operating system (OS). Computer 101
is connectable to one or more networks 110 over wired (such as Ethernet
or ATM) or wireless links (such as 802.11).

[0024] During the operation of computer 101, processes are launched to
perform various actions in accordance with the operation of computer 101.
Specifically, when a process 104 (hereinafter also referred to as
"subject process") is launched, it executes within memory component 102.
A program file 105 (hereinafter also referred to as "subject program
file") represents the code or sequence of instructions which subject
process 104 starts executing upon its launch. The subject program file
105 is typically some type of an executable file, such as a binary
executable file, script, batch file, interpreted code, byte code, etc.
Program file 105 is stored on storage component 103 or is otherwise
accessible to computer 101. Note that subject process 104, during its
life, may execute other code or instructions such as dynamic libraries,
scripts, accepted input, or any other container of code, but the program
file 105 refers to the code that subject process 104 starts out executing
upon process launch. Furthermore, as described in more detail below, when
subject process 104 is launched to execute a script, the program file 105
refers to the script and not to any interpreter of the script.

[0025] At some point during its execution, subject process 104 may attempt
to perform an action on an object 106. For example, object 106 may be a
file and the action attempt may comprise an attempt to write to the file.
Other examples of objects 106 and actions are described below.

[0026] Using techniques described herein, the action attempt of subject
process 104 is intercepted and an authorization policy is consulted. The
authorization policy takes into account the state of the connectivity
state of computer 101, and preferably also considers one or more other
parameters such as the subject process 104, the subject program file 105,
the object 106, and the action being attempted by subject process 104.
The authorization policy indicates whether the attempted action is
authorized or not.

[0027] There are two broad modes of operation for the connectivity-based
authorizations of the present invention: a "tracking mode" and an
"enforcement mode". Both modes allow authorized attempts to proceed, but
the modes differ in how they handle unauthorized attempts. In an
enforcement mode, unauthorized attempts are blocked. In a tracking mode,
unauthorized attempts are allowed to proceed, but they are logged.
Tracking mode is useful for examining what effects an authorization
policy would have on a system were the policy to be enforced. Tracking
mode allows experimentation with and fine-tuning of authorization
policies on a live computer 101, as well as real-time feedback based
thereon, without disturbing the operation or behavior of the computer
101. Once an authorization policy is deemed acceptable, it can be
enforced by switching from tracking mode to enforcement mode.

[0028] A typical example of an object 106 is a file, managed by a file
system of computer 101. In that case the action attempt is a file system
action attempt such as a read, write or delete operation on the file, or
it may be an attempt to execute the file. Another example of an object
106 is a registry entry, such as one managed by a Windows® operating
system. In that case the action attempt may be a retrieve, create or
delete a registry entry. Other examples of objects 106 include containers
or resources managed by a service-oriented architecture (SOA), data
structures or other objects stored in memory 102, or any other objects
that are accessible to subject process 104. In general, the actions that
can be attempted by the subject process 104 depend on the object 106 and
how the object is being managed. While the following description is
illustrated mainly with reference to file system action attempts, this is
by way of example and is not intended to limit the scope of the disclosed
techniques. It should be obvious to one of ordinary skill in the art that
the disclosed techniques can be applied to connectivity-based
authorization of any action attempted by a subject process on a computer.
Further example actions for files and registry entries are enumerated
below.

Connectivity-Based Action Authorization

[0029] FIG. 2 is a flow diagram showing a method for connectivity-based
action authorization, according to an embodiment of the present
invention. Step 201 intercepts a file system action attempt. This step
preferably occurs in real-time. Step 202 determines the network
connectivity of computer 101.

[0030] Before consulting a connectivity-based authorization policy, step
203 preferably also determines one or more other parameters relevant to
an authorization of the attempted action, such as the target file (object
106) of the file system action attempt, the subject process 104 and the
subject program file 105, and the action that is being attempted by
subject process 104 on object 106. Step 203 optionally also determines
one or more other attributes of the above parameters, examples of which
are enumerated below.

[0031] Step 204 consults an authorization policy in order to determine 205
whether the attempted action is authorized or not. The authorization
policy takes into account the connectivity determined in step 202, and
preferably also takes into account one or more other parameters or
attributes determined in step 203. Optionally, the authorization policy
may disregard some of the determined information. For example, the
authorization policy may disregard some or all of the file object 106
attributes and consider only the connectivity of computer 101 and the
attempted action. Authorization policies may be stored using any
appropriate data structure, for example in a computer readable medium
comprising a table with a plurality of entries, with an entry associating
a connectivity state with one or more allowed actions and subject
programs and objects on the computer.

[0032] Next, if the action is authorized, step 206 allows the action to
proceed and optional step 207 generates one or more log entries and/or
alerts indicating that the authorized action was allowed to proceed. If
the action is not authorized, step 208 blocks the action from proceeding
and optional step 209 generates one or more log entries and/or alerts
indicating that the unauthorized action was blocked. A log entry or alert
may include information about the connectivity, the subject process 104,
the subject program 105, the action, the object 106, relevant
authorization policy, date and time, and/or any other information
relevant to the authorization decision and available at the time of
logging. Steps 208 and 209 are for an enforcement mode embodiment of the
present invention. In a tracking mode embodiment, as described above,
step 208 is skipped, allowing the unauthorized action to proceed and
recording logs and/or alerts at step 209.

[0033] Example attributes of the subject process 104, action and object
106 are described in the above-referenced co-pending U.S. patent
application Ser. No. 11/400,085. Example attributes of the connectivity
include the following:

[0034] Network to which computer 101 is
connected. A network is broadly defined as any set of nodes (such as
computers, routers, switches, etc.) that can communicate with each other
using some protocol. There may be more than one network to which computer
101 is connected at any given time, and such a set of connected networks
may dynamically change over time as connected networks are disconnected
and new connections are established.

[0035] For a network to which
computer 101 is connected or connectable, attributes such as:

[0036]
whether the network is wired or wireless;

[0037] a network identifier,
such as a Media Access Control (MAC) address of a default gateway, or a
Service Set Identifier (SSID) of a wireless network;

[0043] whether computer 101 is currently connected to a
Microsoft® Active Directory domain;

[0044] whether computer 101 is
currently connected to a single sign-on network, such as one configured
to use Kerberos;

[0045] network connection speed;

[0046] any DHCP options
selected for the network (if DHCP enabled);

[0047] any DHCP options
selected for the computer 101, for example the boot image to use for
booting up the OS of computer 101;

[0048] whether a specific service
(such as an anti-virus update service, an application update service, an
OS update service such as Microsoft Windows® Update, etc.) is
currently available via the network;

[0049] whether a specific network
node (such as an anti-virus update server, an application update server,
an OS update server such as a server for Microsoft Windows® Update,
etc.) is currently available via the network;

[0050] DNS SRV records for
the network (such as including those specified in RFC 2782);

[0051] We now turn to describing the steps of FIG. 2 in more detail. For
the interception step 201, OS provisions can be used to intercept file
system action requests and registry action requests, as well as to
determine whether a file system action request is a an attempt to read a
file, write to a file, delete a file, rename a file, move a file, append
to a file, truncate a file, get or set permissions on a file, or get or
set any other attribute of a file. For example, in a Microsoft
Windows® OS environment, a filter driver can be used to intercept file
system requests and determine their type.

[0052] In other operating systems, such as Linux or other Unix-derived
operating systems, a "shim" module or wrapper mechanism can be used for
that purpose. A wrapper mechanism would redirect action attempts (e.g.
system calls) to a wrapper library that represents an entry point for the
interception code, and which may eventually call into the original
library or code that implements the intended action attempt. One way of
indicating redirection to the wrapper library comprises setting one or
more environment variables indicating library load paths and sequences.

[0053] A shim module redirects system calls to custom interception code
within the kernel, and the interception code decides whether or not to
redirect execution to the kernel code that implements the system call.
For example, in a Unix-derived OS, one or more virtual file system (VFS)
methods may be patched to facilitate redirection to interception code.
These and other techniques for the interception of file system requests
should be obvious to one of ordinary skill in the art, and are also
briefly described in the above referenced co-pending U.S. patent
application Ser. No. 11/346,741. Similarly, OS provisions can be used to
intercept registry action requests and determine whether the request is
an attempt to read or retrieve an entry, delete an entry, write to an
entry, create an entry, or perform any other actions on the entry. We
continue to illustrate the steps with exemplary references to file system
requests.

[0054] Once a file system request is intercepted, the request indicates
the file object 106 as well as the action that the subject process 104 is
attempting to perform on the file object 106. In an embodiment where step
203 further determines the subject process 104 and its subject program
file 105, one technique is to start with a unique identifier for the
process context of the currently executing subject process 104. This
identifier need not necessarily comprise the traditional process
identification number (PID) assigned to processes by many operating
systems, though it may. For example, in a Microsoft Windows® OS, an
EPROCESS block or a process handle can be used to uniquely identify the
subject process 104.

[0055] Once an identifier for the subject process 104 is determined, the
subject program file 105 and optionally one or more other attributes of
the subject process 104 can be determined as well. For some operating
systems, such as a Microsoft Windows® OS, this information may not be
available via a published application programming interface (API). In
such cases, one technique for inferring the subject program file 105
associated with the subject process 104 is to explicitly keep track of
the process-program associations so that they can be referred to when
needed. One way to do this is by implementing a "Process Tracking
Framework" abstraction which, upon receiving an identifier of a subject
process 104 context, indicates the subject program file 105 associated
with the subject process 104. The Process Tracking Framework is described
in the above-referenced co-pending U.S. patent application Ser. No.
11/400,085.

[0056] The authorization rules can be arbitrarily complex and may
represent any function or Boolean predicate which effectively takes as
input a connectivity state, a subject program file 105 of a subject
process 104 (and optionally one or more further attributes of the subject
process 104), a requested action, and an object 106 (or one or more file
object 106 attributes), and outputs an authorization decision. We will
now present some specific use cases enabled by the connectivity-based
authorization techniques and authorization policies described herein.

[0057] One particular example of using connectivity-based action
authorization is to implement file read restrictions on a computer. As
one example of a read restriction policy, a set of authorization rules
can be defined to block file transfer programs resident on computer 101
from accessing a specified set of files R whenever computer 101 has
connectivity to any network other than a specific network N. For example,
R may represent a set of sensitive files related to a business'
operations which should be safeguarded against leaking outside of N.
Consequently, as a result of enforcing the connectivity-based
authorization with such a read restriction policy, whenever a file
transfer program attempts to access a file in R while computer 101 is
connected to any network other than N, the attempt will fail.

[0058] Another example of using connectivity-based action authorization is
to implement file write restrictions on a computer. As one example of a
write restriction policy, a set of authorization rules can be defined to
restrict a specific program file 105 P's ability to write to the
computer's 101 storage 103 depending on the computer's 101 connectivity.
For example, P may be specified as a specific hypertext markup language
(HTML) browser such as Microsoft Internet Explorer®, and an
authorization policy can be defined which restricts P to writing only a
restricted set of files whenever computer 101 is suspected to be
connected to a potentially unsafe network. For example, Microsoft
Internet Explorer® may be allowed to write any type of file to
computer's 101 storage 103 except executable files, scripts, batch files,
and dynamic libraries, unless computer 101 is connected to a specific
firewalled network N (and to no other potentially unsafe network).
Furthermore, Microsoft Internet Explorer® may be also restricted from
modifying existing content on storage 103 unless a connection to N (and
no connection to any other network) can be detected. This means that
whenever a connection to the firewalled network cannot be detected,
Microsoft Internet Explorer® will be blocked from writing such
restricted files to the computer's 101 storage 103 or modifying existing
content, thereby reducing the risk of browser-written malware and
malicious changes to computer 101.

[0059] Other examples of using connectivity-based action authorization
comprise extending the concepts disclosed in above-referenced co-pending
U.S. patent applications with the connectivity-based authorization
techniques disclosed herein. In particular, U.S. patent application Ser.
Nos. 11/346,741 and 11/277,596 describe techniques involving
authorization of updates, changes and executions of objects resident on a
computer system (such as software, configuration files, registry entries,
executables, etc.). The present connectivity-based authorization
techniques extend the authorization of updates, changes and executions
described in said patents to also take into account the connectivity of
the computer 101.

Connectivity-Based Execution Authorization

[0060] The process for execution authorization is similar to that for
action authorization, except that in some operating systems execution
requests may follow a different code path than other file system action
requests, and therefore the interception of execution requests may differ
in implementation from the interception of other file system action
requests.

[0061] FIG. 3 is a flow diagram showing a method for connectivity-based
execution authorization, according to an embodiment of the present
invention. Step 221 intercepts an execution attempt. This step preferably
occurs in real-time. Step 222 determines the network connectivity of
computer 101.

[0062] Before consulting a connectivity-based authorization policy and
analogously to step 203 above, step 223 preferably also determines one or
more other parameters relevant to an authorization of the attempted
execution, such as the target executable file (object 106) of the
execution attempt, the subject process 104 that is attempting to execute
the executable file (object 106), and the subject program file 105 that
represents the code being executed by the subject process 104.
Optionally, step 223 also determines one or more other attributes of the
above parameters, as was enumerated above. For example attributes of the
executable file, refer to the above described object 106 attributes.

[0063] Step 224 consults an authorization policy to determine 225 whether
the attempted execution is authorized or not. The authorization takes
into account the connectivity determined in step 222, and preferably also
takes into account any other parameters and attributes as determined in
step 223. Optionally, the authorization policy may disregard some of the
determined information. For example, the authorization policy may
disregard some or all of the executable file (object 106) attributes and
consider only the connectivity and the subject program file 105. For
example, specific programs may be prohibited from executing unless
computer 101 is connected only to a trusted network. As a concrete
example for a specific business organization, browsers (such as Microsoft
Internet Explorer®) and tools which process proprietary or sensitive
data (such as computer-aided design (CAD) tools) may be prohibited from
running unless computer 101 is connected to the organization's one or
more trusted network. As described above, authorization policies may be
stored using any appropriate data structure, for example in a computer
readable medium comprising a table with a plurality of entries, with an
entry associating a connectivity state with one or more allowed
executions and subject programs and objects on the computer.

[0064] If the execution is authorized, step 226 allows the execution to
proceed and optional step 227 generates one or more log entries and/or
alerts indicating that the authorized execution was allowed to proceed.
If the execution is not authorized, step 228 blocks the action from
proceeding and optional step 229 generates one or more log entries and/or
alerts indicating that an unauthorized execution was blocked. Analogous
to the above description, steps 228 and 229 are for an enforcement mode
embodiment of the present invention. In a tracking mode embodiment, step
228 is skipped, allowing the unauthorized execution to proceed and
recoding logs and/or alerts at step 229.

[0065] We now turn to describing the steps of FIG. 3 in more detail. One
technique for implementing the interception step 221 comprises placing
hooks within the process creation and process termination code paths of
the OS. This is also described in the above-referenced co-pending U.S.
patent application Ser. No. 11/400,085. For step 222, the determination
of connectivity proceeds as described for step 202 above. For step 223,
since an execution request submitted to the OS generally includes an
indication of the executable file (object 106) as an argument (e.g. name
or handle of a binary file, script file, batch file, interpreted program
file, byte code file, etc.), the executable file can be determined by
examining the execution request intercepted in step 221. Any other
parameters and attributes for step 223 can be determined as described
above for step 203. Determination of the subject process (step 223a) can
be done as described above, for example by starting with a unique
identifier for the process context of the currently executing subject
process 104. Determination of subject process 104 attributes (step 223b),
such as the actual program file comprising the code for the subject
process, can be done by using the Process Tracking Framework described in
the above-referenced co-pending U.S. patent application Ser. No.
11/400,085.

[0066] The disclosed connectivity-based authorization techniques
generalize to any other objects and actions which are accessible to
running processes. Examples of such other objects include:
synchronization objects such as semaphores and locks; inter-process
communication (IPC) objects such as shared memory segments; communication
objects such as network sockets; local communication abstractions such as
pipes; file access objects such as symbolic links (on a Unix-flavored OS)
and shortcuts (on a Windows® OS); running processes; etc. Actions
applicable to such objects depend on the specific abstractions,
implementations and semantics of the systems managing the objects, with
examples including: killing, suspending, unsuspending or sending signals
to processes; acquiring or releasing locks; reading from or writing to
shared memory segments; opening, reading from, writing to, or closing
network sockets or pipes; etc. The adaptation of the program-based
authorization steps disclosed herein to such objects and actions (such as
interception of action attempts, determination of object attributes,
etc.) should be obvious to one of ordinary skill in the art.

[0067] Foregoing described embodiments of the invention are provided as
illustrations and descriptions. They are not intended to limit the
invention to precise form described. In particular, it is contemplated
that functional implementation of invention described herein may be
implemented equivalently in hardware, software, firmware, and/or other
available functional components or building blocks, and that networks may
be wired, wireless, or a combination of wired and wireless. Other
variations and embodiments are possible in light of above teachings, and
it is thus intended that the scope of invention not be limited by this
Detailed Description, but rather by Claims following.