WO2005099340A2 - On-line centralized and local authorization of executable files - Google Patents

On-line centralized and local authorization of executable files Download PDF

Info

Publication number
WO2005099340A2
WO2005099340A2 PCT/IB2005/001623 IB2005001623W WO2005099340A2 WO 2005099340 A2 WO2005099340 A2 WO 2005099340A2 IB 2005001623 W IB2005001623 W IB 2005001623W WO 2005099340 A2 WO2005099340 A2 WO 2005099340A2
Authority
WO
WIPO (PCT)
Prior art keywords
execution
executable
rules
recited
rule
Prior art date
Application number
PCT/IB2005/001623
Other languages
French (fr)
Other versions
WO2005099340A3 (en
Inventor
Viacheslav Usov
Original Assignee
Securewave S.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Securewave S.A. filed Critical Securewave S.A.
Priority to EP05744086A priority Critical patent/EP1745342A2/en
Publication of WO2005099340A2 publication Critical patent/WO2005099340A2/en
Publication of WO2005099340A3 publication Critical patent/WO2005099340A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12Protecting executable software
    • G06F21/121Restricting unauthorised execution of programs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2101Auditing as a secondary aspect

Definitions

  • the invention extends the security framework of the contemporary computer operating systems. It relies on the operating system to provide system services to load and/or execute standalone executable modules.
  • Cryptographic digests public and symmetric key cryptography, and digital certificates are used extensively in order to identify executables and secure communication links between the server and the protection module.
  • a number of algorithms SHA-1 for digests and certificates, RSA public key cryptography for certificates and secure communications, AES for secure communications
  • SHA-1 digests and certificates
  • RSA public key cryptography for certificates and secure communications
  • AES for secure communications
  • a technique for intercepting system services on the MS Windows NT family of operating systems is used.
  • the technique involves overwriting ("patching") the system service table.
  • the technique is known to persons skilled in the art.
  • the prior art has employed black-list systems, execution pattern systems, purely white-list systems, white-list systems in combination with black-list systems and execution pattern systems, and systems with cryptographic digests, digital certificates and fixed priority rules. Each of these is discussed in turn.
  • BLACK-LIST SYSTEMS These systems check whether an executable is previously known as harmful. Systems follow the black-list approach when a knowingly harmful executable or an executable that appears to be harmful is blocked or the user is asked for a decision. Such a system typically results in a quick spread of harmful executables that the systems are not aware of. Other systems that follow a black-list approach often fail to detect harmful executables.
  • EXECUTION PATTERN SYSTEMS This type of system monitors the behavior of an executable and if the behavior correlates with that of previously known harmful executables, the executable is considered harmful. These systems may also require updates from their vendors and are unable to block all the harmful executables. They may also generate a significant number of false alarms and may still miss harmful executables while generating a large.number of false positives.
  • WHITE-LIST SYSTEMS These systems are very secure, but are not flexible, because the users may need to run unknown executables which are not harmful. With purely white list systems, this requires a prior authorization by a system administrator. There are a number of products that implement the white-list approach; however, they do not support at least one of the following: local authorization, spread monitoring and flexible rules. With the white list approach, any unknown executable is blocked, or the user, if trusted, is asked for a decision - the latter lets the user disallo V an executable even when it is executed automatically, without the user's prior consent. Systems that follow a strictly white-list approach, while very secure, are inflexible.
  • Some systems have employed cryptographic digests and digital certificates at the time when an executable is introduced to the system - but they are unable to deal with the executables that are introduced in a way they cannot handle, or with the executables introduced when these systems were inactive.
  • Other systems have used cryptographic digests and digital signatures at the time of execution, but not via intercepting system services, which makes it possible to circumvent their protection.
  • Yet still other systems implement a fixed priority rule scheme, or are not scoped, or do not support flexible rule targets.
  • This system adds local authorization to the white-list combined wit black-list approach; local authorization may only be enabled for a selected number of trusted users.
  • the other users work in a very secure environment.
  • the trusted users are always able to disallow an undesirable executable, even if it is started automatically by an insecure or compromised application. Since such locally authorized executables are the only potentially harmful executables, spread of harmful executables can be detected reliably and in a very straightforward way.
  • the automatic security escalation i.e., switching to the white-list-only mode for all the users immediately, limits a detected spread before it may affect the organization significantly; this is not possible with black-list or execution-pattern systems, because there is no naturally defined secure environment.
  • SIGNIFICANT FEATURES OF THE PRESENT INVENTION INCLUDE: 1. The usage of cryptographic digests and digital certificates at the time of execution, by way of intercepting the operating system's load and execute services.
  • Hierarchical and scoped rules with intra-scope priorities and inter-scope priority overrides, with heterogeneous rule objects and highly granular targets.
  • Spread monitoring where spread is defined as a growing number of users authorizing an executable locally.
  • the present invention which combines a white-list 1 approach with local authorization, guarantees that the only harmful executables that may be executed at protected computers are those locally authorized. This, in turn, guarantees that all potentially harmful executables are detected and that the number of false positives is reduced dramatically.
  • An embodiment of the present invention is a method of controlling the execution of a executable file on a computer system.
  • the method includes the steps of (i) intercepting a system service during an attempted execution of the executable file, (ii) examining an ordered set of authorization rales to determine whether it is permissible to execute the executable file, the ordered set of rules describing allowed targets, objects, and schedules, wherein allowed targets includes a list of allowed users or computer systems, allowed objects includes a list of permitted executables, each uniquely identifiable, and whether user authorization is permitted, and allowed, schedules includes a list of conditions under which an execution is allowed, (iii) applying a stored permission to determine whether or not to execute the file, if there is a rule in the set with a matching target, object, and applicable schedule, (iv) determining whether or not there is a local authorization rule, a matching target and applicable schedule, if there is no rule with a matching target, object and applicable schedule, (v) applying a recorded decision to determine whether or not to execute the file, if there is a local authorization rule, a matching target and applicable schedule and there is a record of the current
  • the system includes a database system, an administrative console, a user notification component, a server, and a protection module.
  • the database system is arranged for storing and retrieving execution rules.
  • the administrative console is configured for use by a system administrator to view and modify the execution rules.
  • the user notification component is configured for receiving user authorization requests and sending user replies to the requests.
  • the server is configured for retrieving rules stored in the database system, and is in operative communication with the administrative console to supply the rules to and receive rules from the administrative console.
  • the protection module is in operative communication with the server over a secure channel to obtain stored execution rules and in operative communication with the user notification component to send user authorization requests and to receive user replies.
  • the protection module is configured to intercept services provided by an operating system for executing executable files and to apply the execution rules to an intercepted executable file.
  • One object of the present invention is to control which executables may be loade and executed in a centralized (organization- wide) way, with an option of delegating the decision to a trusted user locally.
  • Another object is to keep track of the execution attempts, successful and/or unsuccessful.
  • Yet another object is to monitor the spread of locally authorized executables throughout an organization. Yet another object is to perform a corrective action automatically whenever a spread is detected.
  • Advantages over the prior systems include the use of a highly flexible set of execution rules, and the use of interception of system services.
  • the use of a highly flexible set of execution rules is not possible with black-list systems, and is implemented only to a limited degree in most white-list systems. This enables system administrators to implement user-productivity and licensing solutions (e.g., to authorize only a necessary -minimum of executables for most users, and authorize certain executables only for the users that require them). Because user and computer groups are supported, system administrators can reuse the already established organizational structure.
  • interception of system services is the most secure way of implementing execution rules, instead of intercepting executables above the level of system services (shell level, usermode abstraction layers).
  • FIG. 1A is a system block diagram of the present invention
  • FIG. IB is a diagram of typical computer system
  • FIG. 2 is a flow chart showing a process in accordance with an embodiment of the present invention.
  • the system 1O includes five standalone software components: a database system 20, a server 22, an administrative console 24, a protection module 26, and a user notification component 28.
  • the software components execute on an exemplary computer system, shown in FIG. IB, that includes a processor 12, a memory 14, a mass storage subsystem 16, 19, a network subsystem 15-, and user-oriented I/O 18, interconnected by a bus 17.
  • the memory 14 and/or mass storage system 16, 19 store the instructions of the software components used for execution by the processor 12.
  • the database system 20 stores all the execution rules in a centralized way.
  • the database system may be supplied by a third, party.
  • the server 22 retrieves the rules stored in the database system 20 and transforms them to a form that is secure and most convenient to the protected client.
  • the server receives execution logs from the protected client and transforms them to form most suitable for the database storage.
  • the server 22 supplies to and accepts execution rules from the administrative console 24 and hosts the spread monitor 30.
  • the server 22 contains a module 32 for communicating with other servers, if an organization employs multiple servers (which is required when a significant number of protected clients are installed).
  • the administrative console 24 is a set of instruments that the system administrators uses to view and modify the execution rules, and view execution logs.
  • the administrative console 24 communicates with the server 22 to perform these tasks.
  • the protection module 26 is a highly privileged module installed at the computers being protected.
  • the module intercepts the services that the operating system provides to load and execute executable files. When a service is intercepted, the module 26 applies the execution rules.
  • This module communicates with the server 22 over a secure (tamper-proof) channel 34 to receive the execution rules and to forward the execution logs. It also interacts with the user notification component 28 to perform local authorization and to notify the user of denied execution attempts. It stores the list 36 of locally authorized executables (because the list is maintained by a privileged component, it can be protected from tampering by normal executables).
  • the user notification component 28 is a normal application that executes in the context of a user.
  • executables To control loading and execution of executables in a centralized way, executables must be identifiable.
  • the executables are identified by means of cryptographic digests (an industry standard cryptographic digest is computed from a full or partial binary image of an executable), their filesystem or network locations, digital certificates (digital certificates are issued by the vendors of the executables; any executable possessing a certificate by a particular vendor are associated with that vendor), etc; this list is not exhaustive.
  • the identification data are organized as a hierarchical set of rules.
  • Each rule describes which computers and/or users it applies to; it may apply to computer and user groups, if supported by the operating system. This is -known as the "rule targets”.
  • Each rule describes the executables it applies to, listing their digests, filesystem locations, digital certificates, etc. This is known as the "rule object”.
  • Special rule objects may specify that local authorization is to be performed, or that all executables be allowed (useful if certain targets are completely trusted).
  • Each rule may specify additional conditions of rule applicability, such as date or time, number of allowed executions, etc. This is known as the "rule schedules”.
  • Each rule describes the organizational unit (e.g., a department, a site, an office, etc) it applies to, if organizational units are supported by the operating system. This is known as the "rule scope”. If organizational units are not supported, the global scope is assumed.
  • the rules are ordered according to their scope and intra-scope priority (for rules with the same scope), and inter-scope overrides.
  • the rules are stored at a well-known location within an organization, where they are manipulated by designated administrators, and the changes are propagated to the participating computers.
  • the steps for controlling the execution of executables are as follows.
  • the relevant system services are intercepted, in step 100, by a privileged protection module, which examines the rules.
  • the rules are examined in order, in step 102, as described above. If a rule with a matching object (different than local authorization), a matching target and an applicable schedule is found, as determined in step 104, the permission associated with the target allows or denies the executable, in step 106. If a local authorization rule with a matching target and an applicable schedule is found, as determined in step 108, then: 1. If the local authorization data do not contain a record on the current executable, as determined in step 1 10, the user is prompted with details on the executable.
  • the user allows or denies the executable, in step 112, and, optionally, instructs the system to store his decision permanently in the local authorization data, in step 112. 2. If the local authorization data do contain a record on the current executable (identifiable by a cryptographic digest), the recorded decision is applied, in step 114.
  • the original system service is invoked, in step 116.
  • Each rule may have special audit targets.
  • a rule allows or denies an execution attempt, and if the rule has a matching audit target, the execution attempt and the system decision are recorded in step 124. If a rule that has allowed or denied an execution attempt, in step 120, does not have a matching audit target, as determined in step 122, the rules are examined again (in the same order), in step 126, for matching audit targets.
  • a rule may contain only audit targets; such a rule is ignored for execution control, but is considered for execution audit.
  • the audit trails are transferred to a centralized audit storage in step 128, which provides means to retrieve the audit data based on a number of search criteria (where the execution attempt took place, on behalf of which user, involving which executable, when, etc).
  • an agent that periodically accesses the centralized audit data storage and checks to determine whether any particular executable has been locally authorized by a number of distinct users that exceeds a threshold established by system administrators. If such a condition arises, an alert is generated.
  • the system may automatically perform a corrective action if configured by system administrators. It may disable local authorization rules so as to prevent further spread of the executable throughout the organization.
  • the system may also carry out a custom action, e.g., running a job that removes the offending executable from the clients.
  • Some operating syste s have built-in capabilities for delivering a centralized and hierarchical set of data to computers within an organization.
  • the database system may only be required to keep the processed execution logs, and the server is required to process the execution logs and host the spread monitor.
  • the administrative console comr ⁇ unicate directly with the system supplied facilities to view and manipulate the execution rules, and communicate with the server to query the execution logs.
  • the protection module receives the execution rules directly from the operating system.
  • any unauthorized executable is prevented from loading and executing.
  • an attempt to load and execute an executable that is not authorized centrally or locally the user is requested to allow or deny the executable.
  • Centrally unauthorized executables that have been locally authorized are allowed to execute without user intervention.
  • the spread monitor generates alerts whenever an executable is authorized locally by a number of users exceeding a threshold set by system administrators; if security escalation is configured for spread alerts, the protected computers are automatically requested to switch into the white-list-only mode.

Abstract

A system and method for controlling the execution of executable files. The executables are identified by either a cryptographic digest or a digital certificate. The crytographic digest is computed from the binary image of the executable. An executable that is attempting to execute is intercepted by a protection module that consults a database of stored rules over a secure channel to determine whether or not the executable can be identified as a permitted executable and whether or not it has permission to execute on a particular computer system under certain specified conditions. If a stored permission is available, it is used to control the execution. Otherwise, the user is consulted for permission.

Description

ON-LINE CENTRALIZED AND LOCAL AUTHORIZATION OF EXECUTABLE FILES
CROSS-REFERENCE TO RELATED APPLICATIONS This application is related to U.S. Provisional Application, Serial No. 60/562,983, filed April 19, 2004, and titled "A Generic Framework for Runtime Interception and Execution Control of Interpreted Languages."
This application is related to and claims priority to U.S. Provisional Application Serial No. 60/562,982, filed April 19, 2004, and titled "ONLINE CENTRALIZED AND LOCAL
AUTHORIZATION OF EXECUTABLE FILES." This application is related to U.S. Provisional Application Serial No. 60/564,579, filed
April 23, 2004, titled "TRANSPARENT ENCRYPTION AND ACCESS CONTROL FOR MASS
STORAGE DEVICES."
FIELD OF THE INVENTION The invention extends the security framework of the contemporary computer operating systems. It relies on the operating system to provide system services to load and/or execute standalone executable modules.
DESCRIPTION OF THE RELATED ART Cryptographic digests, public and symmetric key cryptography, and digital certificates are used extensively in order to identify executables and secure communication links between the server and the protection module. A number of algorithms (SHA-1 for digests and certificates, RSA public key cryptography for certificates and secure communications, AES for secure communications) are known to persons skilled in the art and are employed by the system.
A technique for intercepting system services on the MS Windows NT family of operating systems is used. The technique involves overwriting ("patching") the system service table. The technique is known to persons skilled in the art. l The prior art has employed black-list systems, execution pattern systems, purely white-list systems, white-list systems in combination with black-list systems and execution pattern systems, and systems with cryptographic digests, digital certificates and fixed priority rules. Each of these is discussed in turn. BLACK-LIST SYSTEMS These systems check whether an executable is previously known as harmful. Systems follow the black-list approach when a knowingly harmful executable or an executable that appears to be harmful is blocked or the user is asked for a decision. Such a system typically results in a quick spread of harmful executables that the systems are not aware of. Other systems that follow a black-list approach often fail to detect harmful executables.
Systems that follow a black-list approach also rely on a vendor- supplied update, which leaves an organization essentially unprotected and business process interrupted for a period of time. Even after such an update is delivered, certain harmful self-modified executables may not be disabled. These systems require continual updates by their vendors or system administrators, and are unable to block previously unknown harmful executables until after these executables have caused some harm (possibly in another organization).
EXECUTION PATTERN SYSTEMS This type of system monitors the behavior of an executable and if the behavior correlates with that of previously known harmful executables, the executable is considered harmful. These systems may also require updates from their vendors and are unable to block all the harmful executables. They may also generate a significant number of false alarms and may still miss harmful executables while generating a large.number of false positives.
BLACK-LIST COMBINED WITH EXECUTION PATTERN SYSTEMS These systems still have the same problems as those above. Black-list and execution- pattern systems are greatly inferior to this system in terms of security. In principle, it might be possible to combine some of the competing products with either another one and/or custo software, but this results in a system that is very difficult to implement and support.
WHITE-LIST SYSTEMS These systems are very secure, but are not flexible, because the users may need to run unknown executables which are not harmful. With purely white list systems, this requires a prior authorization by a system administrator. There are a number of products that implement the white-list approach; however, they do not support at least one of the following: local authorization, spread monitoring and flexible rules. With the white list approach, any unknown executable is blocked, or the user, if trusted, is asked for a decision - the latter lets the user disallo V an executable even when it is executed automatically, without the user's prior consent. Systems that follow a strictly white-list approach, while very secure, are inflexible.
WHITE-LIST COMBINED WITH BLACK-LIST SYSTEMS COMBINED WITH EXECUTION PATTERN SYSTEMS In these systems, certain users or computers are exempt from white-list checking, and only black-list in combination with execution pattern checking applies. While this does reduce the risk significantly, the exempt users face the same risks as those in non-white-list systems, even the systems that follow a combined approach still exhibit these deficiencies.
Some systems have employed cryptographic digests and digital certificates at the time when an executable is introduced to the system - but they are unable to deal with the executables that are introduced in a way they cannot handle, or with the executables introduced when these systems were inactive. Other systems have used cryptographic digests and digital signatures at the time of execution, but not via intercepting system services, which makes it possible to circumvent their protection. Yet still other systems implement a fixed priority rule scheme, or are not scoped, or do not support flexible rule targets.
BRIEF SUMMARY OF THE INVENTION This system adds local authorization to the white-list combined wit black-list approach; local authorization may only be enabled for a selected number of trusted users. The other users work in a very secure environment. The trusted users are always able to disallow an undesirable executable, even if it is started automatically by an insecure or compromised application. Since such locally authorized executables are the only potentially harmful executables, spread of harmful executables can be detected reliably and in a very straightforward way. The automatic security escalation, i.e., switching to the white-list-only mode for all the users immediately, limits a detected spread before it may affect the organization significantly; this is not possible with black-list or execution-pattern systems, because there is no naturally defined secure environment.
SIGNIFICANT FEATURES OF THE PRESENT INVENTION INCLUDE: 1. The usage of cryptographic digests and digital certificates at the time of execution, by way of intercepting the operating system's load and execute services.
2. Local authorization of unknown executables.
3. Hierarchical and scoped rules with intra-scope priorities and inter-scope priority overrides, with heterogeneous rule objects and highly granular targets.
4. Spread monitoring, where spread is defined as a growing number of users authorizing an executable locally. The present invention, which combines a white-list 1 approach with local authorization, guarantees that the only harmful executables that may be executed at protected computers are those locally authorized. This, in turn, guarantees that all potentially harmful executables are detected and that the number of false positives is reduced dramatically.
5. Security escalation upon detecting a spread. As soon as a spread is detected, the system automatically transitions into a white-list-only mode, which immediately prevents all unknown executables from being executed. An embodiment of the present invention is a method of controlling the execution of a executable file on a computer system. The method includes the steps of (i) intercepting a system service during an attempted execution of the executable file, (ii) examining an ordered set of authorization rales to determine whether it is permissible to execute the executable file, the ordered set of rules describing allowed targets, objects, and schedules, wherein allowed targets includes a list of allowed users or computer systems, allowed objects includes a list of permitted executables, each uniquely identifiable, and whether user authorization is permitted, and allowed, schedules includes a list of conditions under which an execution is allowed, (iii) applying a stored permission to determine whether or not to execute the file, if there is a rule in the set with a matching target, object, and applicable schedule, (iv) determining whether or not there is a local authorization rule, a matching target and applicable schedule, if there is no rule with a matching target, object and applicable schedule, (v) applying a recorded decision to determine whether or not to execute the file, if there is a local authorization rule, a matching target and applicable schedule and there is a record of the current executable, (vi) obtaining input from the user to determine whether or not to execute the file, and storing the input in the local authorization rule for the executable, if there is no recorded decision, and (vii) invoking the intercepted service, if there is permission to execute the file.
Another embodiment of the present invention is a system for controlling the execution of an executable file. The system includes a database system, an administrative console, a user notification component, a server, and a protection module. The database system is arranged for storing and retrieving execution rules. The administrative console is configured for use by a system administrator to view and modify the execution rules. The user notification component is configured for receiving user authorization requests and sending user replies to the requests. The server is configured for retrieving rules stored in the database system, and is in operative communication with the administrative console to supply the rules to and receive rules from the administrative console. The protection module is in operative communication with the server over a secure channel to obtain stored execution rules and in operative communication with the user notification component to send user authorization requests and to receive user replies. The protection module is configured to intercept services provided by an operating system for executing executable files and to apply the execution rules to an intercepted executable file.
OBJECTS OF THE INVENTION One object of the present invention is to control which executables may be loade and executed in a centralized (organization- wide) way, with an option of delegating the decision to a trusted user locally.
Another object is to keep track of the execution attempts, successful and/or unsuccessful.
Yet another object is to monitor the spread of locally authorized executables throughout an organization. Yet another object is to perform a corrective action automatically whenever a spread is detected.
Advantages over the prior systems include the use of a highly flexible set of execution rules, and the use of interception of system services. The use of a highly flexible set of execution rules is not possible with black-list systems, and is implemented only to a limited degree in most white-list systems. This enables system administrators to implement user-productivity and licensing solutions (e.g., to authorize only a necessary -minimum of executables for most users, and authorize certain executables only for the users that require them). Because user and computer groups are supported, system administrators can reuse the already established organizational structure.
The use of interception of system services is the most secure way of implementing execution rules, instead of intercepting executables above the level of system services (shell level, usermode abstraction layers).
BRIEF DESCRIPTION OF THE DRAWINGS These and other features, aspects and advantages of the present invention will become better understood with regard to the following description, appended claims, and accompanying drawings where: FIG. 1A is a system block diagram of the present invention; FIG. IB is a diagram of typical computer system; and FIG. 2 is a flow chart showing a process in accordance with an embodiment of the present invention.
DETAILED DESCRIPTION OF THE INVENTION Referring to FIG. 1 A, the system 1O includes five standalone software components: a database system 20, a server 22, an administrative console 24, a protection module 26, and a user notification component 28. The software components execute on an exemplary computer system, shown in FIG. IB, that includes a processor 12, a memory 14, a mass storage subsystem 16, 19, a network subsystem 15-, and user-oriented I/O 18, interconnected by a bus 17. The memory 14 and/or mass storage system 16, 19 store the instructions of the software components used for execution by the processor 12.
The database system 20 stores all the execution rules in a centralized way. The database system may be supplied by a third, party.
The server 22 retrieves the rules stored in the database system 20 and transforms them to a form that is secure and most convenient to the protected client. The server receives execution logs from the protected client and transforms them to form most suitable for the database storage. The server 22 supplies to and accepts execution rules from the administrative console 24 and hosts the spread monitor 30. The server 22 contains a module 32 for communicating with other servers, if an organization employs multiple servers (which is required when a significant number of protected clients are installed).
The administrative console 24 is a set of instruments that the system administrators uses to view and modify the execution rules, and view execution logs. The administrative console 24 communicates with the server 22 to perform these tasks.
The protection module 26 is a highly privileged module installed at the computers being protected. The module intercepts the services that the operating system provides to load and execute executable files. When a service is intercepted, the module 26 applies the execution rules. This module communicates with the server 22 over a secure (tamper-proof) channel 34 to receive the execution rules and to forward the execution logs. It also interacts with the user notification component 28 to perform local authorization and to notify the user of denied execution attempts. It stores the list 36 of locally authorized executables (because the list is maintained by a privileged component, it can be protected from tampering by normal executables). The user notification component 28 is a normal application that executes in the context of a user. It receives local authorization requests from the protection module 26 and displays them to the user; when the user replies, it sends the reply to the protection module 26. It also receives and displays user notifications whenever an executable is denied. To control loading and execution of executables in a centralized way, executables must be identifiable. The executables are identified by means of cryptographic digests (an industry standard cryptographic digest is computed from a full or partial binary image of an executable), their filesystem or network locations, digital certificates (digital certificates are issued by the vendors of the executables; any executable possessing a certificate by a particular vendor are associated with that vendor), etc; this list is not exhaustive.
The identification data are organized as a hierarchical set of rules. Each rule describes which computers and/or users it applies to; it may apply to computer and user groups, if supported by the operating system. This is -known as the "rule targets". Each rule describes the executables it applies to, listing their digests, filesystem locations, digital certificates, etc. This is known as the "rule object". Special rule objects may specify that local authorization is to be performed, or that all executables be allowed (useful if certain targets are completely trusted). Each rule may specify additional conditions of rule applicability, such as date or time, number of allowed executions, etc. This is known as the "rule schedules". Each rule describes the organizational unit (e.g., a department, a site, an office, etc) it applies to, if organizational units are supported by the operating system. This is known as the "rule scope". If organizational units are not supported, the global scope is assumed.
The rules are ordered according to their scope and intra-scope priority (for rules with the same scope), and inter-scope overrides.
The rules are stored at a well-known location within an organization, where they are manipulated by designated administrators, and the changes are propagated to the participating computers.
Referring to FIG. 2, the steps for controlling the execution of executables are as follows. When an execution attempt takes place, the relevant system services are intercepted, in step 100, by a privileged protection module, which examines the rules. The rules are examined in order, in step 102, as described above. If a rule with a matching object (different than local authorization), a matching target and an applicable schedule is found, as determined in step 104, the permission associated with the target allows or denies the executable, in step 106. If a local authorization rule with a matching target and an applicable schedule is found, as determined in step 108, then: 1. If the local authorization data do not contain a record on the current executable, as determined in step 1 10, the user is prompted with details on the executable.
The user allows or denies the executable, in step 112, and, optionally, instructs the system to store his decision permanently in the local authorization data, in step 112. 2. If the local authorization data do contain a record on the current executable (identifiable by a cryptographic digest), the recorded decision is applied, in step 114.
If the executable is authorized during the rule search sequence, the original system service is invoked, in step 116.
If the executable is not authorized during the search sequence, or is explicitly denied during the search sequence, the original system service is not invoked, and an appropriate failure status is returned to the user.
LOAD AND EXECUTION AUDIT Each rule may have special audit targets. When a rule allows or denies an execution attempt, and if the rule has a matching audit target, the execution attempt and the system decision are recorded in step 124. If a rule that has allowed or denied an execution attempt, in step 120, does not have a matching audit target, as determined in step 122, the rules are examined again (in the same order), in step 126, for matching audit targets. A rule may contain only audit targets; such a rule is ignored for execution control, but is considered for execution audit. The audit trails are transferred to a centralized audit storage in step 128, which provides means to retrieve the audit data based on a number of search criteria (where the execution attempt took place, on behalf of which user, involving which executable, when, etc).
To monitor the spread of locally authorized executables, an agent is provided that periodically accesses the centralized audit data storage and checks to determine whether any particular executable has been locally authorized by a number of distinct users that exceeds a threshold established by system administrators. If such a condition arises, an alert is generated. When an alert is generated as described above, the system may automatically perform a corrective action if configured by system administrators. It may disable local authorization rules so as to prevent further spread of the executable throughout the organization. The system may also carry out a custom action, e.g., running a job that removes the offending executable from the clients.
Some operating syste s have built-in capabilities for delivering a centralized and hierarchical set of data to computers within an organization. With these operating systems, the database system may only be required to keep the processed execution logs, and the server is required to process the execution logs and host the spread monitor. Likewise, the administrative console comrαunicate directly with the system supplied facilities to view and manipulate the execution rules, and communicate with the server to query the execution logs. The protection module, in turn, receives the execution rules directly from the operating system.
In one implementation, for users or computers in the white-list-only mode (talcing into account the scope and priority of execution rules), any unauthorized executable is prevented from loading and executing. For users or computers in the local authorization mode, an attempt to load and execute an executable that is not authorized centrally or locally, the user is requested to allow or deny the executable. Centrally unauthorized executables that have been locally authorized are allowed to execute without user intervention. The spread monitor generates alerts whenever an executable is authorized locally by a number of users exceeding a threshold set by system administrators; if security escalation is configured for spread alerts, the protected computers are automatically requested to switch into the white-list-only mode.
Although the present invention has been described in considerable detail with reference to certain preferred -versions thereof, other versions are possible. Therefore, the spirit and scope of the appended claims should not be limited to the description of the preferred versions contained herein.

Claims

CLAIMSWhat is claimed is:
1. A method of controlling the execution of a executable file on a computer system, the method comprising: intercepting a system service during an attempted execution of the executable file; examining an ordered set of authorization rules to determine whether it is permissible to execute the executable file, the ordered set of rules describing allowed targets, objects, and schedules, wherein allowed targets includes a list of allowed users or computer systems, allowed objects includes a list of permitted executables, each uniquely identifiable, and whether user authorization is permitted, and allowed schedules includes a list of conditions under which an execution is allowed; applying a stored permission to determine whether or not to execute the file, if there is a rule in the set with a matching target, object, and applicable schedule; determining whether or not there is a local authorization rule, a matching target and applicable schedule, if there is no rule with a matching target, object and applicable schedule; applying a recorded decision to determine whether or not to execute the file, if there is a local authorization rule, a matching target and applicable schedule and there is a record of the current executable; and obtaining input from the user to determine whether or not to execute the file, and storing the input in the local authorization rule for the executable, if there is no recorded decision; and invoking the intercepted service, if there is permission to execute the file.
2. A method of controlling execution as recited in claim 1, wherein each executable in the list of permitted executables is identifiable by means of a cryptographic digest.
3. A method of controlling execution as recited in claim 2, wherein the cryptographic digest is computed from the binary image of the executable.
4. A method of controlling execution as recited in claim 3, where in the binary image is a full binary image.
5. A method of controlling execution as recited in claim 3, where in the binary image is a partial binary image.
6. A method of controlling execution as recited in claim 1, wherein the list of permitted executables is identifiable by means of a digital certificate.
7. A method of controlling execution as recited in claim 1, further comprising denying the execution of the executable file, if there is no permission to execute the file.
8. A method of controlling execution as recited in claim 7, wherein the ordered set of rules includes, for each rule, a special audit target; and further comprising determining whether a rule that denied execution of the executable has a matching special audit target, and if the rule has a matching special audit target, recording the attempted execution and the denial in an execution audit trail.
9. A method of controlling execution as recited in claim 8, further comprising, if the rule does not have a matching special audit target, examining the set of rules again for matching audit targets.
10. A method of controlling execution as recited in claim 1, wherein the ordered set of rules includes, for each rule, a special audit target; and further comprising determining whether a rule that permitted execution of the executable has a matching special audit target, and if the rule has a matching special audit target, recording the attempted execution and the permission to execute in an execution audit trail.
11. A method of controlling execution as recited in claim 10, further comprising if the rule does not have a matching special audit target, examining the set of rules again for matching audit targets.
12. A system for controlling the execution of an executable file, the system comprising: a database system for storing and retrieving execution rules; an administrative console for use by a system administrator to view and modify the execution rules; a user notification component for receiving user authorization requests and sending i user replies to the requests; a server for retrieving rules stored in the database system, the server in operative communication with the administrative console to supply the rules to and receive rules from the administrative console; and a protection module in operative communication with the server over a secure channel to obtain stored execution rules and in operative communication with the user notification component to send user authorization requests and to receive user replies, the protection module configured to intercept services provided by an operating system for executing executable files and to apply the execution rules to an intercepted executable file.
13. A system for controlling the execution of an executable file as recited in claim 12, wherein execution rules stored in the database include an ordered set of rules describing allowed targets, objects, and schedules, wherein allowed targets includes a list of allowed users or computer systems, allowed objects includes a list of permitted executables, each uniquely identifiable, and whether user authorization is permitted, and allowed schedules includes a list of conditions under which an execution is allowed.
14. A method of controlling execution as recited in claim 13, wherein each executable in the list of permitted executables is identifiable by means of a cryptographic digest.
15. A method of controlling execution as recited in claim 14, wherein the cryptographic digest is computed from the binary image of the executable.
16. A method of controlling execution as recited in claim 15, wherein the binary image is a full binary image.
17. A method of controlling execution as recited in claim 15, wherein the binary image is a partial binary image.
18. A method of controlling execution as recited in claim 13, wherein the list of permitted executables is identifiable by means of a digital certificate.
19. A method of controlling execution as recited in claim 12, further comprising a centralized audit storage system for storing audit data when execution rules applied to an intercepted executable file have special audit targets indicating that the permission or denial of execution should be recorded.
PCT/IB2005/001623 2004-04-19 2005-04-18 On-line centralized and local authorization of executable files WO2005099340A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP05744086A EP1745342A2 (en) 2004-04-19 2005-04-18 On-line centralized and local authorization of executable files

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US56298204P 2004-04-19 2004-04-19
US56298304P 2004-04-19 2004-04-19
US60/562,982 2004-04-19
US60/562,983 2004-04-19
US56457904P 2004-04-23 2004-04-23
US60/564,579 2004-04-23

Publications (2)

Publication Number Publication Date
WO2005099340A2 true WO2005099340A2 (en) 2005-10-27
WO2005099340A3 WO2005099340A3 (en) 2006-04-20

Family

ID=35150392

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/IB2005/001623 WO2005099340A2 (en) 2004-04-19 2005-04-18 On-line centralized and local authorization of executable files
PCT/IB2005/002335 WO2005099342A2 (en) 2004-04-19 2005-04-18 A generic framework for runtime interception and execution control of interpreted languages

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/IB2005/002335 WO2005099342A2 (en) 2004-04-19 2005-04-18 A generic framework for runtime interception and execution control of interpreted languages

Country Status (3)

Country Link
US (4) US7487495B2 (en)
EP (2) EP1745343B1 (en)
WO (2) WO2005099340A2 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1457885A2 (en) * 2003-03-14 2004-09-15 Websense, Inc. System and method of monitoring and controlling application files
EP1708115A1 (en) * 2005-03-28 2006-10-04 Microsoft Corporation System and method for identifying and removing potentially unwanted software
US7529754B2 (en) 2003-03-14 2009-05-05 Websense, Inc. System and method of monitoring and controlling application files
GB2457305A (en) * 2008-02-11 2009-08-12 Symbian Software Ltd Controlling access to system resources using script and application identifiers
US8453243B2 (en) 2005-12-28 2013-05-28 Websense, Inc. Real time lockdown

Families Citing this family (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002025438A1 (en) * 2000-09-22 2002-03-28 Patchlink.Com Corporation Non-invasive automatic offsite patch fingerprinting and updating system and method
US8539063B1 (en) 2003-08-29 2013-09-17 Mcafee, Inc. Method and system for containment of networked application client software by explicit human input
US7840968B1 (en) 2003-12-17 2010-11-23 Mcafee, Inc. Method and system for containment of usage of language interfaces
US7783735B1 (en) * 2004-03-22 2010-08-24 Mcafee, Inc. Containment of network communication
EP2267624B1 (en) 2004-04-19 2017-07-12 Lumension Security S.A. A generic framework for runtime interception and execution control of interpreted languages
WO2005099340A2 (en) 2004-04-19 2005-10-27 Securewave S.A. On-line centralized and local authorization of executable files
US7873955B1 (en) 2004-09-07 2011-01-18 Mcafee, Inc. Solidifying the executable software set of a computer
WO2006101549A2 (en) 2004-12-03 2006-09-28 Whitecell Software, Inc. Secure system for allowing the execution of authorized computer program code
US7603552B1 (en) * 2005-05-04 2009-10-13 Mcafee, Inc. Piracy prevention using unique module translation
US7856661B1 (en) 2005-07-14 2010-12-21 Mcafee, Inc. Classification of software on networked systems
US7757269B1 (en) 2006-02-02 2010-07-13 Mcafee, Inc. Enforcing alignment of approved changes and deployed changes in the software change life-cycle
US20070226800A1 (en) * 2006-03-22 2007-09-27 Tony Nichols Method and system for denying pestware direct drive access
US7895573B1 (en) 2006-03-27 2011-02-22 Mcafee, Inc. Execution environment file inventory
US7870387B1 (en) * 2006-04-07 2011-01-11 Mcafee, Inc. Program-based authorization
US8352930B1 (en) 2006-04-24 2013-01-08 Mcafee, Inc. Software modification by group to minimize breakage
US8555404B1 (en) 2006-05-18 2013-10-08 Mcafee, Inc. Connectivity-based authorization
US8117441B2 (en) * 2006-06-20 2012-02-14 Microsoft Corporation Integrating security protection tools with computer device integrity and privacy policy
US8190868B2 (en) 2006-08-07 2012-05-29 Webroot Inc. Malware management through kernel detection
US9424154B2 (en) 2007-01-10 2016-08-23 Mcafee, Inc. Method of and system for computer system state checks
US8332929B1 (en) 2007-01-10 2012-12-11 Mcafee, Inc. Method and apparatus for process enforced configuration management
US9906549B2 (en) * 2007-09-06 2018-02-27 Microsoft Technology Licensing, Llc Proxy engine for custom handling of web content
US9043861B2 (en) 2007-09-17 2015-05-26 Ulrich Lang Method and system for managing security policies
US8195931B1 (en) 2007-10-31 2012-06-05 Mcafee, Inc. Application change control
US8515075B1 (en) 2008-01-31 2013-08-20 Mcafee, Inc. Method of and system for malicious software detection using critical address space protection
JP2009211190A (en) * 2008-02-29 2009-09-17 Hitachi Ltd Information processor
US8615502B2 (en) 2008-04-18 2013-12-24 Mcafee, Inc. Method of and system for reverse mapping vnode pointers
US8176554B1 (en) * 2008-05-30 2012-05-08 Symantec Corporation Malware detection through symbol whitelisting
EP2318955A1 (en) 2008-06-30 2011-05-11 Websense, Inc. System and method for dynamic and real-time categorization of webpages
US8544003B1 (en) 2008-12-11 2013-09-24 Mcafee, Inc. System and method for managing virtual machine configurations
US8332909B2 (en) * 2008-12-16 2012-12-11 Microsoft Corporation Automated software restriction policy rule generation
US8984296B1 (en) * 2009-03-29 2015-03-17 Cypress Semiconductor Corporation Device driver self authentication method and system
US11489857B2 (en) 2009-04-21 2022-11-01 Webroot Inc. System and method for developing a risk profile for an internet resource
US9130972B2 (en) 2009-05-26 2015-09-08 Websense, Inc. Systems and methods for efficient detection of fingerprinted data and information
US8341627B2 (en) 2009-08-21 2012-12-25 Mcafee, Inc. Method and system for providing user space address protection from writable memory area in a virtual environment
US8381284B2 (en) 2009-08-21 2013-02-19 Mcafee, Inc. System and method for enforcing security policies in a virtual environment
US9552497B2 (en) 2009-11-10 2017-01-24 Mcafee, Inc. System and method for preventing data loss using virtual machine wrapped applications
ES2628224T3 (en) * 2010-05-21 2017-08-02 Sfnt Germany Gmbh Method to control the execution of an application in a computer system
US20120011573A1 (en) * 2010-07-12 2012-01-12 Menasce Daniel A System and method for managing insider security threats
US8925101B2 (en) 2010-07-28 2014-12-30 Mcafee, Inc. System and method for local protection against malicious software
US8938800B2 (en) 2010-07-28 2015-01-20 Mcafee, Inc. System and method for network level protection against malicious software
US8549003B1 (en) 2010-09-12 2013-10-01 Mcafee, Inc. System and method for clustering host inventories
US8745064B2 (en) 2010-09-13 2014-06-03 Lumension Security, Inc. Systems and methods for operating a saturated hash table
EP2439673A3 (en) 2010-10-11 2012-05-30 Lumension Security, Inc. Systems and methods for implementing application control security
US9075993B2 (en) 2011-01-24 2015-07-07 Mcafee, Inc. System and method for selectively grouping and managing program files
US9112830B2 (en) 2011-02-23 2015-08-18 Mcafee, Inc. System and method for interlocking a host and a gateway
US20130268559A1 (en) 2011-07-13 2013-10-10 Z124 Virtual file system remote search
US9152404B2 (en) * 2011-07-13 2015-10-06 Z124 Remote device filter
US8631244B1 (en) 2011-08-11 2014-01-14 Rockwell Collins, Inc. System and method for preventing computer malware from exfiltrating data from a user computer in a network via the internet
US20130268703A1 (en) 2011-09-27 2013-10-10 Z124 Rules based hierarchical data virtualization
US9594881B2 (en) 2011-09-09 2017-03-14 Mcafee, Inc. System and method for passive threat detection using virtual memory inspection
US8694738B2 (en) 2011-10-11 2014-04-08 Mcafee, Inc. System and method for critical address space protection in a hypervisor environment
US9069586B2 (en) 2011-10-13 2015-06-30 Mcafee, Inc. System and method for kernel rootkit protection in a hypervisor environment
US8973144B2 (en) 2011-10-13 2015-03-03 Mcafee, Inc. System and method for kernel rootkit protection in a hypervisor environment
US8800024B2 (en) 2011-10-17 2014-08-05 Mcafee, Inc. System and method for host-initiated firewall discovery in a network environment
US8713668B2 (en) 2011-10-17 2014-04-29 Mcafee, Inc. System and method for redirected firewall discovery in a network environment
US9059853B1 (en) 2012-02-22 2015-06-16 Rockwell Collins, Inc. System and method for preventing a computing device from obtaining unauthorized access to a secure network or trusted computing environment
US8656494B2 (en) * 2012-02-28 2014-02-18 Kaspersky Lab, Zao System and method for optimization of antivirus processing of disk files
US8739272B1 (en) 2012-04-02 2014-05-27 Mcafee, Inc. System and method for interlocking a host and a gateway
US8694961B2 (en) * 2012-04-03 2014-04-08 Microsoft Corporation Thread-agile execution of dynamic programming language programs
US8661246B1 (en) 2012-04-09 2014-02-25 Rockwell Collins, Inc. System and method for protecting certificate applications using a hardened proxy
US8959362B2 (en) * 2012-04-30 2015-02-17 General Electric Company Systems and methods for controlling file execution for industrial control systems
US8973146B2 (en) 2012-12-27 2015-03-03 Mcafee, Inc. Herd based scan avoidance system in a network environment
WO2015060857A1 (en) 2013-10-24 2015-04-30 Mcafee, Inc. Agent assisted malicious application blocking in a network environment
US9430216B2 (en) 2014-05-11 2016-08-30 Lumension Security, Inc. Self-contained executable for predetermined software updating
US10339305B2 (en) * 2016-02-26 2019-07-02 Cylance Inc. Sub-execution environment controller
US11082491B2 (en) 2016-10-07 2021-08-03 Microsoft Technology Licensing, Llc Propagating origin information for applications during application installation
US10949642B2 (en) * 2017-11-24 2021-03-16 Integrated Biometrics, Llc Method for capture of a fingerprint using an electro-optical material
US10884899B2 (en) * 2018-10-01 2021-01-05 International Business Machines Corporation Optimized trampoline design for fast software tracing

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998050843A1 (en) * 1997-05-02 1998-11-12 Network Associates, Inc. Process-level data security system
WO2001098876A2 (en) * 2000-06-21 2001-12-27 Microsoft Corporation Filtering a permission set using permission requests associated with a code assembly
US20020099952A1 (en) * 2000-07-24 2002-07-25 Lambert John J. Policies for secure software execution

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2742892B1 (en) * 1995-12-21 1998-02-13 Bull Sa SOFTWARE PROTECTION SYSTEM FOR A WRITTEN LANGUAGE COMPUTER
US5794049A (en) * 1996-06-05 1998-08-11 Sun Microsystems, Inc. Computer system and method for executing architecture specific code with reduced run-time memory space requirements
US6721941B1 (en) * 1996-08-27 2004-04-13 Compuware Corporation Collection of timing and coverage data through a debugging interface
US6094528A (en) * 1996-10-24 2000-07-25 Sun Microsystems, Inc. Method and apparatus for system building with a transactional interpreter
US5923878A (en) * 1996-11-13 1999-07-13 Sun Microsystems, Inc. System, method and apparatus of directly executing an architecture-independent binary program
US6367012B1 (en) * 1996-12-06 2002-04-02 Microsoft Corporation Embedding certifications in executable files for network transmission
US5854930A (en) * 1996-12-30 1998-12-29 Mci Communications Corporations System, method, and computer program product for script processing
CA2194848C (en) * 1997-01-10 2003-12-23 Jonathan Layes Condition handling using script interpreters
US6766454B1 (en) * 1997-04-08 2004-07-20 Visto Corporation System and method for using an authentication applet to identify and authenticate a user in a computer network
US6473893B1 (en) * 1997-05-30 2002-10-29 International Business Machines Corporation Information objects system, method, and computer program organization
US6141793A (en) * 1998-04-01 2000-10-31 Hewlett-Packard Company Apparatus and method for increasing the performance of interpreted programs running on a server
EP1133188A3 (en) * 2000-02-23 2004-11-24 Sony Corporation Information processing apparatus, network system, recording medium
US6941470B1 (en) * 2000-04-07 2005-09-06 Everdream Corporation Protected execution environments within a computer system
GB2404262B (en) * 2003-06-19 2008-03-05 Yaron Mayer System and method for comprehensive general generic protection for computers against malicious programs that may steal information and/or cause damages
WO2002025438A1 (en) 2000-09-22 2002-03-28 Patchlink.Com Corporation Non-invasive automatic offsite patch fingerprinting and updating system and method
US6686002B2 (en) * 2001-01-11 2004-02-03 Seal-Ops, Llc Sealing strip composition
US7613930B2 (en) * 2001-01-19 2009-11-03 Trustware International Limited Method for protecting computer programs and data from hostile code
US7278158B2 (en) 2001-03-16 2007-10-02 Securewave S.A. Method and system for shadowing accesses to removable medium storage devices
US20030014667A1 (en) 2001-07-16 2003-01-16 Andrei Kolichtchak Buffer overflow attack detection and suppression
US8041815B2 (en) * 2001-09-21 2011-10-18 Microsoft Corporation Systems and methods for managing network connectivity for mobile users
AU2002326226B2 (en) * 2001-09-28 2008-06-12 High Density Devices As Method and device for encryption/decryption of data on mass storage device
US6996814B2 (en) * 2001-11-14 2006-02-07 Sun Microsystems, Inc. Method and apparatus for dynamically compiling byte codes into native code
US20030099952A1 (en) * 2001-11-26 2003-05-29 Roland Green Microarrays with visible pattern detection
US20030131245A1 (en) * 2002-01-04 2003-07-10 Michael Linderman Communication security system
US7219344B2 (en) * 2002-04-30 2007-05-15 Accenture Global Services Gmbh Method and apparatus for deploying programs and computing platforms to selected computers
US7454508B2 (en) * 2002-06-28 2008-11-18 Microsoft Corporation Consent mechanism for online entities
US7500108B2 (en) * 2004-03-01 2009-03-03 Microsoft Corporation Metered execution of code
EP2267624B1 (en) 2004-04-19 2017-07-12 Lumension Security S.A. A generic framework for runtime interception and execution control of interpreted languages
WO2005099340A2 (en) 2004-04-19 2005-10-27 Securewave S.A. On-line centralized and local authorization of executable files
US7802110B2 (en) * 2004-08-25 2010-09-21 Microsoft Corporation System and method for secure execution of program code
US20090210267A1 (en) 2008-02-18 2009-08-20 Bryan David Fish System and method for automatically mapping security controls to subjects

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998050843A1 (en) * 1997-05-02 1998-11-12 Network Associates, Inc. Process-level data security system
WO2001098876A2 (en) * 2000-06-21 2001-12-27 Microsoft Corporation Filtering a permission set using permission requests associated with a code assembly
US20020099952A1 (en) * 2000-07-24 2002-07-25 Lambert John J. Policies for secure software execution

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1457885A2 (en) * 2003-03-14 2004-09-15 Websense, Inc. System and method of monitoring and controlling application files
EP1457885A3 (en) * 2003-03-14 2007-10-17 Websense, Inc. System and method of monitoring and controlling application files
US7529754B2 (en) 2003-03-14 2009-05-05 Websense, Inc. System and method of monitoring and controlling application files
US9692790B2 (en) 2003-03-14 2017-06-27 Websense, Llc System and method of monitoring and controlling application files
EP1708115A1 (en) * 2005-03-28 2006-10-04 Microsoft Corporation System and method for identifying and removing potentially unwanted software
US7685149B2 (en) 2005-03-28 2010-03-23 Microsoft Corporation Identifying and removing potentially unwanted software
US8453243B2 (en) 2005-12-28 2013-05-28 Websense, Inc. Real time lockdown
GB2457305A (en) * 2008-02-11 2009-08-12 Symbian Software Ltd Controlling access to system resources using script and application identifiers

Also Published As

Publication number Publication date
US20090133004A1 (en) 2009-05-21
EP1745343B1 (en) 2017-06-07
WO2005099342A3 (en) 2006-04-20
US8001536B2 (en) 2011-08-16
EP1745342A2 (en) 2007-01-24
WO2005099342A2 (en) 2005-10-27
US8474011B2 (en) 2013-06-25
US8060924B2 (en) 2011-11-15
US7487495B2 (en) 2009-02-03
US20120047556A1 (en) 2012-02-23
US20050262558A1 (en) 2005-11-24
US20050246683A1 (en) 2005-11-03
WO2005099340A3 (en) 2006-04-20
EP1745343A2 (en) 2007-01-24

Similar Documents

Publication Publication Date Title
US8474011B2 (en) On-line centralized and local authorization of executable files
EP2267625A2 (en) On-line centralized and local authorization of executable files
US7698744B2 (en) Secure system for allowing the execution of authorized computer program code
US8719901B2 (en) Secure consultation system
US8347359B2 (en) Encryption sentinel system and method
Whitelisting et al. Application Whitelisting: Enhancing Host Security

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWE Wipo information: entry into national phase

Ref document number: 2005744086

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 2005744086

Country of ref document: EP