The present subject matter pertains to data control systems and more particularly to protection of data storage media.
The vast amount of computer system data typically resides on a computer's read/write data storage media. Such storage media commonly includes a computer hard disk. An operating system can be adept at maintaining the integrity of a computer system's hard disk data. However, operating systems can be manipulated by some software including computer viruses to over-write valuable data. Therefore, protecting a user's data is of paramount importance. Users demand integrity of their data.
Currently, internet applications and marketing web sites are becoming more aggressive in dealing with a user's hard drive data, unknown to the user. For example, links to an unwanted site can become forced onto the user's hard drive “favorites” lists. “Spy software” may be downloaded into a user's hard drive to monitor a user's habits and report the habits to an unauthorized link, again unknown to the user. Data mining is prevalent which attempts to gather a user's personal data, such as social security, credit card information and other highly personal information.
As hard disks and other readable/writeable memories grow in size, protecting the stored data becomes more important and valuable to users. These memories can be vulnerable to aggressive behavior or attacks from outside sources via remote software that can read or write a user's data.
As used herein the phrase “device” refers to any machine capable of connecting to a network and includes memory for storing data, including data received from the network and data to be delivered to the network. In an embodiment the network is the internet.
The data protection system 10 includes, among other things, a filter driver 20, a monitor application 50, a policy manager 55 associated with a policy application database 57, a log file 60 and, in some embodiments, a private file system 25.
Monitor application 50 interfaces with the user to allow input and output of information to operate the protection system to allow access to protected files and directories only to the applications attempting to gain access to them. In an embodiment, the monitor application is always running on the system to provide a user interface to the system and to respond to filter driver 20 when messages are to be sent to the user.
Policy manager 55 stores information or conditions input from the user to monitor application 50 relating to allowing or restricting access of particular applications to protected files or directories located in memory 40. In an embodiment, those inputs are stored in data base 57 for policy manager 55. In an embodiment, memory 45 is partitioned from memory 42. Memory 45 is controlled by operating system (OS) file control 30. File system control 25 controls access to a protected partition memory 45 of hard disk 40 via port driver 35. Similarly, OS file control 30 controls access to the unprotected partition 42 of mass memory 40 via port driver 35.
In some embodiments, memory or hard disk 40 does not require partitioning. Partitioning increases the protection provided by the methodology. As shown memory partitions 45 and 42 may be included in the same hard disk or memory 40. File system control 25 controls access to the protected partition memory 45 of hard disk 40 via port driver 35. Similarly, OS file control 30 controls access to the unprotected partition 42 of mass memory 40 via port driver 35. File system control 25 operates in a similar manner to OS file control 30 to locate various files and directories of data on memory 40. OS file control 30 may include a disk operating system, a read only memory operating system, a programmable read only memory and an electronically erasable read only memory.
In an embodiment, private file system control 25 operates in a similar manner to OS file control 30 to locate various files and directories of data on memory 40. OS file control 30, in some embodiments includes one or more of a disk operating system, a read only memory operating system, a programmable read only memory and an electronically erasable read only memory.
Filter driver 20 receives incoming requests from applications external to the device for access to the memory 40, since it “sits atop” OS file control 30 and routes information to it under control of policy manager 55. For requests to access non-protected memory 42, filter driver 20 sends the request 15 to OS file control 30. For requests 15 for access to the protected memory 45, filter driver 20 will obtain appropriate information from data base 57 of policy manager 55 to evaluate the request 15 to allow or deny access to the protected partition memory 45.
Log file 60 stores access requests 15 to various files and directories of memory 40. The user may interrogate the log file 60 in order to determine what accesses have been made or attempted to memory, so that a historical access to the data by various applications and entities may be monitored by the user. In one embodiment, such accesses may be to an access to a file and in other embodiment, the accesses may be to a directory. As mentioned throughout, use of a file includes a directory and use of a directory includes a file.
As an example, let us consider a situation in which a user sets-up a policy via monitor application 50 with policy manager 55 to control access to memory partition 45 for file request 15 made by an external application and received for the device by an internet browser, not shown. The access policy may be, for example, to allow access by the browser to the cache directory of memory partition 45, but restrict access to any other directory on partition 45 of hard disk 40.
If the browser attempted to write to the user's favorites directory, the user may receive a “pop-up” message on the display device, not shown, via monitor application 50. The “pop-up” message might indicate that the browser is attempting to write to the favorites directory and the user could be queried to determine whether the user wish to allow such access. Once the user responds via monitor application 50, filter driver 20 would handle the access request by the browser as directed by the user (allow or deny).
Filter driver 20 is on top of OS file control 30. Filter driver 20 receives incoming requests 15 for access to hard disk 40. Filter driver 20 scans the incoming requests 15 and determines the file name, the path, the name of the application making the access request and access type, either read or write. Filter driver then examiner the data base 57 of policy manager 55 and determines whether there are any access restrictions for this requesting application. If, in an embodiment, the policy of the user is to deny the access, filter driver 20 signals the monitor application 50 via policy manager 55 to ask the user how to proceed, as mentioned above. In another embodiment an access request that is to be denied as falling within the user's policy is denied without asking the user how to proceed. If the access request is allowed, filter driver 20 forwards the request to private file system control 25 for performing the read or write access.
Monitor application 50 has two main functions. First, monitor application 50 provides the user interface for input from the user. Second, monitor application 50 sends outputs to the user under direction from filter driver 20. In an embodiment such outputs request user input on how to proceed in various circumstances.
In the first function above, in an embodiment, the monitor application 50 allows the user to add application and associated policies to data base 57 of policy manager 55. Continuing with the example of an application accessing the device through a browser, the user in an embodiment selects the browser, or a particular application accessed by the browser, as a restricted application. In an embodiment, the user selects the directories to which the browser, or a particular application accessed by the browser, may have access. In an embodiment the user selects whether the browser, or a particular application accessed by the browser is to have certain accesses logged by log file 60.
In an embodiment, when an application and its associated restrictions are added to data base 57, a “finger print” of the images (a hashsum over the application), for example, is formed. In an embodiment, this hashsum can be saved in the data base 57 for protecting the integrity of the application.
In the second function, monitor application 50 may provide multiple levels of output to the user. For example, in an embodiment, a novice mode or an expert mode may be selected by the user. When the monitor application 50 receives an indication from the filter driver 20 that user interaction is required, it sends an appropriate communication seeking a user decision as to whether to allow or deny access to memory partition 45. Depending upon the user's selection, the monitor application 50 may update the policy stored in data base 57 via policy manager 55. In an embodiment, password protection is provided so that a user must input a password in order to affect a policy change or update.
In an embodiment, data base 57 stores one or more of a list of restricted applications, their associated restriction policies, default policies, a “finger print” of the application, and configuration information. In an embodiment, the data base 57 is stored in the protected memory partition 45 with “finger print” protection added to this file.
When an access request is received 82, block 84 is entered. In an embodiment, the filter driver 20 extracts from the access request: the target directory, the target file name, the requesting or calling application name, and an access type, read or write, block 84.
Next, filter driver obtains the data in data base 57 related to this application name. Filter driver 20 determines whether this application name has any restrictions associated with this access request, block 86. If there are no restrictions associated with the requesting application name, block 86 transfers control to block 88 via the NO path. If the file or directory is located on unprotected partition 42, filter driver passes the request on to OS file control 30. If the file or directory is to the protected partition 45, filter driver passes the request on to file system control 25. File system control interfaces with port driver 35 to perform the requested access. Then block 88 transfers control to the idle state 80 to wait 81 for the next access request.
If the filter driver detected a restriction associated with the requesting or calling application, block 86 transfers control to block 90 via the YES path. Block 90 determines whether the requesting or calling application is denied access to the particular file or directory. If the access is not denied, block 90 transfers control to block 88 via the NO path. Block 88 uses file system control 25 to perform the requested access, since there was some restriction associated with the requesting application as detected by block 86. Then block 88 transfers control to the idle state 80 to wait 81 for the next access request.
If the filter driver determines that this requesting or calling application is denied access to the particular file or directory block 90 transfers control to block 92 via the YES path. Filter driver 20 then indicates to monitor application 50 through policy manager 55 that a user messages should be displayed, do that the user may allow or confirm denial of the requested access, block 92. The user is queried, block 92.
When the user responds, block 92 transfers control to block 94. Block 94 determines whether the user has allowed the access request. If the user input allowed the access request, block 94 transfers to block 88 via the YES path. Block 88 uses file system control 25 to perform the requested access, since the user allowed the requested access. Then block 88 transfers control to the idle state 80 to wait 81 for the next access request. When the user input is received the policy manager 55 can consider updating the data base 57.
If the user denied the requested access, block 94 transfers control to block 96 via the NO path. Block 96 indicates that the access request, read or write, has failed to the requesting or calling application. Then block 96 transfers control to the idle state 80 to wait 81 for the next access request.
As can be seen from the above explanation, the subject methodology provides a user with the ability to protect certain files and directories and data from read or write access by entities which may attempt such accesses without prior knowledge of the user.
The description and the drawings illustrate specific embodiments of the invention sufficiently to enable those skilled in the art to practice it. Examples merely typify possible variations. Portions and features of some embodiments may be included in or substituted for those of others.
Although some embodiments of the invention have been illustrated, and those forms described in detail, it will be readily apparent to those skilled in the art that various modifications may be made therein without departing from the spirit of these embodiments or from the scope of the appended claims.