Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
  • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
  • H04L63/1416—Event detection, e.g. attack signature detection
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/55—Detecting local intrusion or implementing counter-measures
  • G06F21/552—Detecting local intrusion or implementing counter-measures involving long-term monitoring or reporting
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/55—Detecting local intrusion or implementing counter-measures
  • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
  • G06F21/577—Assessing vulnerabilities and evaluating computer system security
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2101—Auditing as a secondary aspect
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2115—Third party

Definitions

• the disclosure generally relates to the field of computer security, in particular to determining whether a computer file is malicious.
• Malware can attack modern computers. Malware threats include computer viruses, worms, Trojan horse programs, spyware, adware, crimeware, and phishing websites. Malicious entities sometimes attack servers that store sensitive or confidential data that can be used to the malicious entity's own advantage.
• malware is becoming less effective.
• Modern malware is often targeted and delivered to only a relative handful of computers.
• a Trojan horse program can be designed to target computers in a particular department of a particular enterprise.
• Such malware might never be encountered by security analysts, and thus the security software might never be configured with signatures for detecting such malware.
• Mass-distributed malware in turn, can contain polymorphisms that make every instance of the malware unique. As a result, it is difficult to develop signature strings that reliably detect all instances of the malware.
• a reputation system can determine the reputation of a file encountered on a computer in order to assess the likelihood that the file is malware.
• One way to develop the reputation for a file is to collect reports from networked computers on which the file is found and base the reputation on information within the reports.
• a file's reputation can change over time as more reports are collected. There is a need for a way to efficiently provide the changing reputation scores to the networked computers and other entities that use the reputation scores to detect malware.
• Embodiments of the present disclosure include methods (and corresponding systems and computer program products) for generating and utilizing individualized time-to- lives (TTLs) for reputation scores of computer files.
• TTLs time-to- lives
• One aspect of the present disclosure is a computer-implemented method for generating an individualized time -to-live (TTL) for a reputation score of a file, comprising: receiving a request from a client system, the request comprising an identifier of the file; generating a reputation score of the file, the reputation score representing an assessment of a trustworthiness of the file; determining a TTL for the reputation score based on the reputation score, the TTL describing a validity period for the reputation score; and transmitting the reputation score and the TTL to the client system in response to the request.
• TTL time -to-live
• Another aspect of the present disclosure is a computer system for generating an individualized time-to-live (TTL) for a reputation score of a file, comprising: a computer- readable storage medium comprising executable computer program code for: a
• the communication module for receiving a request from a client system, the request comprising an identifier of the file; a reputation score generation module for generating a reputation score of the file, the reputation score representing an assessment of a trustworthiness of the file; and a TTL determination module for determining a TTL for the reputation score based on the reputation score, the TTL describing a validity period for the reputation score; wherein the communication module is further configured for transmitting the reputation score and the TTL to the client system in response to the request.
• Still another aspect of the present disclosure is a computer-readable storage medium encoded with executable computer program code for generating an individualized time -to-live (TTL) for a reputation score of a file, the computer program code comprising program code for: receiving a request from a client system, the request comprising an identifier of the file; generating a reputation score of the file, the reputation score
• TTL time -to-live
• the reputation score representing an assessment of a trustworthiness of the file; determining a TTL for the reputation score based on the reputation score, the TTL describing a validity period for the reputation score; and transmitting the reputation score and the TTL to the client system in response to the request.
• FIG. 1 is a high-level block diagram of a computing environment according to one embodiment of the present disclosure.
• FIG. 2 is a high-level block diagram illustrating an example of a computer for use in the computing environment shown in FIG. 1 according to one embodiment of the present disclosure.
• FIG. 3 is a high-level block diagram illustrating modules within a security module according to one embodiment of the present disclosure.
• FIG. 4 is a high-level block diagram illustrating modules within a security system according to one embodiment of the present disclosure.
• FIG. 5 is a flow diagram illustrating a process for determining whether a computer file is malicious based on a reputation score and an individualized time -to-live (TTL) for the reputation score according to one embodiment of the present disclosure.
• TTL time -to-live
• FIG. 6 is a flow diagram illustrating a process for continuously generating a current reputation score and an accompanying individualized TTL for the reputation score for a computer file according to one embodiment of the present disclosure.
• FIG. 1 is a high-level block diagram that illustrates a computing environment 100 for generating and utilizing an individualized time-to-live (TTL) for a reputation score of a computer file, according to one embodiment of the present disclosure.
• the computing environment 100 includes a client system 110 and a security system 120 connected through a network 130. Only one of each entity is illustrated in order to simplify and clarify the present description. There can be other entities in the computing
• the client system 110 is an electronic device that can host malicious software.
• the client system 110 is a conventional computer system executing, for example, a Microsoft Windows-compatible operating system (OS), Apple OS X, and/or a Linux distribution.
• the client system 110 is another device having computer functionality, such as a personal digital assistant (PDA), mobile telephone, video game system, etc.
• PDA personal digital assistant
• the client system 110 typically stores numerous computer files that can host malicious software.
• Malicious software is generally defined as software that executes on the client system 110 surreptitiously or that has some surreptitious functionality. Malware can take many forms, such as parasitic viruses that attach to legitimate files, worms that exploit weaknesses in the computer's security in order to infect the computer and spread to other computers, Trojan horse programs that appear legitimate but actually contain hidden malicious code, and spyware that monitors keystrokes and/or other actions on the computer in order to capture sensitive information or display
• the client system 110 executes a security module 115 for detecting the presence of malware.
• the security module 115 can be, for example, incorporated into the OS of the computer or part of a separate comprehensive security package.
• the security module 115 is provided by the entity that operates the security system 120.
• the security module 115 can communicate with the security system 120 via the network 130 .
• the security module 115 transmits a request for a reputation score of a file to the security system 120, and receives the reputation score and an associated TTL in return.
• the security module 115 determines whether the file is malicious based on the received reputation score during the period of time defined by the TTL (called the validity period) and other factors such as observed behaviors of the file, and discards the reputation score thereafter.
• the reputation score represents an assessment of the trustworthiness of the associated file.
• the reputation score can be a continuous value ranging from 0 to 1, which a score of 0 indicating a very low trustworthiness (e.g., the file is malicious) and a score of 1 indicating a very high trustworthiness (e.g., the file is legitimate).
• the TTL specifies the period of time that the associated reputation score is valid. Depending upon the embodiment, the TTL can be specified as a length of time after a specified event (e.g., the reputation score is valid for one week after receipt of the score by the client system 110), as an explicit date (e.g., the reputation score is valid until July 1, 2012), or in another manner.
• the security system 120 is a hardware device and/or software program configured to receive information about computer files (e.g., their behaviors) from the client systems 110 and other sources, generate reputation scores for these files, and determine associated TTLs based on the reputation scores and confidence in the reputation scores.
• the security system 120 also receives requests from the client systems 110 for reputation scores of particular files, and provides their current reputation scores and TTLs in response.
• An example of the security system 120 is a web-based system providing security software and services allowing the security module 115 to detect and remediate malware on the client systems 110.
• the security system 120 generates the reputation score for a file based on attributes that correlate to the trustworthiness of the file. For example, the security system 120 can analyze a reputation of the source(s) of the file (e.g., whether the file was
• a digital signature e.g., a file digitally signed by a reputable entity is more trustworthy than a file signed by a less reputable entity or a file without a digital signature
• the file is prevalent among the client systems 110, to name a few.
• the security system 120 determines a confidence score for a generated reputation score.
• the confidence score measures the confidence the security system 120 has in the reputation score (i.e., the likelihood of the reputation score reflecting the true trustworthiness of the underlying file).
• the confidence score can be a continuous value ranging from 0 to 1 , which a score of 0 indicating a very low confidence (e.g., the indication value of the reputation score is very low) and a score of 1 indicating a very high confidence (e.g., the reputation score almost certainly reflects the true
• the security system 120 determines the confidence score based on attributes that correlate to the confidence in the generated reputation score, such as the value of the reputation score, the underlying file's age (i.e., how long the security system 120 has known about the file), and the file's prevalence across the user base of the security system 120. [0028]
• the security system 120 computes the TTL based on attributes that correlate to the trustworthiness of the file (i.e., the reputation score) and the confidence score for the reputation score. Generally, the security system 120 sets long TTLs for reputation scores with high confidence scores, and sets short TTLs for reputation scores with low confidence scores.
• the TTL represents an assessment of the length of time it takes for the security system 120 to collect enough additional related information that may cause the security system 120 to generate a materially different reputation score for the file. If the assessment of trustworthiness of a file is unlikely to change for a long time, the TTL is long, and otherwise short. By setting long TTLs for reputation scores with high confidence scores, the client system 110 relies on such reputation scores for a long period of time before requesting an update from the security system 120.
• cloud computing refers to a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet.
• cloud computing customers generally do not own the physical infrastructure serving as host to the software platform in question, but instead rent usage of resources from a third-party provider, where consume these resources as a service and pay only for resources used.
• the network 130 enables communications between the client system 110 and the security system 120.
• the network 130 uses standard
• the network 130 can include links using technologies such as Ethernet, 802.11, worldwide interoperability for microwave access (WiMAX), 3G, digital subscriber line (DSL), asynchronous transfer mode (ATM), InfiniBand, PCI Express Advanced Switching, etc.
• the networking protocols used on the network 130 can include multiprotocol label switching (MPLS), the transmission control protocol/Internet protocol (TCP/IP), the User Datagram Protocol (UDP), the hypertext transport protocol (HTTP), the simple mail transfer protocol (SMTP), the file transfer protocol (FTP), etc.
• the data exchanged over the network 130 can be represented using technologies and/or formats including the hypertext markup language (HTML), the extensible markup language (XML), etc.
• links can be encrypted using conventional encryption technologies such as secure sockets layer (SSL), transport layer security (TLS), virtual private networks (VPNs), Internet Protocol security (IPsec), etc.
• SSL secure sockets layer
• TLS transport layer security
• VPNs virtual private networks
• IPsec Internet Protocol security
• the entities can use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.
• the network 130 can also include links to other networks such as the Internet.
• FIG. 2 is a high-level block diagram illustrating an example computer 200.
• the computer 200 includes at least one processor 202 coupled to a chipset 204.
• the chipset 204 includes a memory controller hub 220 and an input/output (I/O) controller hub 222.
• a memory 206 and a graphics adapter 212 are coupled to the memory controller hub 220, and a display 218 is coupled to the graphics adapter 212.
• a storage device 208, keyboard 210, pointing device 214, and network adapter 216 are coupled to the I/O controller hub 222.
• embodiments of the computer 200 have different architectures.
• the storage device 208 is a computer-readable storage medium such as a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-state memory device.
• the memory 206 holds instructions and data used by the processor 202.
• the pointing device 214 is a mouse, track ball, or other type of pointing device, and is used in combination with the keyboard 210 to input data into the computer system 200.
• the graphics adapter 212 displays images and other information on the display 218.
• the network adapter 216 couples the computer system 200 to one or more computer networks.
• the computer 200 is adapted to execute computer program modules for providing functionality described herein.
• module refers to computer program logic used to provide the specified functionality.
• a module can be implemented in hardware, firmware, and/or software.
• program modules are stored on the storage device 208, loaded into the memory 206, and executed by the processor 202.
• the types of computers 200 used by the entities of FIG. 1 can vary depending upon the embodiment and the processing power required by the entity.
• the security system 120 might comprise multiple blade servers working together to provide the functionality described herein.
• the client system 110 might comprise a mobile telephone with limited processing power.
• the computers 200 can lack some of the components described above, such as keyboards 210, graphics adapters 212, and displays 218. EXAMPLE ARCHITECTURAL OVERVIEW OF THE SECURITY MODULE
• FIG. 3 is a high-level block diagram illustrating a detailed view of modules within the security module 115 according to one embodiment. Some embodiments of the security module 115 have different and/or other modules than the ones described herein. Similarly, the functions can be distributed among the modules in accordance with other embodiments in a different manner than is described here. As illustrated, the security module 115 includes a file monitor module 310, a security analysis engine 320, a
• the file monitor module 310 continuously monitors computer files within the client system 110 and collects related information such as their sources (e.g., the websites from which the files were downloaded), digital signatures, behaviors, and system properties such as the dates of creation and the dates of last modification. Such related information is collectively called the "metadata" of the associated files.
• the security analysis engine 320 determines whether the monitored files are malicious based on factors such as their metadata and reputation scores. In one
• the security analysis engine 320 makes the determination for a file when a suspicious behavior (e.g., an attempt to write to the system registry) is observed for that file. For example, the security analysis engine 320 can determines that a first file with a good reputation (i.e., high reputation score) that attempts to write to the registry is probably not malware, and that a second file with a bad reputation (i.e., low reputation score) that attempts to write to the registry is probably malware.
• a good reputation i.e., high reputation score
• a bad reputation i.e., low reputation score
• the security analysis engine 320 coordinates with the communication module 330 to request a current reputation score and an associated TTL from the security system 120. Otherwise, if the file is associated with a valid reputation score (e.g., the validity period has not ended), the security analysis engine 320 determines whether the file is malicious based on the reputation score and other factors such as the metadata.
• the security analysis engine 320 creates a black list of files determined malicious and a white list of files determined legitimate. If the verdict for a file (i.e., whether the file is malicious) changes, for example, because of a subsequent reputation score change, the security analysis engine 320 updates the black list and/or white list accordingly.
• the communication module 330 communicates with the security system 120 to determine the reputation scores and corresponding TTLs for the monitored files.
• the communication module 330 transmits an identifier of the file (e.g., a digital fingerprint) and related information (e.g., the metadata) to the security system 120, and receives a reputation score and an accompanying TTL in response.
• the file instead of or in addition to the identifier, the file itself can be transmitted to the security system 120.
• the communication module 330 stores the reputation score and the TTL in the data store 340 together with other related information for the file.
• the data store 340 stores data used by the client system 110. Examples of such data include identifiers of the computer files resided on the client system 110 and their metadata, reputation scores, and associated TTLs, and information about the security system 120 (e.g., IP address).
• the data store 340 may be a relational database or any other type of database.
• FIG. 4 is a high-level block diagram illustrating a detailed view of modules within the security system 120 according to one embodiment. Some embodiments of the security system 120 have different and/or other modules than the ones described herein.
• the security system 120 includes a communication module 410, a reputation score generation module 420, a confidence determination module 430, a TTL determination module 440, and a data store 450.
• the communication module 410 receives inquiries from the security modules 115 running on the client systems 110 and provides responses to the security modules 115.
• the inquiries include identifiers of computer files and may also include metadata for the files.
• the responses include reputation scores for the identified files and TTLs of the reputation scores.
• the communication module 410 contacts the reputation score generation module 420 and the TTL determination module 440 for the current reputation scores and associated TTLs, accordingly.
• the communication module 410 also receives information related to computer files from client systems 110 and other resources and stores the received
• the reputation score generation module 420 generates reputation scores for computer files. As described above, a reputation score is an assessment of the trustworthiness of the associated file. The reputation score generation module 420 generates the reputation score based on attributes that correlate to the trustworthiness of the file. Examples of such attributes include the prevalence (or popularity) of the file among the user base of the security system 120, the reputation of sources of the file, the reputation scores of other files resided on the same client systems 110 with the file, and the observed behaviors of the file, to name a few. In one embodiment, the reputation score generation module 420 continuously generates reputation scores as requests and information about computer files are received from the client systems 1 10 and other sources.
• the confidence determination module 430 determines the confidence scores for the reputation scores generated by the reputation score generation module 420. As described above, a confidence score measures the confidence the security system 120 has in the generated reputation score. The confidence determination module 430 determines the confidence score based on attributes that correlate to the confidence in the generated reputation score. Examples of such attributes include the value of the reputation score, the file's age (i.e., how long the security system 120 has known about the file), and the file's prevalence across the user base of the security system 120.
• a reputation score that is on or near the extreme ends of the spectrum serves as an indication of high confidence in the reputation score, since such a reputation score is unlikely to change materially over time. For example, if a reputation score is close to 0, the low end of the spectrum, indicating that the associated file is almost certainly malicious, the chance that the reputation score will change substantially over time is close to zero.
• reputation scores are organized into the following reputation bands: extreme (higher than 0.95 or less than 0.05), decisive (between 0.95 and 0.8 or between 0.05 and 0.2), marginally decisive (between 0.7 and 0.8 or between 0.2 and 0.3), and indecisive (between 0.3 and 0.7).
• the length of time the security system 120 has known about a file is another indicator of confidence in the reputation score of the file. If a file is relatively new to the security system 120, the confidence of the reputation score is low since the security system 120 probably has not collected enough information to make a good assessment of its trustworthiness. As the file becomes more familiar to the security system 120, the confidence in the reputation score increases, since the security system 120 is likely to have collected more information and can make a better assessment. In addition, if the security system 120 has known about the file for a long time, the chance of new information that will materially change the reputation score surfacing in the near future is also low.
• file ages are organized into the following age bands: old (greater than 6 months), middle-aged (equal or less than 6 months, older than 3 months), young (equal or less than 3 months, older than 1.5 months); very young (equal or less than 1.5 months).
• file prevalence is also an indicator of confidence in the reputation score of the file. Files that are more prevalent tend to be better known to the security system 120, and as a result the security system 120 tends to have more information about such prevalent files, boosting confidence of their reputation scores.
• file prevalence is categorized into the following prevalence bands: very high (more than 50,000 machines), high (equal or less than 50,000, more than 25,000), medium (equal or less than 25,000, more than 10,000), low (equal or less than 10,000, more than 1,000), very low (equal or less than 1,000).
• the confidence determination module 430 determines the confidence scores by collectively considering multiple confidence indicators such as the ones described above. For example, the confidence determination module 430 can determine the confidence scores by walking through the following table:
• the confidence determination module 430 can take the confidence score for the reputation score of a file from the first row (from top down) in the table for which the attributes of the file meet or exceed what is specified in each category. To simplify the issue, the confidence scores determined using the above table has one of the following four values: very high, high, low, and very low.
• the TTL determination module 440 determines TTLs for reputation scores generated by the reputation score generation module 420. As described above, a TTL describes the validity period for its associated reputation score. The TTL determination module 440 determines a TTL based on the associated reputation score and the confidence score determined for the reputation score. Continuing with the above example, the TTL determination module 440 can determine the TTLs by walking through the following table in a similar manner:
• the TTLs determined using the above table has one of the following four values: one year, one month, one week, and one day.
• the data store 450 stores data used by the security system 120. Examples of such data include information related to computer files (e.g., identifiers such as digital fingerprints, metadata, past/current reputation scores and TTLs), websites, digital signatures, and client systems 110, to name a few. Information related to files can be grouped together and indexed by file identifiers to facilitate rapid retrieval. Similar to the data store 340, the data store 450 may be a relational database or any other type of database.
• FIG. 5 is a flow diagram illustrating a process 500 for the security module 115 to determine whether a computer file is malicious based on a reputation score and an individualized TTL for the reputation score, according to one embodiment.
• Other embodiments can perform the steps of the process 500 in different orders.
• other embodiments can include different and/or additional steps than the ones described herein.
• the security module 115 running on the client system 110 identifies 510 a computer file for security examination. For example, the security module 115 monitors files residing on the client system 110, observes an attempt to perform a suspicious activity by one of the monitored files, and identifies 510 that file for security examination.
• the security module 115 determines 520 whether the identified file has a valid reputation score available. For example, the security module 115 searches in the data store 340 for the presence of a reputation score associated with the identified file and the accompanying TTL. If no such reputation score is present or the available reputation score is already expired (i.e., as indicated by the TTL), the security module 115 determines 520 that no valid reputation score is available. Otherwise, if a reputation score for the identified file is present in the data store 340 and the validity period defined by the accompanying TTL has not ended, the security module 115 assumes the reputation score to be a valid assessment of the trustworthiness of the identified file, and determines 520 that the identified file has a valid reputation score available.
• the security module 115 determines 550 whether the file is malicious based on the reputation score and other factors such as the observed behaviors of the identified file. The security module 115 can further determine whether to allow any attempt to perform suspicious activities by the identified file based on whether the file is determined malicious.
• the security module 115 requests 530 a reputation score for the identified file from the security system 120. For example, the security module 115 transmits to the security system 120 a request including an identifier of the file (e.g., the digital fingerprint). The security module 115 may also transmit metadata (e.g., observed behavior) for the identified file to the security system 120 along with the request. The security module 115 then receives 540 a reputation score and an
• the security module 115 determines 550 whether the file is malicious as described above.
• FIG. 6 is a flow diagram illustrating a process 600 for the security system 120 to continuously generate a current reputation score and an accompanying individualized TTL for the reputation score for a computer file, according to one embodiment.
• Other embodiments can include different and/or additional steps than the ones described herein.
• the security system 120 receives 610 information related to a computer file. Examples of the related information include an identifier of the computer file (e.g., digital signature), observed behaviors, source(s), prevalence (e.g., the client systems 110 hosting the file), and age (e.g., how long the file exists on a particular the client system 110), to name a few.
• the security system 120 receives 610 the information from sources such as the security module 115 running on the client system 110, the data store 450, and other sources.
• the security system 120 stores the related information received from the security module 1 15 in the data store 450.
• the security system 120 generates 620 a current reputation score for the file based on the received information, determines 630 a confidence score for the generated reputation score, and determines 640 a TTL for the generated reputation score based on factors including the reputation score and the confidence score.
• the reputation score along with the TTL and the confidence score can be stored in the data store 450 as the current reputation score for the computer file.
• the process 600 is repeated continuously to generate updated reputation scores and TTLs that account for newly-received related information for the file.
• the security system 120 may repeat the process 600 when new related information is received, when receiving a request for the current reputation score and TTL of the file, or at a predetermined time interval.
• the security system 120 receives 610 a request for a reputation score for a file along with metadata of that file from the security module 115, generates 620 a reputation score taking into account the received metadata, and determines 630, 640 a confidence score and a TTL, and returns the reputation score and the TTL to the security module 115.
• This approach intelligently determines an individualized TTL for a reputation score of a particular file based on attributes of the file that reflect the confidence in the reputation score. As a result, the number of requests the security modules 115 transmit to the security system 120 regarding files that are highly likely to be good or bad (i.e., files with high-confidence reputation scores) are reduced, and therefore the performances of the client systems 110 and the security system 120 are improved.
• this approach advantageously achieves a tradeoff between providing satisfying realtime security to the client systems 110 and maintaining backend performance and scalability.
• At least a part of the security system 120 can be
• the security module 115 running on the client system 110 such that the client system 110 locally generates reputation scores and TTLs for computer files and does not regenerate the reputation scores until their TTLs expire.
• the TTL provided by the security system 120 can be further customized by the client system 110 based on its local security policy. For example, if the client system 110 has low security policies in place (e.g., computers in an Internet cafe) then the client system 1 10 can extend the TTLs of the reputation scores by a pre-determined and customizable factor. On the other hand, if the client system 110 enforces stringent local security policies, then the client system 1 10 may reduce the TTLs provided by the security system 120.
• any reference to "one embodiment” or “an embodiment” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment.
• the appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
• Coupled and “connected” along with their derivatives. It should be understood that these terms are not intended as synonyms for each other. For example, some embodiments may be described using the term “connected” to indicate that two or more elements are in direct physical or electrical contact with each other. In another example, some embodiments may be described using the term “coupled” to indicate that two or more elements are in direct physical or electrical contact. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. The embodiments are not limited in this context.
• the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion.
• a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.
• "or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• General Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Computing Systems (AREA)
• Health & Medical Sciences (AREA)
• Virology (AREA)
• General Health & Medical Sciences (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Information Transfer Between Computers (AREA)
• Computer And Data Communications (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (1)

Family

ID=43064680

Family Applications (1)

Country Status (5)

Cited By (1)

Families Citing this family (49)

Citations (1)

Family Cites Families (16)

• 2009
  • 2009-09-15 US US12/560,261 patent/US8800030B2/en active Active
• 2010
  • 2010-09-10 EP EP10763494.1A patent/EP2478460B1/en active Active
  • 2010-09-10 CA CA2770265A patent/CA2770265C/en active Active
  • 2010-09-10 WO PCT/US2010/048475 patent/WO2011034792A1/en not_active Ceased
  • 2010-09-10 JP JP2012528934A patent/JP5610451B2/ja not_active Expired - Fee Related

Patent Citations (1)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events