|Publication number||US8161014 B1|
|Application number||US 11/689,417|
|Publication date||Apr 17, 2012|
|Filing date||Mar 21, 2007|
|Priority date||Mar 21, 2007|
|Publication number||11689417, 689417, US 8161014 B1, US 8161014B1, US-B1-8161014, US8161014 B1, US8161014B1|
|Inventors||Eugene Bradley Allen|
|Original Assignee||ByStorm Software, LLC|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (6), Referenced by (4), Classifications (6), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application claims the benefit of U.S. Provisional Application No. 60/775,376, filed Mar. 21, 2006.
The present invention relates to tracking user access to file in a computer file system including file auditing and security in a computer file system such as the Windows 2000 based operating systems.
For a further understanding of the nature and objects of the present invention, reference should be had to the following detailed description, taken in conjunction with the accompanying drawings, in which like elements are given the same or analogous reference numbers.
There is a need to efficiently and effectively implement rules for accessing files in a computer file system and to audit and track the operations by users on files in a computer file system. Rules for accessing, auditing and tracking files use sets of information. Preferably, the information includes who is or seeks to operate on a file, which file or object is being operated upon, and what operation is being or is attempting to be performed on the file or object. The auditing and tracking would also include when did all of this occur. Furthermore, within these sets are multiple attributes that can also serve to expand or limit the rule.
As used herein “Auditing” or “audit” means the recording of information related to a request to access an object in a computer system.
“Track” or “tracking” means the recording and displaying of information related to a request to access an object in a computer system.
“Object” as used herein means any type of computer resource or peripheral that can be accessed by a user or an application being executed. Examples of objects or files in a file system, printers, scanners, etc.
“Venn Relationship” as used herein means the intersection if any between the sets of information used to define a rule.
The sets of information described herein can be operated on using set type operations or abstractly applying Venn Diagrams to determine Venn relationships which are used to identify whether a given attribute or element is found within the intersection of all sets thereby passing the rule. Venn diagrams are geometric figures used to illustrate sets and set relations. Generally, a rectangle is used to represent the universal set, and circles are used to represent subsets of the universal set. Venn diagrams are useful for illustrating set operations like “OR”, “AND”, or “NOT”.
For example the entire computer file system, all users, all files and all of the operations that are available, is the universal set at a given time. Then a set of files can be defined as all Excel™ spreadsheet files, a set of operations can be defined as all file writes and a set of users can be defined as all users with a name starting with “G”. The Venn diagram that would show the intersection of all three sets would be written as “all users with a name starting with the letter “G” doing a file write on any Excel™ spreadsheet file”.
Using Venn relationships and the description of such relationships enables operations on large sets of data because inclusion in the set is based on an attribute of the set member. This enables “atomic on-demand” checks like a security check on a certain file or whether a certain operation should be audited or not. Because any set member can be identified by an attribute, rules are not limited to file names or user names. Rather any attribute of a file can be used, such as date of creation, location, file type, size, etc. Attributes other than a user name can also be used and would only be limited by the attributes and information collected and available in a computer system. The larger the user profile the more attributes that are available to be used in the rule making. It is the same for any object in the system that has attributes.
A rule must be defined such that it will result in showing inclusion or exclusion from a set. File names and the like can be described using the common wildcard symbols “*” and “?”. For example the “*” represents 0 or more characters and “?” represents a single character from a set of characters.
In a preferred embodiment according to the invention, all computer file accesses are intercepted or hooked by a process executing on the computer so that each file access can be tested against the defined rule models.
Here is an example of a set of attributes that can be used in testing for inclusion in a set:
In a preferred embodiment according to the invention as set forth in
By utilizing the IFS, Independent Software Vendors are able to write software that can intercept and operate on file data before or after the hardware receives it such as ByStorm Filter Driver 12. For example, a virus scanner intercepts all file reads and scans the contents for viruses before allowing the requesting application to receive it. An on-the-fly encryption package will intercept file READs after the operating system has read the data, intercepting the file WRITE BEFORE the operating system has written it. This is encrypting on the WRITE command and decrypting on the READ.
In a preferred embodiment according to the invention, file operations are intercepted by filter driver 12 before the file system 11 receives them. Thereafter, WHAT file or object is being operated on which is a member of Venn relationship set 13; WHO is asking for the operation to be performed which is a member of set Venn relationship set 15; and the operation that is being performed (WHY) which is member of Venn relationship set 14; is determined. The Security Engine 16 tests the information against each Venn Relationship Rules Model 21 to determine if it is found within the intersection 22 of the Venn Relationship sets 13, 14, and 15. If it is found within the intersection 22, then the file request will be denied by the Security Engine 16 and the Filter Driver 12 will not pass the request to the file system 11.
In a preferred embodiment according to the system, each request 23 is also passed to the Auditing Engine 17 which maintains a set of Venn Relationship Rules for determining whether a request 23 should be audited and recorded in the audit trail 18. The Auditing Engine 17 tests the request 23 against each Audit Venn Relationship Rules Model 21 to determine if it is found within the intersection 22 of the Audit Venn Relationship sets 13, 14, and 15. If it is found within the intersection 22, then the file request will be audited and information relating to the file access including the user making the request, the file being accessed, the type of access, and the date and time will be recorded and logged in the File Audit Trail 18.
Because each file access request is being intercepted, stability and performance is an issue that needs to be addressed. In the preferred embodiment part of the system is using the Installable File System mechanism within Windows 2000, which means that it will be considered as part of the operating system. Of all the Windows sub-systems to HOOK into, the file system can be risky.
Nearly every task performed in the Windows™ operating system requires a file access. To mitigate against crashing the operating system, in a preferred embodiment the application is divided into a module that hooks into the operating system to intercept the file system access requests a module that runs as a service or as a user level process to perform some of the tasks and a user level console that is used to create rules and interface with service module.
Performance in a normal operating environment is also an issue. Operating system such as Windows™ continually access files in order to maintain the executing processes. In other words, nearly everything that happens in Windows™ uses a file and uses them often.
If the computer system intercepts every call to the file system and the executing module involved does not perform well, the entire system will begin to run much less efficiently. For example, if a million file accesses were delayed as little as a 0.25 seconds, these million files accessed would take 250,000 extra seconds. 250,000 seconds is almost 3 days.
To address both stability and performance according to the invention, in a preferred embodiment, the modules are divided into two executing modules.
In the file system “hook” code also known as the Filter Driver, that runs as part of the Operating System:
In a preferred embodiment under a Windows™ based operating system, the User level module executes as a Windows™ service, the “Service, that waits and processes intercepted file requests. In a preferred embodiment according to the invention, the User level module:
In a preferred embodiment, the Filter Driver intercepts each file request and sends it to the Service. It then waits for the Service to process it and return whether or not the Filter driver should allow or deny the file request. For performance enhancement only security rules are handled in real time. Therefore, only the rules which will deny a request are tested. The request is packaged and put into an auditing queue for processing during computer system idle time.
The Service “listens” for incoming raw file requests coming from the Filter driver. When a file request the execution and information flow as follows:
By keeping this “listening” code compact and minimal, the system according to the invention can keep the computer operating at close to maximum efficiency. The preferred embodiment pushes off the actual non-real time (e.g. auditing) processing to be handled at a less critical time, such as when the filter driver is NOT waiting on either the user or the program itself to allow it to continue.
In a multi-threaded computer operating system such as Windows 2000™ based system, the Service is also running several threads allowing it to perform other tasks concurrently with servicing requests from the Filter Driver. The following is an example of threads used within the Service within a preferred embodiment:
1.) Multiple threads are created to process incoming requests from the Filter driver adding the file requests to an internal queue;
2.) A thread is created to process the raw file requested added by the multiple file requests threads
3.) 1 low-priority thread is created to gather group membership from a configured domain; and
4.) 1 low-priority thread is created to generate a “heart-beat” pulse to the event log if enabled. The purpose of a heart-beat pulse is to record that the service is running. It is a security measure to inhibit the stopping of the service in order to do things without being audited.
In a preferred embodiment according to the invention the system is made up of 3 modules.
The first module is the File System Filter driver which is based on the Windows Installable File System features of Windows 2000™ based computer operating systems. The File System Filter Driver hooks into the Windows File system and intercepts all file operations. Many file operations are ignored, this preferred embodiment according to the invention checks for the following operations:
1. IRP_MJ_CREATE (for file and folder opens/creates);
2. IRP_MJ_READ (for file reads);
3. IRP_MJ_WRITES (for file writes);
4. IRP_MJ_SET_SECURITY (for file security changes);
5. IRP_MJ_SET_INFORMATION (for file and folder renames);
6. IRP_MJ_CLEANUP (for file deletes);
Information about these operations is packaged up and sent to the Windows Service for processing. For the 6 operations above, we “send” the package in the “Pre” completion routine except for IRP_MJ_CREATE and the IRP_MJ_SET_SECURITY with are sent in both the “Pre” and the “Post” completion routine. For each file operation, the following information is sent to the Windows Service
1. A “SentFromPreOperation” Boolean Flag;
2. The IRPflags from the file operation;
3. The Major and Minor file operation codes;
4. The Operation Flags;
5. The File Name;
6. The Volume Name;
7. The Share Name;
8. The File Extension;
9. The Stream Name;
10. The Final Component;
11. The Parent Directory;
12. The SID of the user performing the operation
For impersonating routines, the SID is obtained via the SubjectContextToken. If that fails, it is attempted via the thread token. If that fails, it is finally attempted via the process token. If the SID was not gathered, the package is not sent.
13. The LockOperation;
14. The DeletePending flag;
15. The CancelDeletePending flag;
16. The Read/Write/Delete Access flags;
17. For IRP_MJ_CREATE operations, the Create options;
18. For File Renames operation, the Rename To Filename;
19. A flag for if the operation is on a file or a folder;
20. A flag for whether the object (file or folder, etc.) was created;
21. A flag for whether the operation was denied by the operating system or not; and
22. The path to the program that was used to request the operation.
An internal table is maintained to keep track of which SID opened a file allowing the system to determine the SID in non-impersonated routines.
When the Filter Driver starts up, it registers itself with the Windows 2000 based Filter manager which includes registering which operations will be processed. The internal SID table is allocated and initialized. A communications port for communicating with the Windows™ service is created.
When the Service module connects to the Filter Driver, a Port connect occurs and the process ID of the Service module is recorded. When the Service module disconnects the process ID is zeroed out. When the Filter Driver is unloaded the communications port is closed, the SID table is De-Allocated and the Filter module is unregistered.
Each time an instance of the Filter Driver is setup, all mounted volumes must be attached.
When an access request is received, the Process ID of the current thread is compared to the process ID of the Service module. If they are the same then the request is allowed without further processing. The Service module is not checked to determine if it has access to files.
Otherwise, all necessary information is packaged and sent to the Service module. The Filter Driver module then waits for a reply from the Service module indicating whether or not the file request should be allowed or not. If the reply times out, then allow the request. If the reply comes back as false, then cancel the file operation. Only file operations IRP_MJ_CREATES, IRP_SET_INFORMATIONs and IRP_MJ_SET_SECURITYs can be cancelled.
The Service module runs as a local system process and listens, processes and responds to packages sent by the file system Filter driver. The Service module exposes a COM interface for configuration and interaction by the Console module. The Service module registers an event log source for writing events to the event log. Entries into the log are written for the following events: 1) Service State Changes, i.e. startup, shutdown, etc.); 2) on the heart-beat pulse; 3) changes to the rules module; 4) rule matches; 5) configuration changes; and 6) bad rule data being loaded. The Service incorporates a “heart-beat” pulse that writes to the event log on a regular basis. The Service implements the rules model for processing the packages received from the Filter Driver and implements a security module for configuration changes. Therefore, every entry point into the COM object does a SecurityCheck on the calling user SID to determine if the call should be allowed or denied. Security is based on the calling user being a member of a local group.
Upon startup the Service module loads configuration information, and creates an event that will be signaled when a StopService event is received. It then creates the COM object and registers it. It creates two critical sections one for the rules model and one for the raw requests list. It creates a raw requests list, builds a translation table from NT volume names to drive letter mappings, loads group membership thread configuration, and in a multi-threaded environment creates a thread for gathering domain group membership information. The Service loads the rule model and the filter driver, connects to the communications port created by the Filter driver and creates an I/O Completion Port to monitor for packages. In a multi-threaded environment, the Service module creates one or more threads, preferably 10, to monitor for packages from the Filter driver and a single thread used to wait on the 10 monitoring threads during shutdown and cleanup. The main processing thread is created. The Service module also creates the heartbeat thread. When a StopService event is signaled then the Service module shuts down the heartbeat thread, shuts down the processing thread, unloads the filter driver, shuts down the monitoring thread, signals monitoring threads to exit and wait for the shutdown cleanup thread to exit; cleans up the communications ports, I/O completion ports, etc., and then exits.
In a multi-threaded operating environment such as Windows 2000™ based systems, the Service modules creates multiple threads to handle processing according to the invention. One thread is used to generate the heart-beat pulse every certain number of seconds, if configured to do so. One thread is used to load domain group membership every certain number of seconds, if configured to do so. Ten threads are used to process packages sent via the Filter driver. The following illustrates the flow of those threads
One main processing thread used to take action upon the queued packages. Here is the flow of that thread:
1. Wait for a “file request” to be in the raw request list;
2. while the raw request is not empty
In a preferred embodiment, the Rule object has the following major methods—
In a preferred embodiment the major functions used in the Service module are
i. CHECKRULE receives as a parameters a rule, a filename and a user's SID and then goes through the following:
In a preferred embodiment according to the invention, a Console module is available to configure and create rules and to interact with the Service module. The console is a client application that runs under the context of the logged in user. There are 4 major dialogs in the console.
After the connection is successfully made, the console checks for a valid license and if successful, enters a running state. When the console is in a running state, service statistics are displayed on the main console screen and UI input for allowing access to the other 4 major dialogs.
In a preferred embodiment,
In a preferred embodiment,
In a preferred embodiment according to the invention,
In a preferred embodiment,
While the invention has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of this disclosure, will appreciate that other embodiments can be devised which do not depart from the scope of the invention as disclosed herein. Accordingly, the scope of the invention should be limited only by the attached claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6038563 *||Mar 25, 1998||Mar 14, 2000||Sun Microsystems, Inc.||System and method for restricting database access to managed object information using a permissions table that specifies access rights corresponding to user access rights to the managed objects|
|US6236996 *||Dec 16, 1999||May 22, 2001||Sun Microsystems, Inc.||System and method for restricting database access to managed object information using a permissions table that specifies access rights to the managed objects|
|US7032026 *||Jan 10, 2002||Apr 18, 2006||Oracle International Corp.||Method and apparatus to facilitate individual and global lockouts to network applications|
|US20040022390 *||Aug 2, 2002||Feb 5, 2004||Mcdonald Jeremy D.||System and method for data protection and secure sharing of information over a computer network|
|US20040039741 *||Aug 22, 2003||Feb 26, 2004||Greg Benson||Method and system for managing a data object so as to comply with predetermined conditions for usage|
|US20040236747 *||Mar 3, 2004||Nov 25, 2004||Swimmer Morton G.||Data processing systems|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8392379 *||Mar 5, 2013||Sophos Plc||Method and system for preemptive scanning of computer files|
|US8452740 *||May 28, 2013||Softcamp Co., Ltd.||Method and system for security of file input and output of application programs|
|US20100242109 *||Mar 17, 2009||Sep 23, 2010||Lee Graham J||Method and system for preemptive scanning of computer files|
|US20110231378 *||Sep 22, 2011||Yang Jin Seo||Method and system for security of file input and output of application programs|
|U.S. Classification||707/694, 707/785|
|International Classification||G06F7/00, G06F17/00, G06F17/30|
|Nov 27, 2015||REMI||Maintenance fee reminder mailed|
|Apr 4, 2016||FPAY||Fee payment|
Year of fee payment: 4
|Apr 4, 2016||SULP||Surcharge for late payment|