Patent ID: 12229258

DETAILED DESCRIPTION

Reference will now be made in detail to the presently preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. Throughout the following detailed description, the same reference numerals refer to the same elements in all figures.

In general, a whitelist/blacklist-based computer security system provides an automated way to prevent execution of software containing code that is potentially contaminated (e.g., contains or is malicious software). Before execution of any code on the target computer system, a test is performed by checking one or more whitelists and/or blacklists to determine if the code has been enabled for execution (whitelist) or prevented from execution (blacklist) on the target computer system and, if the code is on the blacklist, execution of the code is blocked unless an entry in a whitelist permits execution of the code. It is fully anticipated that there be multiple blacklists and whitelists, for example, a global blacklist, a global whitelist, a company whitelist and/or blacklist, a department-wide whitelist and/or blacklist, a local blacklist, and a local whitelist. Further, any form and location of storage of the blacklist(s) and whitelist(s) are anticipated, including local memory.

Throughout this description, the term, “computer” refers to any system that has a processor and runs software. Examples of such are: a personal computer, a server, a notebook computer, a tablet computer, a smartphone, a smart watch, a smart television, etc. The term, “user” refers to a human that has an interest in the computer, perhaps a person (user) who is using the computer.

Throughout this description, the term “directory” or “directory path” describes a hierarchical pathway to a particular folder in which files (e.g., data or programs) are stored. For example, “C:/windows/system32” refers to files stored in a folder called “system32” which is a subfolder of another folder called “windows” which is a top-level folder of a storage device known as “C.” Note that the storage device (e.g., C:) is at times a physical device (e.g., a separate disk drive) or a logical device (e.g., a portion of a disk drive). Also note that the described representation (e.g., “C:/windows/system32”) is a human-readable representation of such hierarchy used by certain operating systems and any such representation is anticipated and included herein (e.g., some representations use backslashes instead of slashes).

Throughout this description, the term, “malicious software” or “malware” refers to any software having ill-intent. Many forms of malicious software are known; some that destroy data on the host computer; some that capture information such as account numbers, passwords, etc.; some that fish for information (phishing), pretending to be a known entity to fool the user into providing information such as bank account numbers; some encrypt data on the computer and hold the data at ransom, etc. A computer virus is a form of malicious software.

In general, the system, method, and apparatus being described utilizes efficient storage and retrieval mechanisms to determine if a program (e.g., an executable, macro, form, etc.) is identified within a list, either a whitelist or a blacklist. A hash table is one such mechanism, though other mechanisms are equally anticipated and included here within. As an efficient way of characterizing the questionable program, in some embodiments, it is anticipated that rather than storing the entire program in such tables, a portion of the program is stored, often referred to as a signature of the program. For example, the signature contains key sequences found within the program; finding of such key sequences typically indicates that the program matches the signature or a hash value of the program.

Referring toFIG.1illustrates a data connection diagram of the exemplary computer security system for managing whitelists and blacklist. In this example, a target computer10(e.g., a personal computer that is being protected) communicates through a network506(e.g., the Internet, local area network, etc.) to a server computer500.

The server computer500has access to data storage512. One item in the data storage512is a blacklist15and another is a whitelist19; for example, a blacklist15of programs/applications that are known to be of high risk of malware and, therefore, not allowed to execute while a whitelist19is a list of programs/applications that are known to be of low-risk of malware and, therefore, generally allowed to execute. In some embodiments, the data storage512is in the cloud. Although one path between the target computer10and the server computer500is shown going through the network506as shown, any known data path is anticipated. For example, the Wi-Fi transceiver96(seeFIG.2) of the target computer10is used to communicate with the wide area network506, which includes the Internet, and, consequently, with the server computer500.

The server computer500transacts with computer security system software that runs on the target computer10through the network(s)506. The computer security system software17runs on the target computer10and monitors any activation of programs/applications/scripts (e.g., running of a program) and provides or denies permission for running the program/application/script on the target computer10. The program/application/script is allowed to run when the programs/applications/scripts is deemed malware-free (e.g., is not in the blacklist15or is in the whitelist19). Information is also transferred from computer security system software17that runs on the target computer10to the server computer500regarding potential threats, etc.

The server computer500transacts with the computer security system software17that runs on the target computer10as needed, for example, to update the whitelist19and/or blacklists15stored on the target computer10.

The computer security system software17that runs on the target computer10selectively provides execution approval to software that attempts to execute on the target computer10. In such, if approval is provided, the software is able to execute on the target computer10. If approval is not provided, the software is blocked from executing on the target computer10and various additional steps are taken such as logging the attempt, transferring the suspect software to the server computer500for analysis, and informing the user of the target computer10, etc.

Referring toFIG.2, a schematic view of a typical target computer10is shown. The computer security system software17running on the target computer10executes on any processor-based device (e.g., target computer10) for providing protection against programs/applications/scripts that contain malicious software (malware). The present invention is in no way limited to any particular computer. Protection for many other processor-based devices are equally anticipated including, but not limited to smart phones, cellular phones, portable digital assistants, routers, thermostats, fitness devices, smart watches etc.

The example target computer10represents a typical device that is protected by computer security system software17that runs on the target computer10. This exemplary target computer10is shown in its simplest form. Different architectures are known that accomplish similar results in a similar fashion, and the present invention is not limited in any way to any particular computer system architecture or implementation. In this exemplary target computer10, a processor70executes or runs programs in a random-access memory75. The programs are generally stored within a persistent memory, storage12, and loaded into the random-access memory75when needed. The processor70is any processor, typically a processor designed for phones. The random-access memory75is interfaced to the processor by, for example, a memory bus72. The random-access memory75is any memory suitable for connection and operation with the selected processor70, such as SRAM, DRAM, SDRAM, RDRAM, DDR, DDR-2, etc. The storage12is any type, configuration, capacity of memory suitable for persistently storing data, for example, flash memory, read only memory, battery-backed memory, hard disk, etc. In some exemplary target computers10, the storage12is removable, in the form of a memory card of appropriate format such as SD (secure digital) cards, micro SD cards, compact flash, etc.

Also connected to the processor70is a system bus82for connecting to peripheral subsystems such as a cellular network interface80, a graphics adapter84and user I/O devices91such as mice, keyboards, touchscreens, etc. The graphics adapter84receives commands from the processor70and controls what is depicted on the display86. The user I/O devices91provides navigation and selection features.

In general, some portion of the storage12is used to store programs, executable code, and data, etc. In some embodiments, other data is stored in the storage12such as audio files, video files, text messages, etc.

The peripherals shown are examples, and other devices are known in the industry such as Global Positioning Subsystems, speakers, microphones, USB interfaces, cameras, microphones, Bluetooth transceivers, Wi-Fi transceivers96, image sensors, temperature sensors, etc., the details of which are not shown for brevity and clarity reasons.

In some embodiments, a network interface80connects the target computer10to the network506through any known or future protocol such as Ethernet, Wi-Fi, GSM, TDMA, LTE, etc., through a wired or wireless medium78. There is no limitation on the type of connection used. In such, the network interface80provides data and messaging connections between the target computer10and the server computer500through the network506.

Referring toFIG.3, a schematic view of a typical server computer system (e.g., server computer500) is shown. The example server computer500represents a typical server computer system used for back-end processing, generating reports, displaying data, etc. This exemplary server computer500is shown in its simplest form. Different architectures are known that accomplish similar results in a similar fashion and the present invention is not limited in any way to any particular computer system architecture or implementation. In this exemplary computer system, a processor570executes or runs programs in a random-access memory575. The programs are generally stored within a persistent memory574and loaded into the random-access memory575when needed. The processor570is any processor, typically a processor designed for computer systems with any number of core processing elements, etc. The random-access memory575is connected to the processor by, for example, a memory bus572. The random-access memory575is any memory suitable for connection and operation with the selected processor570, such as SRAM, DRAM, SDRAM, RDRAM, DDR, DDR-2, etc. The persistent memory574is any type, configuration, capacity of memory suitable for persistently storing data, for example, magnetic storage, flash memory, read only memory, battery-backed memory, magnetic memory, etc. The persistent memory574is typically interfaced to the processor570through a system bus582, or any other interface as known in the industry.

Also shown connected to the processor570through the system bus582is a network interface580(e.g., for connecting to a data network506), a graphics adapter584and a keyboard interface592(e.g., Universal Serial Bus—USB). The graphics adapter584receives commands from the processor570and controls what is depicted on a display586. The keyboard interface592provides navigation, data entry, and selection features.

In general, some portion of the persistent memory574is used to store programs, executable code, data, and other data, etc.

The peripherals are examples and other devices are known in the industry such as pointing devices, touch-screen interfaces, speakers, microphones, USB interfaces, Bluetooth transceivers, Wi-Fi transceivers, image sensors, temperature sensors, etc., the details of which are not shown for brevity and clarity reasons.

Referring toFIGS.4,5,6, and6B, user interfaces100,100A,100B of the computer security system for managing whitelists and blacklist are shown. Although many user interfaces are anticipated, one set of examples are shown for brevity reasons. The user interfaces100/100A that are shown represent that a program14is stored on the target computer10. There are many ways for this program14to be loaded and initiated on the target computer10, for example, through an email system, through a browser, through a forms interface, etc. The computer security system software17intercepts and processes all requests to initiate operation of any type of program.

One such program14is shown as an example in a user interface100ofFIG.4. A program14(e.g., a word processing program) is represented as an icon102on a display86. As with many windowing programs, a user typically selects the icon102, for example, double-clicking on the icon102, and the operating system and/or user interface software initiates execution of the program14on the target computer10. For example, in some operating systems, double clicking on a word processor icon initiates (runs) a word processing program that is associated with the word processor icon.

After the user selects the icon102(e.g., double clicking) and the operating system of the target computer10attempts to initiate/run the program14associated with the icon102, the computer security system software17analyzes the program14associated with the icon102and determines if the program14is contained in the whitelist19and/or blacklist15(seeFIG.7). If the program14associated with the icon102is listed in the whitelist19or is not listed in the blacklist15, the program14is deemed acceptable and is allowed to run. If the program14associated with the icon102is found in the blacklist15, it is assumed to have the potential to be/contain malware unless the program14is found in the whitelist19. Therefore, if the program14is found in the blacklist15, the program14is prevented from running and an error message105is displayed. Notification of an attempt to run the program14is made to an administrator of the target computer10, for example, a message is sent/displayed to the administrator or a record is added to a logfile either on the target computer10, the server computer500, or both. For the remainder of this description, the administrative software917will be described as running on the server computer500, though it is equally anticipated that the administrative software917runs on the target computer10or any device or any combination thereof.

Based upon user security settings and global information, the administrative software917will make intelligent decisions as to whether the program14associated with the icon102is dangerous based upon any of several factors, and if it is determined that the program14associated with the icon102is not dangerous, the administrative software917will add an entry to the whitelist19to allow future execution of the program14associated with the icon102. On the other hand, if it is determined that the program14associated with the icon102is dangerous, the administrative software917will add an entry to the blacklist15to prevent future execution of the program14associated with the icon102.

In the past, the administrator would review the log files or be presented with a user interface105A as shown inFIG.6A. The user interface105A includes a message window that describes the program14that was attempted to be executed, the location where the program14was attempted to be executed, other information regarding the program14and selection icons107/109. In the prior art, the administrator had the ability to either allow107or deny109future executions of the program14(e.g., either add the program14to the blacklist15, add the program to the whitelist19, or not add the program14to either the blacklist15or the whitelist19).

Instead of a simple allow/deny, the administrator user interface105A, enhanced tools are provided to the administrator to reduce frustrations of users of the target computers10by applying heuristics and historical data to the event (the attempted execution) and to present alternatives that will allow future executions of, not only the program14, but of other programs that, by nature of the program14, are likely to be benign. The program14and other programs form a program classification or a group of programs that have in common a folder in which they are stored, a certification, an origin company, etc. For example, when a software suite such as an office suite is installed into a folder, initially all programs in that folder are not in the blacklist15and execution of each is allowed. When such program attempts to run (e.g., a word processor), it is allowed unless an administrator removes the program from the whitelist19or adds the program to the blacklist15. If the administrator removes the program from the blacklist15, malware pretending to be that program are also allowed to execute. If the administrator recognizes that the program is part of an installed package, the administrator can add an entry to the whitelist19, for example, the classification of all programs running from the same directory or the classification of all programs sharing the digital signature of the word processor. This would allow a program that matches an entry in the blacklist15to run if that program is being run out of the cited directory or if that program is in the same classification (e.g., same digital certificate).

An enhanced administrative interface105B is shown inFIG.6B, providing a directive to allow a class of programs14to run that reside in the same directory or file folder.

For example, if a user is using a tax preparation software package, every time the user starts that tax preparation software package, the tax preparation software package checks for updates as tax laws change daily, downloads new software, and the tax preparation software package restarts. If a virus masquerading as the tax preparation software package is discovered, the tax preparation software package added the blacklist15and any legitimate copies of the tax preparation software package would not be allowed to run. Instead, given the history and execution environment of the tax preparation software package, an analysis is made by heuristics and, based upon acquired intelligence and history, it is recommended that the administrator allow execution of the tax preparation software package based upon the directory or folder from which it is executed (e.g., “C:/program files/mytax2022”). In this way, suspect copies of the tax preparation software package running from other folders/directories are blocked by the blacklist15, while the valid copy of the tax preparation software package running from the allowed directory are allowed to execute.

Although there are many anticipated ways to make this intelligent recommendation, one example includes the file location from which the program14comes. In one example, if the program14is stored in a directory from which other program(s) are stored and those other programs are not in the blacklist15, then there is a greater chance that the program14is benign, as virus software usually tries to hide in directories that are rarely visited. As an example, when a user that often executes one program that is stored in a directory “C:/PgmFiles/mytrustedapps,” tries to run another program from that same directory, it is more than likely that the second program is benign. In such, upon approval of the administrator, execution of any program in said directory (program classification) will be permitted. It is also anticipated that, in some embodiments, when it is uncovered (local, company-wide, or worldwide) that a program is detected to contain malware that is stored in this directory, such approval will be revoked. Therefore, as malware evolves and someone creates malware that utilizes this directory, the server computer500receives such information and the administrative software917and the computer security system software17invalidates the entry allowing execution of the program based upon directory in the whitelist15. In this, the administrator will need to update the whitelist19and add entries for whichever programs are now known to be benign that reside in the directory that was removed from the whitelist15.

As shown inFIGS.6B-6E, at some time after the attempt to run a program14(e.g., after receiving a call from the user or during routine operations), the administrative software917uses the described heuristics to make one or more suggestions113(or options) to the administrator in an enhanced user interface105B, either before the administrator attempts to process the program or as part of the administration of the program. In some embodiments, the suggestions113are accompanied with a set of possible actions related to the suggestions. For example, if the program14is in a program classification of “all programs in a directory/folder,” then the suggestion113is to allow by folder. The possible actions are allow-by-folder, allow by hash, allow by filename, deny.

In other embodiments, the administrator is provided with selections for all possible ways to add an override to the whitelist19. Then, upon making a selection, in some embodiments, the heuristics are run to verify what the administrator has selected and, if the verification indicates an issue, the administrator receives guidance as to the best way to add the override to the whitelist15.

It is fully anticipated that the described heuristics analyze the program and associated data (e.g., historical data) before or after the administrator is presented with an administrator interface (e.g., enhanced administrator interface105B) and the heuristics are used to provide suggestions and/or enable or prevent options for the enhanced administrator interface105B. For example, if a known virus is known to have the same program name (e.g., tax2020.exe), then in some embodiments, the enhanced administrator interface105B lacks an option to add an override for the program14to the whitelist15and only presents an option to add the program14by hash value so that if the program is modified or replaced (e.g., by a different program having a virus and a different hash value), then the different program will not match the hash value and will not be allowed to run.

It is also fully anticipated that the described heuristics analyze the program14and associated data after the administrator is presented with an administrator interface (e.g., administrator interface105C) and the heuristics are used to provide feedback and/or enable or prevent options for the administrator interface105C. For example, if a virus is known to install into a program with the same program name (e.g., tax2020.exe), then in such embodiments, when the administrator selects the by-directory option111, the warning administrator interface105D is presented, and the administrator can only choose to allow by hash value107E or deny109(e.g., add to the blacklist).

In the administrator interfaces105B/105C/105D/105E, a description of the program is provided to the administrator, along with a suggestion113(if any), which in the enhanced administrator user interface105B is a suggestion113to enable execution of programs in the same directory, perhaps because one or more target computers10have run one or more of the same or different programs from that same directory in the past few weeks. In the enhanced administrator interface105B, the administrator has the ability to select allow107just that program (as in the past), deny109(not allowing execution of this program—e.g., adding the program to a blacklist), or allowing programs in the same directory by way of the by-directory option111.

Note that there are many ways to implement a blacklist15in which a single entry (or record) within the blacklist15, all of which are anticipated here within. The message that appears in the enhanced administrator interface105B is based upon analysis of the program that is attempted to be run with respect to various aspects of the program such as the program's name, certificate, path/folder, etc. In some embodiments, history is used to suggest a blacklisting/whitelisting strategy, including historic blacklisting by other administrators either within the same company or world-wide. For example, if the program is called “chrome.exe” and was previously enabled by hash value and each time an update to “chrome.exe” is made/loaded, the hash value does not match, the message window of the enhanced administrator interface105B will suggest the administrator add an override entry to the whitelist19so that future executions of that program name in a specific directory are allowed and the user does not find the error the next time “chrome.exe” is updated. Further, if many administrators in the same organization or world-wide have blacklisted “chrome.exe” running out of a specific directory, then the message window of the enhanced administrator interface105B would suggest blacklisting “chrome.exe” by name and adding an override to the whitelist19that allows execution in a known folder. Further, if many other administrators have blacklisted several programs in the same folder, then the message window of enhanced administrator interface105B will suggest blacklisting the entire folder, etc.

In some embodiments, it is already known that some form of malware utilizes a specific directory such as a download directory or temporary files directory. In such, the server computer500periodically receives such information to the administrative software917. In some embodiments, the administrative software warns the administrator not to enable this program by a suggestion113D/113E in the warn administrative interface105D/105E. In other embodiments, the administrative software917prevents the administrator from allowing execution of programs found in the requested directory and presents a message administrative interface informing the administrator that the program will not be allowed to run on any system.

If it is determined that the program14is not on the blacklist15and allowed to execute, the program14executes as shown in a user interface100A ofFIG.5, for example, displaying a user interface window103.

If, after an attempt to execute the program14, the program14is found in the blacklist15, the program14is prevented from executing and a user interface100B ofFIG.6is presented, displaying an error message105. In some embodiments, after such attempt, information about the attempted execution, the program name, program content, date/time, etc., are logged and/or transmitted to the server computer500where the administrative software917analyzes the information.

The table ofFIG.7depicts one implementation of a blacklist15and/or whitelist19. For efficiency, it is anticipated that in some embodiments, a blacklist15or whitelist19be implemented as a hash table for compact storage and faster access. In some embodiments, there are separate blacklists15for each type of blacklisting, for example, one for blacklisting by hash value, one for blacklisting by program name, etc. In this example, there is a single blacklist15(or whitelist19) arranged in linear fashion with entries for each type of blacklisted element (program or directory) in the same blacklist15.

As an example, using the blacklist15ofFIG.7, when an attempt is made to run a program14, the name of the program14is searched in the blacklist15(or program name range using wild card or regular expression characters as in “w??word.exe”). If the program name is found, the program14is prevented from running. If the program name is not found, a hash value of the program14is calculated and the blacklist15is searched for that hash value. Note that hash algorithms are known and well-understood in the field of programming. If the hash value is found in the blacklist15, the program14is prevented from running. Next, the signature of the program14is extracted (if the program is signed) and the blacklist15is searched for the signature. If the signature is found, the program14is prevented from running. If the signature is found, the directory in which the program14is located is determined and the blacklist15is searched for that directory. If the directory is not found, the program14is run as the program14is not in the blacklist15. If the directory is found, then it is determined that the program is in the blacklist15and not allowed to run, unless an entry in the whitelist19allows the program14to run.

In some embodiments, each entry of the blacklist15includes information regarding the program or directory such as the date of last change, the name of the program602, a hash value604of the program14, and a signature of the program606. In some embodiments, more or less information is maintained in the blacklist15. Note that as malware becomes more sophisticated, the malware often masquerades as known, valid programs such as word processors. The hash value604of the program14is one way to prevent this type of masquerading, as a hash value of a malware version (e.g., having the same name as the valid program) will often be different that a hash value604of the program14, as the malware version of the program will have different internal coding (e.g., the malicious code). In some embodiments, the hash value604of the program14, for example is based upon a summation/modulus or other numerical calculation based upon the entire program14or a portion of the program14. Any tampering with the program14by, for example, a hacker, will change the calculation, resulting in a mismatch between the calculated hash value and the hash value604of the program14from the blacklist15, even if a size of the file in which the program14is stored matches the size of the valid program.

In some embodiments, identification is by a signature of the program606as provided in the blacklist15. The signature of the program606, for example is based upon a probing of the entire program or a portion of the program. For example, the presence or absence of certain strings within the program, values at certain locations within the program, etc. Any tampering with the program14, for example, by a hacker, will change a calculation of the signature(s), resulting in not finding certain expected values within the signature based upon the signature of the program606from the blacklist15.

Referring toFIG.7A, an exemplary whitelist19is shown. In this exemplary whitelist19, an override entry was added on Sep. 4, 2017, indicating that programs14stored within the folder608, C:/pgmFiles/mytrustedapps, are trusted. In other words, the user tried to execute a program from the folder608C:/PgmFiles/mytrustedapps and when the enhanced administrator interface105B was presented to the administrator (seeFIG.6B), the suggestion113was “enable by directory” and the administrator invoked the by-directory option111. In this example, once approved, any program14that executes in the folder608C:/ProgramFiles/mytrustedapps will be allowed to execute.

Note that the entries include “<any>” for certain fields of the blacklist15and whitelist19. For example, in the first line of this exemplary whitelist19, the name of the program14would have to match “winword.exe,” but the program14can have any hash value, any signature, or be located in any directory. If both name and folder have values, then in order to run the program14, the name of the program14would have to match the name from the whitelist19and the program14would have to be executing out of the identified directory.

Referring toFIGS.8-10, exemplary program flows of the computer security system are shown.

It is anticipated that portions of the exemplary program flow execute on a user device such as the target computer10while portions of the exemplary program flow execute on the server computer500in any combination and on any known computer.

In this example, the flow starts by a program14attempting to start200on the target computer10. This step is anticipated to be performed through direct or indirect invocation by a user of the target computer10. In a direct invocation, the user knowingly tries to start the program14(e.g., software executable, application, etc.), for example, by double-clicking on a shortcut or icon of that executable. In an indirect invocation, the user initiates execution of an executable by indirect ways such as browsing to a web site, opening an email attachment, etc.

The computer security system software17determines202if the program14is in the blacklist15using any searching mechanism, including linear searching, binary searching, hash searching, etc. For example, the name of the program is searched and if found, the search is successful. If the name is not found, then a hash value is calculated for the program and the hash value is searched and if not found, other searches are performed.

If it is determined202that the program14is not in the blacklist15(e.g., the program is trusted) the program14is run204.

If it is determined202that the program14is in the blacklist15(e.g., the program is not trusted), the program14is prevented from running and, in some embodiments, the computer security system software17records data206regarding the attempt including, for example, the name of the program14, directory in which the program14is located, user identification (who tried to run the program), time/date, etc. In some embodiments, a message is sent or displayed208to an administrator of the target computer10. This part of the process competes without running of the program14.

InFIG.9, program flow of a sample administrative program is shown. At some time after a program14is prevented from running as perFIG.8, the administrator of the target computer10discovers this event. In some cases, by a message as perFIG.8, in some cases, by scanning the log files, and in some cases, by a user contacting the administrator requesting approval to run the program14.

In such, application details are accessed210from the stored data (e.g., log file) and a set of rules are applied212to determine how to handle the program14. If the program14does not conform220to the rules, a message is displayed230to the administrator requesting if the administrator wishes to allow this program14to execute in the future. If the administrator accepts232the program14to execute, the blacklist15and/or whitelist19for the target computer10is updated234(and in some examples, other computers), otherwise the administrative program is finished without updating the blacklist15or whitelist19, and therefore, the program14will not be allowed to execute. Note that, in some embodiments, the blacklist15for the target computer10is a blacklist15that is common across several of the target computers10, for example, all end-user computers in an organization.

If the program14conforms220to any of the rules to make a decision that extends beyond allowing only that program14, a message such as those inFIGS.11-15is displayed, depending upon the rule that applies to this particular program14. For example, if the program executes from a safe directory, the administrator is able to add an override to the whitelist19to allow all programs stored in that directory. If the program14conforms220to any of the rules to make a decision that extends beyond allowing only that program14, in some embodiments, a selection message222is displayed asking the administrator to allow all programs the conform to the one specific rule to make a decision that extends to a class of the programs14that are beyond allowing solely that program14, similar to the user interfaces ofFIGS.11-16. Note that it is anticipated that when the program conforms to multiple specific classes (e.g., rules), either the best rule is selected (e.g., the safest rule) or the user is prompted to select one rule out of the multiple rules presented. If the administrator does not accept224, the flow completes without removing the program14from the blacklist15. If the administrator accepts224, the whitelist15is updated226to add the override (and in some examples, updated on other computers) and future attempts to run the program14and those programs14that conform to the rule will be allowed. In some embodiments, the selection message222is not displayed, the whitelist15is automatically updated226with an override and future attempts to run the program14and those programs14that conform to the rule will be allowed. In some such embodiments, where the rule indicates multiple programs are in the blacklist15that are stored in or executed from the same folder as the program14, the override is not presented/allowed.

Examples of such classes of programs14include all programs14residing in a particular directory, all programs14signed by a certain authority, all programs14of a certain name, etc.

InFIG.10, malware was detected280somewhere, either on one of the target computers10or anywhere in the world, and such was communicated to the administrative software917that runs on the server computer500. Responsive to the detection, the administrative software917removes282any entries from the whitelist19that would allow execution of the program14that was detected280and add an entry to the blacklist15to exclude the program14having the malware. If it is found that the program14having the malware is already running284on any target computers10, warning messages286are displayed by the computer security system software17running on the target computers10to warn the user that this program14is currently running and it is potentially dangerous and may include malware. In this way, the user can reboot the target computer10or use a task manager to kill the already running program. In some embodiments, the program14that is currently running is automatically stopped by the computer security system software17that is running on the target computer10.

Referring toFIGS.10-16, exemplary administrator interfaces of the computer security system are shown. Administrative interfaces are provided for allowing or blocking certain programs on an individual computer or a set of computers. In general, any authorized user (e.g., administrator, IT person) is able to adjust blacklists to accommodate individual programs or a set of programs on one or more computers.

In the example ofFIG.11, an attempt to run a program named “regsvr32.exe” was made and the block or allow administrator interface700is displayed. The hash value702of the program and name704of the program are displayed, along with the vendor/supplier706, and a description708of the program are displayed. In this example, the level710has been selected to be “Computer” meaning that this program will only be allowed or blocked on a single target computer10(as opposed to all computers in the company, in an account, or in a group in which the user's computer resides). If the “close” feature712is selected, nothing happens and the administrator interface exits. If “Manage Prevent List”714is selected, the administrator is taken to a report administrator interface740(seeFIG.16). If the “allow”716feature is selected, the identified program is removed from the blacklist15(list of programs that are deemed malicious or unwanted) and future attempts to run the identified program are allowed on all computers in the selected level710. If the “block”718feature is selected, the identified program is added to the blacklist15and, in embodiments having a whitelist, the identified program is removed from the whitelist (list of allowed programs) on all computers in the selected level710.

In the example ofFIG.12, an allow administrator interface720is displayed. In this, the administrator is prompted to add a program to the whitelist19to allow operation of the program on one or more computers. InFIG.12, the hash value702for the program is displayed and a description708of the program is displayed (or entered by the administrator). InFIG.13, the allow administrator interface with pull-downs720A is shown indicating that the administrator has selected “file hash” as the type and other types are noted such as “Digital” and “Signature.” The user has selected “Both” as the platform724as the platform and other platforms are noted such as “OS-1” and “OS-2” as many enterprises use computers running different operating systems from different suppliers.

Once done, the administrator selects “add,” and a new administrator interface720B/720C ofFIG.14is shown indicating the previously selected type722(“File Hash”) and allowing the administrator to select a level730such as “account,” “company,” “group,” or “device.” Note that “company has been selected as the level730C and the name of the company732is displayed. At this point, the administrator has the ability to select “allow”736to add this program to the whitelists19of all computers associated with the selected level730(e.g., all computers in the company) or to select “block”738to not add this program to the blacklists15of all computers associated with the selected level730(e.g., all computers in the company).

To review and/or adjust the whitelists19(or blacklists15), a report administrator interface740as inFIG.16is used listing a description742of each program in the list, a date added/changed744for each program in the list, a file hash value746for each program in the list, a level748for each program in the list, and a type750for each program in the list. Note that for each program, there is a “remove” feature752that, upon selecting, the associated program will be removed from the list (whitelist19or blacklist15).

By providing the above noted administrator interfaces or similar administrator interfaces, the administrator (e.g., administrator of the target computer10, information technology staff, etc.) is provided the ability to make local or global changes to the whitelists and/or blacklists of the target computer10or a collection of computers that will allow or block programs having the defined characteristics (e.g., all programs having a certain name, all programs having a certain digital certificate, all programs executing from a specific directory, etc.). By making whitelisting/blacklisting more convenient and manageable, the users and administrators will be more accepting of whitelisting/blacklisting and the users/company will be generally more secure through the protection provided.

It is fully anticipated that the disclosed computer security system performs the same or similar steps regarding blacklisting a program. In commuter security parlance, a blacklist15defines a set of programs that are explicitly not allowed to run on the target computer10. It is fully anticipated that in some embodiments of the computer security system with enhanced blacklisting, the blacklist15includes entries for programs14, as well as classes of the programs14. In such embodiments, when the administrator is blacklisting a program(s)14or class of the programs14, the computer security system with enhanced blacklisting uses the same or similar heuristics to make recommendations or present selections based upon the program14, class, and/or historical activities/actions. For example, if the administrator wants to block a game program from being run from the folder/system/games, the computer security system with enhanced blacklisting recognizes that this folder includes other games and suggests blacklisting of the folder. In a similar way, if the administrator wants to block a game that is stored in/system32 and is attempting to block all programs14in that directory, the computer security system with enhanced blacklisting recognizes the number of valid programs14historically run from/system32 and suggests that the administrator add only by program name the program14.

Given all of the above, consider an information technology (IT) organization having responsibility for many target computers10, perhaps thousands of target computers10. Each target computer10typically has one or more users and when a user tries to run a program or script that is blocked, the user must consult with the IT organization to enable that program to run so that the user is able to perform their job function. Consider that many software packages and operating systems provide automatic updates, periodically installing updated programs and/or scripts on the target computers10or several users learning about a new program and these users, over a period of a few days, trying to run that new program and being blocked, the IT organization will receive many requests to enable the updated program or new program from many users. As there are often several personnel in the IT organization answering such requests (e.g., several shifts, each having a few technicians), it is anticipated that these requests are spread out across several technicians and, therefore, it is difficult for each technician to see a trend.

Referring toFIG.17, a simplified organization800is shown having multiple devices10, each device10having a whitelist19and a blacklist14. This exemplary organization800is divided into two sub-organizations810/820. The first sub-organization810(e.g., marketing) has two departments812/814(e.g., direct marketing and indirect marketing). The second sub-organization820has no sub-departments, for example, administration including the CEO, VP, and CFO.

Referring toFIG.18, a schematic view of the simplified organization800in which several users have made requests850to the central authority is shown. In this example, each request850is for a target activity that includes accessing the same program. As users of the devices10within the organization800try to run this program, the users receive messages that the program is blocked (e.g., the program is on a blacklist15or missing from any whitelist19). In some embodiments, a transaction of the attempted target activity is also forwarded to the server computer500. As the program (target activity) is important to such users, each user sends a request850to access that program to the information technology team, for example, through a user interface that runs on the device10, by sending an email or a phone call or a phone call to the information technology team, a phone call, or sending a written request to the information technology team. Upon reception of the request850, the request is assigned or queue for response and eventually processed by an information technology team member. In the past, each request was processed independently and there was no correlation to other requests850.

Referring toFIG.19, a schematic view of the simplified organization is again shown after several users have made requests to the information technology team. In this example, several users have tried to access the program and smart whitelisting/blacklisting software (e.g., running on the server computer500) has correlated the multiple requests by way of history900and rules910. The smart whitelisting/blacklisting software provides tools to the information technology team that shows the correlation to prior request850and suggestions as to possible administrations that will satisfy the pending request850and, possibly, reduce future requests850. The history900provides the smart whitelisting/blacklisting software with information regarding prior requests850and/or prior attempts to run the program (e.g., from notification transaction received each time an attempt was made to run that program). The rules910provide the smart whitelisting/blacklisting software with various thresholds and correlations to present options to the information technology team member who is processing the current request850. For example, one rule states that if the same program is requested by three other users within the same organization (or sub-organization) within a certain timeframe, suggest enabling the program across the organization (or sub-organization). Another example rule is if the same program is requested by three other users within one sub-organization and the program was enabled within that sub-organization and this request is made by a user in a second sub-organization, then the suggestion is to enable the program across the second sub-organization.

In the example ofFIG.19, the smart whitelisting/blacklisting software (e.g., running on the server computer500) suggested to the information technology team member to allow access of the requested program to a portion or all of the organization, in this example, two sub-organizations812/814. Using tools presented to the information technology team member by the smart whitelisting/blacklisting software, the program is added to the whitelist19and updated whitelists19A are distributed and installed on each of the user devices10in the two sub-organizations812/814. Note that in this example, the second sub-organization820(e.g., the executive office) does not receive the updated whitelist19A as a different level of caution is used for this organization and reflected in the rules910. For example, a rule910indicates that a new program can only be enabled in the whitelist19for the second sub-organization820after supervisory review.

Referring toFIG.20, a schematic view of the smart whitelisting/blacklisting software as part of the administrative software917is shown. The administrative software917with smart whitelisting/blacklisting software typically runs at the central authority that receives requests850, often on a server computer500or distributed across one or more computers. The smart whitelisting/blacklisting software utilizes history900and rules910to present user interfaces that present smart selections for the information technology personnel, for example within a user interface915.

As requests850are received and processed, records of each request850are stored in the history900(e.g., a history file in data storage512). The rules910are either integrated into the smart whitelisting/blacklisting software as part of the administrative software917as programmed heuristics, stored in a separate rules-file (e.g., a rules-file within the data storage512), or are implemented using artificial intelligence the receives feedback from the user interface915indicating what selections were made by the information technology personnel and feedback when a contrary action is performed. For example, if the AI machine recommends enabling a program across an organization and then, a few days later, that program is added to the blacklist because malware is found, the rule that enabled the program is candidate for modification by the AI engine, possibly requiring more time between the first request850and suggesting enabling of the program across the entire organization.

For clarity and brevity, distribution of the whitelist19and/or blacklist15is not shown inFIG.20.

Referring toFIG.21, a tabular view of an exemplary set of rules910is shown. In this example, there are two types of expected activities960that are anticipated in a request850from users: run an executable970or access a web location972. Note that other types of activities960are anticipated such as run a script, etc. For each activity960, there are rules for various organizations962, in this example, threshold rules for the organization964and threshold rules for the entire company966. Each threshold rule964/966includes a count and a number of days. For example, a threshold rule for the organization964of 4/5 indicates that if four requests to enable a certain program are received within a five-day window, then it is recommended to enable that program across the organization962, in this case the first sub-organization810. In another example, a threshold rule for the entire company966of 10/8 indicates that if ten requests to enable a certain program are received within an eight-day window, then it is recommended to enable that program across the organization962(in this case, the company which is the organization800.

Referring toFIG.22, a tabular view of an exemplary history file900is shown. In this exemplary history file900, the activity960is listed (e.g., a request to enable a user to run “a.out”) along with the originating organization962. Note that in some embodiments, the history file900is populated as transactions are received from devices10, for example, when an attempt is made to run a program that is not currently allowed to be run, while in some embodiments, the history file900is populated as requests850are received from users of the devices10, for example, after the user attempts to run a program and receives a message that the program is not currently allowed to be run.

In this exemplary history file, there is a time/date field902(shown as date and AM/PM for clarity and simplicity reasons) and an identification904field, for example, the user that initiated the request850or an identification of the device10that attempted to run the program, etc.

In this example, several users have attempted to run the program “a.out” and at the last line908, the fourth user (user6) has attempted to run the program “a.out” (or the fourth request to enable the program “a.out”) has been received within five days, satisfying the first rule in the exemplary rules910. Therefore, after the fourth user (user6) has attempted to run the program “a.out” (or the fourth request to enable the program “a.out”) has been received within five days, the smart whitelisting/blacklisting software (part of the administrative software917) recommends enabling the program, “a.out.” for the organization (the first sub-organization) to the information technology team member. If approved by the information technology team member, a whitelist19for that organization (the first sub-organization810) is modified and distributed to all devices10assigned to that organization.

Referring toFIGS.23and25, exemplary administrator user interfaces950/951of the computer security system with smart whitelisting/blacklisting is shown being displayed on a display586of the server computer500. In such, a user (Tom Programmer) has requested access to a program named “compiler.exe.” In this example, the administrator user interface950displays the program name, the path in which it is located, the name of the user making the request, the device on which the user desires access to the program, and the department in which the user works (Software development department). The smart whitelisting/blacklisting software running as part of the administrative software917on the server computer500, using the history900and rules910has determined that three other users have requested access to this program and has made a recommendation952to enable this program to run on all devices12within the group of the user making the request (e.g., the Software development department). The administrator is still presented with options to enable this program on the user's device954, within the user's group956, or company-wide958. Note that company-wide958is highlighted or gray-ed out to make the administrator think twice before enabling the program company-wide958. Also, as this is an example, it is fully anticipated that for certain organizations, more or less levels of hierarchy are presented to the administrator such as a list of groups, departments, divisions, etc. For example, in a large organization, there are multiple software development teams and several such teams desire use of certain tools/programs.

InFIG.24, a second exemplary administrator user interface951of the computer security system with smart whitelisting/blacklisting is shown being displayed on a display586of the server computer500. In such, a user (Tom Sales) has requested access to a program named “status.exe.” Again, the second administrator user interface951displays the program name, the path in which it is located, the name of the user making the request, the device on which the user desires access to the program, and the department in which the user works (Sales department). The smart whitelisting/blacklisting software running as part of the administrative software917on the server computer500, using the history900and rules910has determined that eight other users have requested access to this program and has made a recommendation962to enable this program to run on all devices12within the company of the user making the request (e.g., the Sales department). The administrator is still presented with options to enable this program on the user's device954, within the user's group956, or company-wide958. Note that company-wide958is no longer highlighted or gray-ed out as the recommendation is to enable the program company-wide958.

Referring toFIG.25, an exemplary flow chart of the smart whitelisting/blacklisting software that is part of the administrative software917is shown. In this, the smart whitelisting/blacklisting software for receives1200a request (or transaction indicating an unauthorized access was made such as running an unauthorized program) and adds1210information from the request850to the history900. Before considering whether to run the target of the request850(e.g., a program), in some embodiments a malware check1220is performed. If the malware check1220determines1230that the target of the request is unsafe, the target of the request is not allowed1240(e.g., added to the blacklist15) and the updated list (e.g., blacklist15) is distributed1250to one or more devices10.

If the malware check1220determines1230that the target of the request is unsafe, the rules910are checked1260to see if this request850meets any rule thresholds or heuristics. For example, if this is the 4threquest within five days of the same program from users in the first sub-organization810(seeFIG.22). If there is no match found1270, the target of the request850is added1280to an individual whitelist19(or removed from an individual blacklist15) such as a whitelist19for a single device10; and the list is distributed only to that device10.

If there is a match found1270and the administrator accepts1290the recommended allowance (e.g., enable across an organization or entire company), the target of the request850is added1300to a whitelist19(or removed from an individual blacklist15) based upon the recommendation and the whitelist19(or blacklist15) based upon the recommendation is forwarded to all devices10based upon the recommendation (e.g., forwarded to all devices10in an organization or entire company).

Equivalent elements can be substituted for the ones set forth above such that they perform in substantially the same manner in substantially the same way for achieving substantially the same result.

It is believed that the system and method as described and many of its attendant advantages will be understood by the foregoing description. It is also believed that it will be apparent that various changes may be made in the form, construction and arrangement of the components thereof without departing from the scope and spirit of the invention or without sacrificing all of its material advantages. The form herein before described being merely exemplary and explanatory embodiment thereof. It is the intention of the following claims to encompass and include such changes.