WO2008036833A2 - Système et procédé permettant de sécuriser un système informatique par une commande sélective de l'accès en écriture à un support de stockage de données - Google Patents

Système et procédé permettant de sécuriser un système informatique par une commande sélective de l'accès en écriture à un support de stockage de données Download PDF

Info

Publication number
WO2008036833A2
WO2008036833A2 PCT/US2007/079065 US2007079065W WO2008036833A2 WO 2008036833 A2 WO2008036833 A2 WO 2008036833A2 US 2007079065 W US2007079065 W US 2007079065W WO 2008036833 A2 WO2008036833 A2 WO 2008036833A2
Authority
WO
WIPO (PCT)
Prior art keywords
application
computer
storage medium
data
file
Prior art date
Application number
PCT/US2007/079065
Other languages
English (en)
Other versions
WO2008036833A3 (fr
Inventor
John Safa
Original Assignee
Drive Sentry, Inc.
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 Drive Sentry, Inc. filed Critical Drive Sentry, Inc.
Publication of WO2008036833A2 publication Critical patent/WO2008036833A2/fr
Publication of WO2008036833A3 publication Critical patent/WO2008036833A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G06F21/80—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in storage media based on magnetic or optical technology, e.g. disks with sectors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing 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/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices

Definitions

  • TITLE SYSTEM AND METHOD TO SECURE A COMPUTER SYSTEM
  • the present invention relates to a method of controlling the writing of data to a storage medium such as a hard drive in a computer system by an application running in a memory of the computer system.
  • the present invention seeks to provide an improved method of preventing the infection of a computer by a virus program.
  • a method of controlling write access to a storage medium by monitoring an application detecting an attempt by the application to write data to said storage medium; interrogating a rules database in response to said detection; and controlling write access to the storage medium by the application in dependence on said interrogation.
  • Figure 1 is a process diagram showing the control of a write instruction of an application in accordance with a preferred method of the present invention
  • Figure 2 is a process diagram illustrating an action of the preferred method according to the present invention.
  • Figure 3 is a flow diagram of the preferred method.
  • Figure 4 shows the user interface querying the user for a decision regarding an application.
  • Figure 5 shows the user interface indicating the collective response of other users to the same application request and logical location to store vault data.
  • Figure 6 shows a close-up of the user interface indicating the collective response of other users to the same application request.
  • Figure 7 depicts the connection between two computers and a central server and the distribution of permission values from one computer to the other through the server.
  • Figure 8 depicts an alternative control flow in accordance with the invention.
  • Figure 9 depicts the user interface showing the reason a particular user responded to the query.
  • the interrogation comprises determining the write access allowed for the application and controlling the write access in dependence thereon.
  • write access is controlled to one of a plurality of levels, the levels including a first level in which no write access is allowed, a second level in which full write access is allowed, and a third level in which write access is only allowed for at least one specified file extension.
  • the method further includes generating a prompt on a display requesting response from a user.
  • the user can respond to the prompt by choosing from a number of possible responses, the possible responses including a first response for allowing write access, a second response for blocking write access and a third response for allowing write access to a specific file type only.
  • the user can respond further by selecting from a plurality of further actions, the further actions including, storing the chosen response in the rules database; and applying the chosen response only for the current attempt by the application to write data to said storage medium.
  • FIG. 1 shows an application 12 which is running in a memory 14 of a computer system.
  • the computer system also has a storage medium 16 which here is in the form of a hard drive or disc.
  • the typical computer is comprised of a central processing unit, a main memory, a mass storage device and input and output connections.
  • the input and output include keyboards, monitors and network connections.
  • the mass storage device can be a magnetic disk, optical disk or a large array of semiconductor devices.
  • the main memory is typically an array of semiconductor circuits.
  • the central processing unit is operatively connected to these components so that it can both control their activities and move data among the components.
  • the central processing unit can load data off of the mass storage device and write it into main memory. This data can either be treated as a program or as data to be processed. If a program, the central processing unit passes control to the program data and executes the instructions encoded in the data.
  • Program data can be an application servicing the user.
  • an application 18 which is here termed as an "interceptor" program.
  • This runs constantly in the background.
  • the interceptor program can run continuously in the background as a process, including as part of the computer operating system.
  • the application 12 attempts to write data to the disc 16
  • the interceptor program 18 detects this and interrogates a rules database 20 to determine the authority of the application 12 to write to the hard drive 16.
  • the database 20 is preferably encrypted and lists applications approved by the user with their level of write access.
  • data is used here in its general sense to include any form of data including programs.
  • the preferred number of possible write access levels for an application is three, being as follows :-
  • Level 0 this means that no write access to the hard drive 16 is allowed for the application 12.
  • Level 1 this means that full write access is allowed.
  • Level 2 the application is allowed write access to the hard drive 16 for specified file extensions only, (for example ".doc" file extensions for document files in Microsoft Office
  • TM file extensions of data that can be written to the hard drive are also held in the database 20.
  • Level 4 The application can be granted to have access to a specific drive or directory.
  • the database can contain corresponding references between applications and file types or file extensions that such application may write.
  • manager program 22 which can sit in the memory 14 alongside the interceptor program 18 and can also be run on start up of the computer or at any preferred time during operation of the interceptor program 18, running continuously in the background, including as part of the computer operating system.
  • Figure 2 illustrates the interface of the manager program 22 with the rules database 20 and the system user.
  • the interceptor program 18 When the interceptor program 18 detects that the application 12 is attempting to write to the hard drive 16 it initiates the loading and execution of the manager program 22. The latter interrogates the rules database 20 to determine the access level of the application 12 and controls the interceptor program 18 to allow or prevent the write action in dependence on the relevant rule in the rules database 20. If the application 12 is not listed in the rules database 20 or the particular write instruction is not allowed, the manager program 22 can generate a prompt signal to be displayed on the computer screen, requiring the user to make a decision on whether or not to allow the write instruction. This prompt can have a number of responses for the user to choose, such as "Allow write access", "Block write access” and "Allow write access to this file type only". Having chosen the response the user can also select one of a number of further actions as follows.
  • the rules database 20 can be updated such that all future attempts by the application 12 to write files of that same extension to the hard drive 16 would be automatically allowed or prevented or result in further user prompts.
  • determining the "file extension" also includes detecting the actual type of file by examination of its contents, especially in the case where internally such file is an executable.
  • Windows XP in a Nutshell, Second Edition, ⁇ 2005, O'Reilly Media, U. S. A is hereby incorporated by reference.
  • the manager program 22 can also be loaded and executed by the user at start up of the computer or at any time in order to scan the hard drive 16 for programs to build a full rules database 20.
  • the manager program 22 can also be prompted by the user to display a list of programs within the rules database 20 with the access level of each program, giving the user the option to delete, add or modify each entry.
  • a rules database can be pre-created, or incrementally improved and distributed to the computer electronically, either embodied on a disk or electronically over a data network. Rules determined by users can also be uploaded to a central depository as well. Rule updates can be downloaded into the computer. Rules can also be included with installation files for the particular application that the installation file is creating.
  • the installation process has to be sufficiently certified that program installation does not corrupt the database by incorporating bogus rules that service virus writers.
  • Certification can include digital signing protocols between the invention and the installing program and other modes of verifying authenticity, including remotely accessed keys or trusted third parties accessed over a network. Rules can also be derived by examining operating system data where such data presents correspondences between installed program applications and file types and extensions. In this case, other authentication may be necessary in order to avoid virus writers from inserting bogus file type associations within the operating system databases. Practitioners of ordinary skill will recognize that authentication can include cyclic redundancy checking (CRC) and other types of numerical algorithms that detect when tampering has occurred.
  • CRC cyclic redundancy checking
  • a flow diagram 30 is shown which illustrates the method followed on initiation 32 of the interceptor program 18.
  • the interceptor module is a kernel mode driver which has a higher level of access to the Windows file system and system resources.
  • the interceptor program 18 waits in a monitoring step 34 during which it monitors for any file write operation to the hard drive 16. In the absence of a file write operation, the interceptor program 18 remains in the monitoring step 34 and continues to check for a file write operation. If a file write operation is detected then write is pended in a queue and the interceptor program 18 proceeds to complete a series of rule checking steps 36 by calling a kernel mode rules checker. Initially the rules checker checks if the application 12 making the write attempt is listed in the rules database 20.
  • the rules database can be stored on the local personal computer, client computer or remote server. In the preferred embodiment, a recent list of rules that have been interrogated may also be held in a cache in kernel memory cache which speeds up applications that are frequently accessing the drive. If the application 12 is not listed then the interceptor program 18 initiates the manager program 22 to allow the user to make a decision about the correct way in which to proceed.
  • the interceptor program 18 proceeds to the next rule checking step.
  • the interceptor program 18 goes on to check if the write privileges of the application 12. Initially the hard drive write privilege of the application 12 is checked. If the application 12 does not have privilege to write to the hard drive then write access is blocked. Otherwise, the interceptor program 18 checks if the application 12 has write privilege for the specific file type, directory or filename which the write attempt has been made to. The manager program can, at this step, check the data to be written or the file to which such data is being appended to determine if the contents of the file are the appropriate file type, that is, to avoid improper creation of portable executable (PE) or other files whose contents are intended to be used as computer program code. PE files are files that are portable across all Microsoft 32-bit operating systems.
  • the same PE-format file can be executed on any version of Windows 95, 98, Me, NT, and 2000. This is supplemental to checking the file extension in order to avoid the virus propagation technique described above. If the application 12 does have privilege to write to the specific detected file type or file extension then the write operation is allowed. Otherwise write access is blocked.
  • a signature of the application which is a number that is calculated to determine whether a code block has been tampered with, is also stored in the rules database. Practitioners of ordinary skill will recognize that CRC, or cyclic redundancy checks or other types of signature checking, for example, MD5 may be used.
  • a prompt module can ask the user what access level or permission they wish to allow for the application. This can involve denying or blocking the application write for that instant or for ever.
  • the user can also get information from other users responses to a specific application by data being downloaded from a central server over a data network, both a proprietary network as well as the Internet.
  • the system also allows feedback on the users responses to write requests to be uploaded and stored on a central server. This stores if the user allowed or denied the application write, or what level of permission was applied and if it was denied, the reason why.
  • the reason the user denied it can be a number of responses such as 'virus', 'Trojan' etc.
  • the applications name and signature are stored with the reason.
  • An embodiment of the invention can enforce strict rules on applications writing to disk drives, memory devices, drivers, external devices or removable media.
  • the rules can be implemented when the application first writes to the drive or via a graphical user interface or application main window.
  • the interface permits the creation and management of a set of sophisticated rules that determine what files types, directory or drive the application can or can't write.
  • the invention permits a user's computer to prevent write access (in real-time) to disk or other memory by malicious programs writing to applications or destroying files.
  • Viruses such as Nyxem can be blocked in real-time when they attempt to write over popular file types such as documents and spreadsheets.
  • the invention can prevent disk drive space from being wasted by blocking applications from saving downloaded media used for advertising.
  • Typical files can be HTML pages, Flash Movies and graphics files, which, by file type, can be blocked from being saved by browser application like FireFox or Internet Explorer.
  • Small files containing indicia about a user's web usage history, also called cookies, can be block from being written to the disk drive by blocking them being saved into a specific directory.
  • Specific file attachments can be blocked in order to prevent applications like instant messaging tools or email clients such as screen savers and other executables from being saved.
  • the invention features a powerful file and registry watch which overrides the default application rules by allowing the user to monitor attempted changes of critical system files or registry keys in real-time for any attempted writes.
  • This prevents viruses and other malicious code overwriting or damaging valuable data or modifying settings in the system registry.
  • the user can separately specify to automatically block, allow or prompt before each action occurs.
  • the user can specify wildcards such as *.DOC to prompt when certain files types are about to be written to and then allow the user to be prompted before the write occurs.
  • This functionality prevents Viruses and Trojans from changing registry settings to allow themselves to start-up automatically. It also prevents Viruses and Trojans changing system files such as HOST settings. It also protects files from Virus attacks by checking before documents, spreadsheets or other valuable data are modified.
  • the system can also protect an entire directory by watching files being changed. If write access is approved for a device or hard drive, certain directories or files can be specified that still require a manual permission for that directory. This ensures that spurious writes to a directory or dangerous behaviour of a virus are blocked before their most destructive act takes place.
  • the software embodying the invention allows the user to view a log of all applications writing out files and registry keys. This allows the user to check what is actually being written by each application. The user can right click on any file(s) in the log list and then either open them for viewing or delete them from the drive.
  • the activity log can also display a real-time graph of statistics that show the file and registry writes and any rules that have been modified.
  • the system can provide additional information about applications by connecting to a service embodied in the central database accessible by a communications network.
  • the database is populated with descriptions and recommended actions for popular applications and processes.
  • Service also displays on the user's computer screen statistical information on what other system users have allowed or denied writing to their computer.
  • DriveSentry detects an unknown program writing to a drive.
  • a pop window is displayed and the user has a choice to block or allow the process from writing.
  • the user can also click an info button which displays another screen.
  • the user can click an info button which displays the DriveSentry advisor window.
  • a connection is made to our server and displays statistical information about the application.
  • the dialog displays a bar chart which shows a % of the number of people that have blocked or allowed the application in the past. Another chart breaks down the reason why people blocked the application.
  • each write to disk requested by a process has to be checked by polling the system's database. That is, the identity of the process or its parent application has to be used to query the database to find what access rules apply. If the database of rules is entirely on the disk drive, this will slow down performance of a computer because for every disk access, there is another disk access required.
  • the cache can be stored the name of the action (e.g. write), name of the application or process and the access writes, e.g. file type or file name or device type.
  • the cache is typically populated by the most recently used rules.
  • a cache in a computer memory there are many strategies for populating a cache in a computer memory.
  • One way is to store in the cache the last distinct N database query results, where N is selected by the practicality of how large a cache in main memory can be supported.
  • the cache can be populated with those rules associated with any active application, and the section of the cache devoted to a terminated application being flushed.
  • the location of the cache is typically stored in a secure location on the computer. This typically is the kernel memory, where driver code is stored.
  • the kernel memory is set up by the operating system to be non-writable by processes not associated with that section of kernel. In this case, the kernel memory devoted to this cache is associated only with the security system embodying the invention that is running as an application or process.
  • the memory allocated to the cache can be encrypted with a check key like a CRC or MD5 so that the application can verify that the rules recovered from the encrypted cache have not been corrupted by some other application or process or virus. Any other method of securing the rule cache from tampering may be used.
  • the Vault system allows applications and data to be recovered under certain circumstances if they are destroyed by a virus or other malicious code.
  • an application (1) runs on the user's computer and its' signature (4) and access rules (3) are read via the security system (2) to check that it's not been modified and it has access to write to the drive.
  • the user can select any file such as a document or spreadsheet to be encrypted and compressed in a secure location as they are processed in real-time by the system.
  • the user can at anytime access the 'Vaulted' copy and restore the file.
  • the system can also store specific loader data on an application that can be easily used to repair an application if it becomes infected by a virus or other malicious code.
  • the system can save part or all of an encrypted copy of an executable.
  • This can include a CRC (cyclic redundancy check) or MD5 code or similar code that tests the integrity of the block of code.
  • CRC cyclic redundancy check
  • MD5 code similar code that tests the integrity of the block of code.
  • the CRC or MD5 of the original executable file is checked. If there is an error, then it means the first copy of the executable is corrupted.
  • the vault system can be called to decrypt its encrypted copy of the executable. If the entire executable has been placed in the vault, then the entire first executable copy can be replaced.
  • the system can do a byte for byte comparison of that block between the decrypted vault copy and the corrupted first copy. Where there are discrepancies, the portions of the first copy can be replaced. At that point, the same CRC or MD5 can be checked to see if the portion of the executable in the vault has fully repaired the first copy of the executable. If so, then the executable is launched. If not, then the process fails and the application is stopped. Practitioners of ordinary skill will recognize that the process as applied to executables can also apply to data files, provided that if the data file is corrupted and cannot be repaired, then an error may be returned to the application rather than stopping the application.
  • some processes can be specified to have full privilege. For example, some operating system processes must be given broad access without checking the database for permission.
  • the security software can specify that certain Windows processes, that is, processes spawned by Windows for the operating system itself, rather than for an application, are writing to important Windows files. This might occur when the Windows operating system is updating its own code. In this case, the security system will permit writes to the *.ini, *.sys and *.exe modules that comprise the Windows operating system.
  • the Windows Registry is a database that stores configuration data about the computer it is running on. Practitioners of ordinary skill will recognize that hidden processes can be launched by inserting commands into the Registry, including in entries such as "run once" or "run”. These entries cause processes to launch on boot-up without any user interaction.
  • the invention is arranged to check for writes to these critical operating system files and specific entries in the operating system files. If a write is approved, the system will log the write: that is, it will store in a data file the specific data being written into the file and its destination in the file.
  • the system will place in the log the value of the data in the file that was overwritten.
  • the log file can be used by the system to detect what corrupt data was written to the operating system file.
  • the log file can also be used to restore the affected operating system file.
  • critical writes to devices and drivers can be trapped by the system and similarly checked for their integrity or permission. This includes checking writes to any removable devices that may be attached to the computer temporarily.
  • the database that the system builds up that notes whether an application has permission to write or other levels of access to resources on the computer can be shared among multiple users.
  • all or part of the database associated with the system, where permissions or denials are stored can be uploaded to a central database by means of typical data communications networks, including the Internet.
  • the database is stored on a memory device that is operably attached to a computer that is further operably attached to the data network.
  • each update to a user's database with regard to application permissions is uploaded to update the central database.
  • Additional information may be stored in the central database, for example, the number of users who has approved and denied the applications' request for the compute resource.
  • the system can query the central server for the data it has regarding that application. This data can be transmitted to the user's computer and the information displayed, as shown on Figure 5. The user can then decide which action to take, and such decision can then be inserted into the local database on the user's computer.
  • FIG. 7 there are two or more computers, (1) and (6), each using an instance of the invention, embodied as software running on the computers.
  • a central server (8) housing a database on a disk drive.
  • the second user's computer running an embodiment of the invention (6) may encounter a file access request by an unknown application (5). As described herein, this will result in the user interface popping up and requesting that the user respond as to whether to allow or block the access and it can also ask the user the reason, for example, the user may know that the identified application is a virus, Trojan or some other type of program. This information is stored in the local computer's database as described herein.
  • this information can be transmitted from the second computer (6) to the central server (8) by the formation of a message data packet that is comprised of the name of the application or the application's executable filename, or process name, the file type accessed, and the user's response, for example, allow or deny (7).
  • the server (8) when it receives such a packet will update its database as follows: The server will search its database for a record corresponding to that application or the application's executable filename. If no record is found a new record is created that includes the information provided by the second user, and that one allowance was permitted (or denial, as the case may be). As additional users report on the same application or executable file or process, their responses are combined with the data present in that data record.
  • the central server (8) has combined the responses of many users to the same application, process or executable request.
  • the local embodiment of the invention initiates a local search for that application, executable or process name (2). If there is no local entry for that application, executable or process (3), then the first computer makes a request (4) to the central server (8) to see if the central server has any information about that application, executable or process.
  • the central server searches its database, and finding the compiled data described above, sends a message data packet (9) back to the first computer.
  • the first computer then presents this data to the first user by means of a typical computer interface, including a graphical interface as shown in Figure 5. The user's selection of what to do is then entered into the local computer's database.
  • the local database of application names, executable names and process names and their corresponding permissions and restrictions for certain file types and directory locations can be immediately populated upon installation of the software that embodies the invention.
  • the database can be updated automatically or upon a user request to the central server.
  • the central server would hold a database containing authorized or fully vetted applications, executables and processes that have been checked by the software manufacturer or some trusted third party.
  • a manufacturer of an application can create a file listing all executables that comprise the manufacturer's application and the file type or file name and directory where such executable is supposed to appropriately write data. This information can be incorporated into the central server's database.
  • the manufacturer can transmit to the central server (8) a request to include certain information into the database.
  • This data will be indicated as actions recommended by the manufacturer of that specific application. As a result, this data can be used to automatically populate the local database residing on the computers, (1) and (6).
  • the central server (8) can deliver a response (9) that indicates that the manufacturer of the software either recommends an allowance, or that the manufacturer does not list the action as required by an uncorrupted copy of their software.
  • the system installed on a particular user's computer has a unique identifier, identifying that instance of the program.
  • the system sends update data to the central database server, it also sends the indicia of identity.
  • the central database server will only upload permission data for a given application from a specific indicia of identity once.
  • a software producer that is, a legitimate software developer, may analyze the operation of one or more of its application products to detect the resource accesses that would be detected and checked by the security system.
  • the software developer can then compile a data file where there are two associated entries: the resource being accessed and the application making the access request. Further information can be provided, for example, the identity of the process, the type of access and other typical information.
  • This data file can then be converted into permission data that can be stored in the central database.
  • the permission data can be downloaded to a user's computer upon installation of the specific software product.
  • the installed software can send a security check number, like a CRC or MD5 code to the central server. This can be checked for integrity before the permission data is downloaded to the user's computer.
  • users are able to rate other user's submissions for accuracy or report them to DriveSentry administrators for moderation.
  • Administrators associated with the central server or a service business relying on the central server can maintain and add entries to the database.
  • An incentive can be provided to users in order that they participate effectively, for example to provide the top 5 submitters in a month to receive a cash prize.
  • the system running on the user's computer would launch a interface window that would display notes that have been uploaded by other users and service administrators. Each note could be rated for accuracy by other users and notes would be ordered by their score with the highest being displayed first. A user would also be able to add, edit and delete their notes. If a note was deemed inaccurate, libellous or inflammatory then it would be able to be reported to service administrators. Reported notes would be reviewed daily and deleted.
  • the user interface displays could appear as shown in Figure 8.
  • An icon would represent that the user was an administrator and their location using a flag symbol.
  • the note would be scrollable and contain the description of the application. Notes would be able to be written in multiple languages and filtered upon.
  • the bottom of the note would contain a row of icons that would indicate the average rating of the note. Other users could click on the rating bar and submit their score to the overall accuracy of the note. If the user was the author of the note then they could edit and delete notes. The user could report other users notes to an administrator by click on a button on the note.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Automation & Control Theory (AREA)
  • Bioethics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un système et un procédé destinés à sécuriser un système informatique en surveillant l'accès en écriture à un support de stockage; en détectant une tentative, de la part de l'application, d'écrire des données sur le support de stockage; en interrogeant une base de données de règles en réponse à la détection; et en autorisant ou en refusant à l'application l'accès en écriture au support de stockage en fonction de l'interrogation.
PCT/US2007/079065 2006-09-20 2007-09-20 Système et procédé permettant de sécuriser un système informatique par une commande sélective de l'accès en écriture à un support de stockage de données WO2008036833A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US82637706P 2006-09-20 2006-09-20
US60/826,377 2006-09-20

Publications (2)

Publication Number Publication Date
WO2008036833A2 true WO2008036833A2 (fr) 2008-03-27
WO2008036833A3 WO2008036833A3 (fr) 2009-01-08

Family

ID=39201280

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/079065 WO2008036833A2 (fr) 2006-09-20 2007-09-20 Système et procédé permettant de sécuriser un système informatique par une commande sélective de l'accès en écriture à un support de stockage de données

Country Status (1)

Country Link
WO (1) WO2008036833A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104796326A (zh) * 2015-04-24 2015-07-22 广州多益网络科技有限公司 一种企业im的群组创建方法、数据加载方法及装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5778432A (en) * 1996-07-01 1998-07-07 Motorola, Inc. Method and apparatus for performing different cache replacement algorithms for flush and non-flush operations in response to a cache flush control bit register
US5974549A (en) * 1997-03-27 1999-10-26 Soliton Ltd. Security monitor
US20030061504A1 (en) * 2001-08-13 2003-03-27 Sprigg Stephen A. Application level access privilege to a storage area on a computer device
US20030093643A1 (en) * 2001-11-09 2003-05-15 Britt Joe Freeman Apparatus and method for allocating memory blocks
US20030195887A1 (en) * 2002-04-10 2003-10-16 Emc Corporation Restoring virtual devices
US20040260877A1 (en) * 2003-06-19 2004-12-23 Ip-First Llc Apparatus and method for renaming a cache line
US6944772B2 (en) * 2001-12-26 2005-09-13 D'mitri Dozortsev System and method of enforcing executable code identity verification over the network

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5778432A (en) * 1996-07-01 1998-07-07 Motorola, Inc. Method and apparatus for performing different cache replacement algorithms for flush and non-flush operations in response to a cache flush control bit register
US5974549A (en) * 1997-03-27 1999-10-26 Soliton Ltd. Security monitor
US20030061504A1 (en) * 2001-08-13 2003-03-27 Sprigg Stephen A. Application level access privilege to a storage area on a computer device
US20030093643A1 (en) * 2001-11-09 2003-05-15 Britt Joe Freeman Apparatus and method for allocating memory blocks
US6944772B2 (en) * 2001-12-26 2005-09-13 D'mitri Dozortsev System and method of enforcing executable code identity verification over the network
US20030195887A1 (en) * 2002-04-10 2003-10-16 Emc Corporation Restoring virtual devices
US20040260877A1 (en) * 2003-06-19 2004-12-23 Ip-First Llc Apparatus and method for renaming a cache line

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
SYMANTEC.: 'Norton Internet Security 2000' USER MANUAL. 1999, pages 14 - 31-32 *
SysInternals. FileMon. 27 August 2005 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104796326A (zh) * 2015-04-24 2015-07-22 广州多益网络科技有限公司 一种企业im的群组创建方法、数据加载方法及装置

Also Published As

Publication number Publication date
WO2008036833A3 (fr) 2009-01-08

Similar Documents

Publication Publication Date Title
US7664924B2 (en) System and method to secure a computer system by selective control of write access to a data storage medium
US20100153671A1 (en) System and method to secure a computer system by selective control of write access to a data storage medium
US9600661B2 (en) System and method to secure a computer system by selective control of write access to a data storage medium
US7437766B2 (en) Method and apparatus providing deception and/or altered operation in an information system operating system
US7296274B2 (en) Method and apparatus providing deception and/or altered execution of logic in an information system
US7676845B2 (en) System and method of selectively scanning a file on a computing device for malware
US20100146589A1 (en) System and method to secure a computer system by selective control of write access to a data storage medium
US8612398B2 (en) Clean store for operating system and software recovery
US7739738B1 (en) Enabling clean file cache persistence using dual-boot detection
US8474032B2 (en) Firewall+ storage apparatus, method and system
EP1920338B1 (fr) Systemes et procedes de securite de reseaux
TWI463405B (zh) 用於間碟軟體偵測機制之系統、方法與電腦儲存裝置
US8984636B2 (en) Content extractor and analysis system
US7895651B2 (en) Content tracking in a network security system
US9147073B2 (en) System and method for automatic generation of heuristic algorithms for malicious object identification
US20070180509A1 (en) Practical platform for high risk applications
US20060130144A1 (en) Protecting computing systems from unauthorized programs
US20070079364A1 (en) Directory-secured packages for authentication of software installation
US11886716B2 (en) System and method to secure a computer system by selective control of write access to a data storage medium
US20080114956A1 (en) System and method to secure a computer system by selective control of write access to a data storage medium
US20230038774A1 (en) System, Method, and Apparatus for Smart Whitelisting/Blacklisting
US9037608B1 (en) Monitoring application behavior by detecting file access category changes
WO2008036833A2 (fr) Système et procédé permettant de sécuriser un système informatique par une commande sélective de l'accès en écriture à un support de stockage de données
Rabaiotti Counter intrusion software: Malware detection using structural and behavioural features and machine learning
Flynn Attacking and Defending Unix

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07842898

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase in:

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112 (1) EPC, EPO FORM 1205A DATED 12-08-2009

122 Ep: pct application non-entry in european phase

Ref document number: 07842898

Country of ref document: EP

Kind code of ref document: A2