Tracking of software executables that come from untrusted locations

A system and method for tracking content derived from unverified sources are described. A tracking application determines a file is untrusted when it is obtained from an unverified or untrusted source. Examples of unverified sources include remote servers accessed through a network and removable storage devices. The application marks the file as untrusted by inserting an identification of the file in a watchlist. A filter driver monitors I/O transactions and conveys information regarding file operations and corresponding processes to the tracking application. The filter driver detects a trusted process touches an untrusted file. The application marks the process as being untrusted. The filter driver detects the process subsequently touches another file. The application then marks this other file as untrusted.

BACKGROUND OF THE INVENTION

Field of the Invention

This invention relates to the field of computer security and, more particularly, to tracking content derived from unverified sources.

Description of the Related Art

Users of computing devices access information from multiple sources for a variety of reasons, such as performing business transactions, updating work flows and presentations, file sharing, communicating through one or more of email, intranet sites and social networking sites, and so forth. These multiple sources include Web pages hosted on remote Web servers and data on removable storage devices. These external types of sources lack a relatively high level of control for providing security as done for other internal sources, such as enterprise servers hosting Intranet content or applications received from a trusted manufacturer for installment. Accordingly, these external sources are not deemed trustworthy (i.e., they are “untrusted”) compared to the internal sources. The content retrieved from these external sources and stored on a user's computing device is deemed untrusted until the content is verified by one or more security applications. During the time period between retrieving and verifying through security applications, accesses of the content yet to be verified may create additional other untrusted and unverified content.

In view of the above, improved systems and methods for tracking content derived from untrusted sources are desired.

SUMMARY OF THE INVENTION

Systems and methods for tracking content derived from unverified sources are contemplated. A user's computing device receives content from many sources for storage. The sources include both trusted sources and untrusted sources. One example of an untrusted source is a remote Web server providing content from Web browsing download operations to be stored in a file system folder on the computing device. Another example of an untrusted source is a removable storage device also providing content to be stored in a file system folder on the computing device. Although in many cases the content is later verified by one or more security applications, for some period of time the content is untrusted.

While untrusted content is resident on the computing system, one or more other processes may access the untrusted content stored on the user's computing device. In some embodiments, content retrieved from an untrusted source may be in the form of an archive type file (e.g., a zip file, or otherwise). In various embodiments, one or more executable files are extracted from an archive file. During the accessing of the content, the processes copy the content, extract executable files and configuration files from the archive files within the content, transfer the executable files and configuration files, and/or execute the executable files with the configuration files. The processes are capable of creating copies of executable files extracted from the archive files. The copies are placed in at least one or more storage locations among the user's computing device, other computing devices, removable storage devices and so forth. Other processes are capable of accessing these copies and so on. While the executable files, and other data, are still unverified and are not blocked, these files may affect a variety of other processes accessing data from a variety of storage locations.

In various embodiments, the user's computing device includes a filter driver. In various embodiments, the filter driver comprises program code used to monitor one or more system folders accessible by the user's computing device. Therefore, the filter driver is capable of determining when new content is added to the monitored system folder or when content is accessed within the monitored system folder.

In various embodiments, a tracking application determines a particular file is untrusted based on determining the particular file was received from an untrusted source. In one example, the untrusted file is an archive file now stored on the user's computing device in a Web browser downloads system folder. In the example, the archive file is named “A.zip.” As this new content is obtained by the user's computing device, the filter driver adds an identification of the new content in a watchlist of untrusted content. One of a variety of data structures may be used to maintain such a watchlist.

The filter driver monitors when processes touch content that is included in the watchlist. A process is considered to touch another file when the process performs a read and/or write of the file. Continuing with the example, the filter driver determines a process resulting from execution of a given file, which is named unzip.exe that is not identified as being untrusted (e.g., does not have an untrusted indication in the watchlist). Therefore, the given file, unzip.exe, is deemed to be a trusted file. In other embodiments, the application deems the given file is a trusted file based on determining the given file is from a verified/trusted source such as a remote server within an enterprise or a verified and secure application. The filter driver detects that the process reads the untrusted archive file, A.zip, and creates other files. In this example, the other files include an executable file named A.exe and other data such as a configuration file named A.config.

The application determines that the process is associated with an untrusted executable file unzip.exe and has touched the files A.exe and A.config by creating them. In response, the application inserts indications of the files A.exe and A.config and the process running the file unzip.exe into the watchlist that indicate they are untrusted.

As trusted processes read from the untrusted files A.exe and A.config, any additional files created or modified by the process are also marked as untrusted. Indications of these created or modified files are inserted into the watchlist in addition to the process running the trusted file that created them. In some embodiments, the system protection mechanisms block functionality of untrusted executable files found by searching the watchlist and finding a hit. In other embodiments, the system protection mechanisms block functionality of any executable file stored within a location with a corresponding indication found in the watchlist.

These and other embodiments will be appreciated upon reference to the following description and accompanying drawings.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth to provide a thorough understanding of the present invention. However, one having ordinary skill in the art should recognize that the invention might be practiced without these specific details. In some instances, well-known circuits, structures, signals, computer program instruction, and techniques have not been shown in detail to avoid obscuring the present invention.

Referring toFIG. 1, a generalized diagram of one embodiment of a node graph for tracking content derived from unverified sources is shown. In the embodiment shown, a sequence of time steps t1to t7are shown where both trusted files and untrusted files are accessed. There are two processes indicated as Process1and Process2inFIG. 1The hardware and software components, such as processing units, buses, interfaces, operating systems and so forth, used to execute the processes and access the files are not shown for ease of illustration. A description of the hardware and software components follows at a later time.

At time t1, the File1is received or otherwise obtained from the Untrusted Source and stored in Location1by Process0. In various embodiments, the Untrusted Source is a source of content that has not been verified or known to have been verified. Examples of unverified sources include removable storage devices and remote servers accessed through a network. In some embodiments, the remote servers are Web servers accessed through the Internet. Verification is done by one or more security applications and/or by a system administrator installing content on particular servers. Some remote servers are verified servers, such as servers within a private network, which is made accessible only to members of a particular organization. An Intranet is one example of the private network.

In some embodiments File1is an archive file, though it could be any type of file. After being received, File1is stored in system memory on a user's computing device. Examples of a computing device are a laptop, a smartphone, a tablet computer, a desktop computer, or otherwise. File1is marked as untrusted as it was obtained from an untrusted source. File1is shown as marked with “U,” which indicates untrusted. Prior to being created, File1did not exist, so the indication “I” for invalid is used (for purposes of illustration) to indicate that File1did not previously exist. In various embodiments of the data structure/database, such an “invalid” indication to indicate the file did not previously exist is not used.

In various embodiments, a watchlist (e.g., data structure or database) of untrusted content is maintained. In the example ofFIG. 1, the watchlist is a node graph. The first node shown, Node1, is inserted in the watchlist at time t1. Node1is shown to include an identification of File1and its storage location “L1,” which indicates Location1. In various embodiments, other information used to describe File1is stored in Node1but not shown for ease of illustration. In some embodiments, as Process® touches the untrusted File1by performing a store operation, an indication of “Edge0” is inserted in the watchlist node graph with information indicating Process® connects, or is otherwise associated with, the Untrusted Source and File1. In various embodiments, the indication includes at least a process identifier (ID) for Process0.

At a later time, a processing unit executes trusted File2which spawns Process1. File2is shown as marked with “T,” which indicates trusted. In some embodiments, the processing unit is within the user's computing device. In other embodiments, the processing unit is within a remote computing device and communicates with the user's computing device through a network connection. In one example, File2is a trusted executable file used for accessing archive files and File1is an untrusted archive file.

At time t2, Process1then touches the untrusted File1by performing a read operation targeting File1. A process is considered to touch a file when the process performs a read and/or write of the file. A lookup into the watchlist provides a hit for File1as Node1is present and corresponds to File1. In some embodiments, an indication is stored indicating the trusted Process1touched the untrusted File1and now Process1is untrusted. In some embodiments, the indication remains stored until Process1completes. However, as it is possible for a given process to run for a relatively long period of time, in some embodiments time limit is established for the indication to remain. In various embodiments, the selection is made by a system administrator. When the given time limit is reached, the indication is removed.

At time t3, Process1touches File3stored in Location2. For example, if File1is an archive file, then File3may represent a file extracted from the archive. The extracted file is then written by Process1to Location2(L2). In this scenario, the untrusted archive file, File1, is read by Process1which causes Process1to become untrusted. As Process1has now created File3, the new File3is considered untrusted and an indication to this effect is stored. File3is shown as marked with “U” inFIG. 1which indicates untrusted. Prior to being created, File3did not exist, so the indication “I” for invalid is used to indicate File3did not previously exist. Similar to the insertions steps for File1, a node corresponding to File3is inserted in the watchlist at time t3.

It is noted that in various embodiments, the insertion steps for nodes in the watchlist occur after a corresponding touching operation completes. In other embodiments, the insertion steps occur during the touching operation, but the nodes are removed should the touching operation end without completion. In this example, Node2is inserted in the watchlist at time t3. Node2is shown to include at least an indication of File3and its storage location “L2,” which indicates Location2. In various embodiments, other information used to describe File3is stored in Node2but not shown for ease of illustration. Additionally, an indication of “Edge1-2” is inserted in the watchlist node graph with information indicating Process1connects, or is otherwise associated with, Node1and Node2. In various embodiments, the indication includes at least a process identifier (ID) for Process1.

At some point in time, a processing unit initiates Process2by executing trusted File4. As File4is trusted, Process2is likewise trusted. In some embodiments, the processing unit processing Process2is the same processing unit processing Process1. In other embodiments, the processing unit processing Process2is a different processing unit. At time t4, Process2touches the untrusted File3by reading from File3. A lookup into the watchlist provides a hit for File3as Node2is present and corresponds to File3. As a result of touching untrusted File3, Process2is updated from being trusted to being untrusted. In some embodiments, an indication is stored indicating the Process2touches the untrusted File3.

At time t5, the untrusted Process2touches File5stored in Location3. In one example, Process2creates File5after reading File3. As the earlier stored indication still remains indicating Process2is untrusted, File5which his created by Process2is also marked as untrusted. File5is shown as marked with “U,” which indicates untrusted. Prior to being created, File5did not exist, so the indication “I” for invalid is used to indicate File5did not previously exist.

Similar to the insertions steps for File1and File3, a node corresponding to File5is inserted in the watchlist at time t5. Node3is inserted in the watchlist at time t5. Node3is shown to include at least an indication of File5and its storage location “L3,” which indicates Location3. Additionally, an indication of “Edge2-3” is inserted in the watchlist node graph with information indicating Process2is associated with Node2and Node3. In various embodiments, the indication includes at least a process ID for Process2.

At time t6, the untrusted Process2touches the trusted File6by reading from File6. A lookup into the watchlist provides a hit for Process2. In this case, as Process2performed a read of File6and did not write to or modify File6, the state of File6remains trusted.

At a later time t7, during execution of Process2, Process2touches File7by creating File7. A lookup into the watchlist provides a hit for Process2as being untrusted. Consequently, File7is deemed untrusted and File7is shown as marked with “U”. Prior to being created, File7did not exist, so the indication “I” for invalid is used to indicate File7did not previously exist. Node4is inserted in the watchlist at time t7. Node4is shown to include at least an indication of File7and its storage location “L4,” which indicates Location4. Similar to other inserted nodes, other information used to describe File7is stored in Node4but it is not shown for ease of illustration. Additionally, an indication of “Edge6” is inserted in the watchlist node graph with information indicating Process2is associated with File6and Node5. In various embodiments, the indication includes at least a process ID for Process2.

Turning now toFIG. 2, a generalized diagram illustrating one embodiment of a computing system200is shown. In the illustrated embodiment, the computing system200includes a public network240and a private network250, which is part of an organizational center. Computing devices210and260are shown connected to each of the networks240and250. Each of the networks240and250is additionally accessed by servers242and252, respectively. Although two computing devices210and260in addition to two servers242and252are shown, in various embodiments, the computing system200includes any number of computing devices and servers. Each of the computing devices210and260is representative of a variety of computing devices such as a desktop computer, a laptop, a smartphone, a tablet computer, or otherwise.

In various embodiments, the private network250within an organizational center is an intranet network providing a network accessible only to members of a particular organization. An intranet portal may be used to provide access to resources with a user-friendly interface such as graphical user interfaces (GUIs) and dashboards. In some embodiments, the organizational center housing the private network250is supported by software such as Microsoft SharePoint, Huddle, and Google for Work, and so forth.

Information and services stored on server252are made available by the private network250to particular members and are unavailable to the general public through direct access. For example, persons could not use the Internet to directly access the information and services provided by the private network250. Through user authentication, staff members are able to access resources through the private network250to communicate with other staff members, collaborate on projects and monitor product development, update products, documents and tools stored in a centralized repository and so forth. The private network250includes one or more web portals, search engines, tools for data visualization and so forth.

The server252is representative of a variety of server types such as database servers, computing servers, application servers, file servers, mail servers and so on. In various embodiments, the server252and the computing devices210and260operate with a client-server architectural model. In various embodiments, the content stored on server252is considered secure as verification is done by one or more security applications and/or by a system administrator installing content prior to the content is made available through the private network250. In various embodiments, the organizational center also supports an extranet network (not shown) which allows customers, partners, and suppliers to securely access a selected portion of the resources available within the private network250.

The computing device210additionally communicates and transfers information with the server242via the public network240. The connections between the computing device210and the remote server242include at least the Internet, wherein each of the computing device210and the remote server242use the Hypertext Transfer Protocol (HTTP) to transfer messages. Accordingly, in various embodiments, the public network240is the Internet. Multiple routers, switches, network cables, wireless technologies and so forth may be used in the public network240to transfer messages and content between the computing device210and the server242.

In various embodiments, the content stored on server242is not considered secure as it is unknown whether verification has been performed at all let alone by a system administrator, a user or other. Therefore, the server242is considered to be an unverified source, whereas the server252is considered to be a verified source. The removable devices230include any of a variety of removable storage devices such as portable hard disk drives, portable Flash drives, smartphones, and so forth. Similar to the remote public server242, it is unknown whether verification has been performed at all let alone by a system administrator, a user or another trusted user on the content stored on the removable devices230. Therefore, any storage device among the removable storage devices230is considered to be an unverified source like the public server242. Other examples of unverified sources are possible and contemplated.

As shown, the computing device210includes the Web browser226for accessing content on the server242through the public network240. The Web browser226is representative of a number of available World Wide Web browsers such as at least Internet Explorer, Firefox, Google Chrome and Safari. In various embodiments, the Web browser226uses a graphical user interface (GUI) to receive instructions and to present a rendered Web page to the user. In order for a user to access content stored on the public remote server242, the computing device210receives an indication from the user to access the content and retrieves the content. The content includes one or more of a Web page and files such as executable files, configuration files and so forth. The computing device210includes the network interface214for transferring information through the public network240. In some embodiments, the computing device210includes other software and another network interface for transferring information through the private network250. Each of the network interface214and any other network interfaces support one or more communication protocols for data and message transfers.

As shown, the computing device210includes a processing unit212. In various embodiments, the processing unit212includes one or more processor cores within one or more processors. Each of the processor cores include circuitry for executing instructions according to a predefined general-purpose instruction set architecture (ISA). For example, the SPARC® instruction set architecture (ISA) may be selected. Alternatively, the x86, x86-64®, Alpha®, PowerPC®, MIPS®, PA-RISC®, or any other ISA may be selected. In other embodiments, the computing device210includes a system-on-a-chip (SOC) with one or more processors utilizing very wide single instruction multiple data (SIMD) architectures to achieve high throughput in highly data parallel applications. In such embodiments, the computing device210includes one or more of a graphics processing unit (GPU), a digital signal processor (DSP), and the like.

As shown, the computing device210includes several software components216-226. The computing device210additionally includes one or more software applications and files (not shown). In some embodiments, one or more of the software components are paged in and out of a main memory in a conventional manner from a storage medium such as a hard drive (not shown). The operating system220within the computing device210is a Mac OS X operating system, a Microsoft Windows operating system, a Unix-like operating system, a mobile device operating system, or a combination wherein a hard disk is partitioned to host multiple operating systems. The operating system220controls the physical resources of the computing device210, such as allocation of the physical resources and management of external storage such as the removable devices230.

The computing device210also includes one or more device drivers224and input/output (I/O) drivers and I/O APIs218. The drivers218and224provide access to a variety of storage devices and support the corresponding data transfer protocols. In some embodiments, the computing device210uses the file system216to provide a special-purpose database for the storage, organization, manipulation, and retrieval of data. In some embodiments, file system216provides access to data by operating as a client for a network protocol. In other embodiments, file system216is virtual and exists only as an access method for virtual data. In some embodiments, the computing device210supports more file systems other than file system216. The computing device210is capable of supporting multiple file system formats.

In various embodiments, the file system216supports data organization which includes a hierarchy of directories and folders within the directories. The directories and folders store data as files. The files include executable files, text files, configuration files, library files and so forth. File system216stores information corresponding to the organization of the files. The organization information includes the storage locations used for storing the files. For example, in various embodiments, the organization information identifies the particular storage device as well as the directory and folders used to store the file. Additionally, file system216stores other information corresponding to the files such as a file name, a file extension indicating a file type, a file size, file ownership, file access permissions, a timestamp and so on.

The computing device210also includes the filter driver222configured to monitor I/O operations including reads and writes of data and processes associated with such I/O operations. Also included is a tracking application270configured to supports a watchlist of untrusted files and processes. In some embodiments, the watchlist is a node based graph. In such embodiments, the nodes include indications of suspicious files. The suspicious files are also referred to as unverified files and untrusted files. In various embodiments, the indications of the untrusted files include one or more of file names, file extensions, and the particular storage devices as well as the directories and folders used to store the files. In some embodiments, the nodes of the watchlist graph also include a signature corresponding to the particular file qualified for insertion. In various embodiments, the signature is an output of one of a variety of hash functions. In some embodiments, the chosen hash function receives one or more of the parameters included in the node as inputs. In other embodiments, the content of the file is also used as an input to the chosen hash function. Also included in the watchlist may be an identification of processes (e.g., process IDs) that are of have become untrusted. In various embodiments, this watchlist data may be stored and maintained in the form of some data structure(s), a database, or any other suitable form on a storage device coupled to the computing system200. In various embodiments, the filter driver222communicates the monitored I/O activities to the tracking application270which then records and maintains corresponding information.

In various embodiments, the edges of the node graph include an indication of the process which touched the file causing the file to now be marked as suspicious. The edge also includes an indication of the trusted file within the process which touched the file having a corresponding node inserted in the graph. For example, when a trusted file, unzip.exe, is executed by a process, reads an untrusted file A.zip and creates the file A.exe, this created file A.exe has a corresponding node and edge inserted into the watchlist graph. In other embodiments, one of a variety of other data structures is used to maintain the watchlist of untrusted files. In various embodiments, the other data structures include records arranged in a different organization than the node graph, but the information within the records is similar to the information described above for the nodes and edges.

The filter driver222monitors operations sent to file system216. In response to detecting operations from running processes which retrieve new content to be controlled by file system216or touch files already controlled by file system216, the filter driver222conveys information (or otherwise makes such information available) to the tracking application270. The information is then used by the tracking application270to determine whether an indication corresponding to a given process and a given file should be inserted in the watchlist of untrusted content and/or whether any other changes to the watchlist are needed.

In various embodiments, the filter driver222determines a particular file is untrusted based on determining the particular file is received from an unverified source. In some embodiments, the unverified source is a remote Web server accessed through an Internet connection rather than a trusted remote server accessed through a secure Intranet. In other embodiments, the unverified source is a removable storage device. The filter driver222determines the source of the retrieved file is an unverified source, generates a corresponding node for the retrieved file, and inserts the node in the watchlist. As described earlier, the filter driver222also determines when a file is created by a trusted executable file in a running process which touched an untrusted file. In such cases, the filter driver222generates a corresponding node and edge for the created file, and inserts the node and the edge in the watchlist.

In various embodiments, the filter driver222detects file read operations, file write/modify operations, file store operations which include file create operations, file delete/remove operations, file copy operations and file rename operations. As described earlier, a process is considered to touch a first file when the process performs a read and/or write of the first file. In various embodiments, the computing system210includes multiple filter drivers rather than a single filter driver222. In some embodiments, a given filter driver is used for a given system folder within file system216.

Referring now toFIG. 3, a generalized block diagram of one embodiment of a method300for tracking content derived from unverified sources is shown. For purposes of discussion, the steps in this embodiment are shown in sequential order. However, some steps may occur in a different order than shown, some steps may be performed concurrently, some steps may be combined with other steps, and some steps may be absent in another embodiment.

One or more software applications are executed where multiple processes are generated and assigned to hardware resources. During execution of the processes, it is determined a given running trusted process touches an untrusted file (block302). As described earlier, in one example, during the execution of one or more processes, a trusted file, such as an executable file used for accessing an archive file, reads an untrusted archive file. The process is marked as untrusted and no longer trusted (block304).

It is determined the same running process subsequently touches another file (block306). For example, after the running and previously trusted process reads the untrusted archive file, the executable file in the running process, which is used for accessing archive files, creates at least one other file. As the running process is marked as untrusted, the file created by the running process is marked as untrusted (block308).

In one example, an archive file named A.zip is stored on the F: drive corresponding to a removable storage device. A process running on the user's computing device later runs an executable file named unzip.exe. During execution, the process spawned by executing the executable file unzip.exe reads the content in A.zip and creates an executable file named A_RunMe.exe on the /temp directory of the C: drive of the user's computing device. As the archive file A.zip was accessed from an unverified source, such as the F: drive, the resulting created file C:\temp\A_RunMe.exe, is marked as untrusted by having a corresponding entry/node/record inserted into a watchlist data structure. Additionally, the running process corresponding to unzip.exe that read the content in A.zip is also marked as untrusted.

A subsequent process reads the content in C:\temp\A_RunMe.exe and creates an executable file named C:\Test\A_Copy_RunMe.exe on the user's computing device. As this file was created from an untrusted file with a corresponding entry/record/node in the watchlist, the resulting created file C:\Test\A_Copy_RunMe.exe is also marked as untrusted by having a corresponding entry/node/record inserted into a watchlist data structure. Additionally, the running process which executed copy.exe to read the content in C:\temp\A_RunMe.exe is also marked as untrusted. In some examples, the process is a different process that read the content in A.zip and the watchlist is used to determine the created file C:\Test\A_Copy_RunMe.exe is to be marked as untrusted. In other examples, the process is the same process which read the content in A.zip and this determination is used to mark the created file C:\Test\A_Copy_RunMe.exe as untrusted.

Turning now toFIG. 4, a generalized block diagram of another embodiment of a method400for tracking content derived from unverified sources is shown. For purposes of discussion, the steps in this embodiment are shown in sequential order. However, some steps may occur in a different order than shown, some steps may be performed concurrently, some steps may be combined with other steps, and some steps may be absent in another embodiment.

A watchlist of untrusted entities (files, processes, storage devices, or otherwise) is maintained (block402). A node graph or a variety of other data structures is used to store and organize indications of untrusted files. It is then determined that a trusted process touches a second file with an indication stored in the watchlist that it is untrusted (block404). As a result of touching the untrusted file, the process is marked as being untrusted by inserting a corresponding indication in the watchlist (block406). The indication may include at least a process ID for the running process.

In some embodiments, the stored indication in the watchlist for the process remains until the process completes. However, as it is possible for a process to run for weeks or months, in other embodiments, a time limit may be established for the indication to remain. In various embodiments, the time limit is made by a system administrator. In other embodiments, the indication that the process is untrusted may remain for the life of the process. If the given time limit is reached (“yes” branch of conditional block410), then the indication is removed (block412).

If the given time limit is not reached (“no” branch of conditional block410), and it is determined the process touches a third file not found in the watchlist (“yes” branch of the conditional block414), then the third file is added to the watchlist of untrusted content (block416). In some embodiments, as previously discussed, a read of an existing file by an untrusted process will not cause the file to then become untrusted if it is currently trusted. A write to such a file would cause the file to then become untrusted. Monitoring of the files continues as files are accessed. In various embodiments, the watchlist is updated when data, such as files marked as untrusted, are deleted. Similar to a process completing (i.e., ceases to exist) and having an indication in the watchlist removed, an indication for the data is removed from the watchlist when it is detected the data is deleted. In various embodiments, system protection mechanisms block functionality of untrusted executable files found by searching the watchlist and finding a hit. In addition to the above, in various embodiments the watchlist may be updated responsive to a status of data or processes changing. For example, software designed to scan data for viruses or other malicious content may verify that particular data identified as being untrusted is safe. In such a case, an indication may be conveyed or otherwise made available to the tracking software to this effect. In response, the watchlist is updated to remove the particular data (e.g., file) from the watchlist. In some cases, other data identified in the watchlist may also be removed due to the particular data being removed. For example, a given file may be identified in the watchlist as untrusted because it was created by a process that touched the particular data. However, the verification that the particular data is safe may in turn remove the reason for marking the given file as being untrusted. Consequently, the given file may be removed from the watchlist. Similarly, processes may likewise be removed from the watchlist. In some embodiments, the watchlist may serve as a database that identifies items that need to be scanned by virus detection or other software. In such a case, the information in the watchlist may be made available to the virus detection software. These and other embodiments are possible and are contemplated.

Referring toFIG. 5, a generalized diagram of another embodiment of a node graph for tracking content derived from unverified sources is shown. Nodes, Edges and Processes used previously in the embodiment illustrated inFIG. 1are numbered identically. In the embodiment shown, a sequence of time steps t1to t8are shown where both trusted files and untrusted files are accessed. The sequence of time steps t1to t7are identical to the sequence previously described inFIG. 1.

At time t8, the untrusted Process2touches File8stored in Location4. In one example, Process2creates File8after reading File5stored in Location3. As the earlier stored indication still remains indicating Process2is untrusted and File5is untrusted, File8which his created by Process2is also marked as untrusted. File8is shown as marked with “U,” which indicates untrusted. Prior to being created, File8did not exist, so the indication “I” for invalid is used to indicate File8did not previously exist.

A node corresponding to File8is inserted in the watchlist at time t8. Node5is inserted in the watchlist at time t8. Node5is shown to include at least an indication of File8and its storage location “L4,” which indicates Location4. Additionally, an indication of “Edge3-5” is inserted in the watchlist node graph with information indicating Process2is associated with Node3and Node5. In various embodiments, the indication includes at least a process ID for Process2.

In various embodiments, weights are associated with one or more of the Nodes and Edges in the watchlist. The weights may be used to determine whether content is trusted or untrusted. The weights may depend on a variety of factors such as the source of content, the transaction type associated with content, the amount of data in the content, the content type, a number of Parent Nodes and Child Nodes were previously inserted in the watchlist and are used to create a given Child Node, and so on. When a weight of a given Node is above a threshold, the given Node may be determined to be untrusted. A further example is provided in Table600.

Turning now toFIG. 6, a generalized diagram of one embodiment of a table for tracking weights of nodes in a node graph tracking content derived from unverified sources is shown. In the embodiment shown, fields602-620are fields used in each entry of the table600. Although particular types of fields are shown and a particular order of storage is shown, in various other embodiments, other field types and a different order of storage are used to implement the table. In the embodiment shown, field602holds the parameter, such as a Node or Edge, for which a weight is being determined.

Fields604-606store the source and the corresponding weight, respectively, for the parameter. Fields608-610hold the data type and the corresponding weight, respectively, for the parameter. Fields612-614hold the data amount and the corresponding weight, respectively, for the parameter. Fields616-618hold the transaction type and the corresponding weight, respectively, for the parameter.

Field620holds the overall weight for the parameter. In various embodiments, the overall weight is product of the previous corresponding weights. In other embodiments, a different algorithm is used to combine the previous weights to determine the overall weight. In various embodiments, when the overall weight for a given Node is above a threshold, the given Node is considered to be untrusted. The threshold may be a programmable parameter. In some embodiments, a different threshold is used for different Nodes.

The illustrated embodiment uses the Nodes and Edges described earlier inFIG. 5. As shown, weights are used in the Edge entries corresponding to Processes. For these table entries, each of the source, the data amount and transaction type has a corresponding weight which contributes to the overall weight stored in the field620. In addition, weights are used in the Node entries corresponding to Files. For these table entries, each of the source and the data type has a corresponding weight which contributes to the overall weight stored in the field620. As the Processes read or write the data in the Files, other factors are already accounted for by using the corresponding Edge as a source.

In the illustrated embodiment, higher weights are used for untrusted sources, larger data amounts and file types corresponding to executables or archive files associated with modifying other files. For example, file extensions such as “.exe” and “.zip” used for executable file types and archive file types have higher weights. In the illustrated embodiment, a maximum weight value used is 1.0. However, a variety of other ranges for the weights are possible and contemplated.

In various embodiments, a number of Parent Nodes and Child Nodes which were previously inserted in the watchlist and are used to create a given Child Node affects the weight for the given Child Node. For example, the field606in the table entry for Node2uses the product 1.0×1.0×0.9. The operands in field606for this table entry uses the weight for Node1, Edge1-2and a coefficient of 0.8 to scale the weight based on Node2being the second consecutive Node created from the content stored in the Untrusted Source such as a removable storage device or Web downloaded content. In a similar manner, field606of the table entries for Node3and Node5use decreasing coefficients 0.8 and 0.7, respectively.

Again, a variety of table arrangements, use of weights and coefficients, and algorithms for generating overall weights other than the ones depicted in table600are possible and contemplated. In various embodiments, the above illustrated embodiments for methods and data structures may be used by a system administrator operating an integrated security strategy for an organizational center. An integrated security strategy monitors threat levels within the organizational center. For example, a security service may use one or more embodiments of the above methods and data structures to monitor content derived from unverified sources. The security service may also be used to deploy computing devices used as endpoints, manage software licenses across the organizational center and identify and reduce security vulnerabilities in the organizational center. The security service may be provided as hardware, a virtual appliance, a cloud-based service, or a combination thereof. Examples of the security service are Symantec Information Technology (IT) Management Suite, Microsoft's System Center Configuration Manager (SCCM), IBM's United Endpoint Management and Dell's Kace Appliance.

In various embodiments, many computing devices generate data access requests to be serviced by other computing devices. Examples of the computing devices are desktop computers, a variety of servers, and a variety of mobile computing devices. The access requests are transferred over one or more network connections. In various embodiments, the computing devices are used within an organizational center.

In various embodiments, the organizational center120utilizes an intranet network for providing data and services accessible only to members of a particular organization. An intranet portal may be used to provide access to resources with a user-friendly interface such as graphical user interfaces (GUIs) and dashboards. In some embodiments, the organizational center is supported by software such as Microsoft SharePoint, Huddle, and Google for Work, and so forth.

In various embodiments, program instructions of a software application are used to implement the methods and/or mechanisms previously described and are stored on a non-transitory computer readable storage medium. Numerous types of storage media are available. The storage medium is accessible by a computing system during use to provide the program instructions and accompanying data to the computing system for program execution. The computing system includes at least one or more memories and one or more processors configured to execute program instructions.