Patent Application
20130031111
The present invention relates to networks, and more particularly to increasing the efficiency of networks with the growing increase of cloud based technologies.
In the context of network security, the threat landscape has grown exponentially over the last few years. The threat landscape has grown so much that most Anti-Virus vendors are evaluating and implementing various technologies to mitigate the unmatched growth in the number of threats. As the threat landscape grows, so does the need to mitigate the threats associated with that growth.
Currently, the number of network based lookups required in a network cloud is very high. These network based lookups include performing signature lookups across a network for each file scanned on a system (e.g. a client computer, etc.). Thus, as the number of threats increase, the number of lookups required to ensure the network is secure also increases.
In some cases, however, it may be desirable to keep the lookup rate to less than a certain number of lookups per day. For example, it may be desirable to keep the lookup rate to less than ten lookups per day per client. Thus, harsh criteria is often used to keep the lookup rates low. As a result, many problematic items (e.g. malware, infected files, etc.) are not examined and such items are missed on the client systems. There is thus a need for overcoming these and/or other issues associated with the prior art.
A system, method, and computer program product are provided for segmenting a database based, at least in part, on a prevalence associated with known objects included in the database. In operation, a database including a plurality of known objects is identified. Additionally, the database is segmented into a plurality of segments. Furthermore, each of the plurality of known objects are assigned to one of the plurality of segments, based at least in part on a prevalence associated with each of the plurality of known objects.
Coupled to the networks 102 are servers 104 which are capable of communicating over the networks 102. Also coupled to the networks 102 and the servers 104 is a plurality of clients 106. Such servers 104 and/or clients 106 may each include a desktop computer, lap-top computer, hand-held computer, mobile phone, personal digital assistant (PDA), peripheral (e.g. printer, etc.), any component of a computer, and/or any other type of logic. In order to facilitate communication among the networks 102, at least one gateway 108 is optionally coupled therebetween.
The workstation shown in
The workstation may have resident thereon any desired operating system. It will be appreciated that an embodiment may also be implemented on platforms and operating systems other than those mentioned. One embodiment may be written using JAVA, C, and/or C++ language, or other programming languages, along with an object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications.
Of course, the various embodiments set forth herein may be implemented utilizing hardware, software, or any desired combination thereof. For that matter, any type of logic may be utilized which is capable of implementing the various functionality set forth herein.
As shown, a database including a plurality of known objects is identified. See operation 302. The objects may include any item capable of being stored in the database. For example, in various embodiments, the known objects may include files or programs.
In either case, the known objects may include objects that are known to be non-malicious. In this case, the database may include a whitelist database. In the context of the present description, a whitelist refers to any data structure that identifies one or more objects that are known to be non-malicious objects.
As another option, the database may include a blacklist database. In the context of the present description, a blacklist refers to any data structure that identifies one or more objects that are known to be malicious, unsafe, or undesirable objects. In this case, the known objects may include objects that are known to be malicious.
In one embodiment, the objects may include whitelisted objects. As an option, the whitelisted objects may be defined utilizing a Bloom filter. In this case, the Bloom filter may be utilized as a whitelist to offset a high false positive rate.
As shown further in
Furthermore, each of the plurality of known objects are assigned to one of the plurality of segments, based at least in part on a prevalence associated with each of the plurality of known objects. See operation 306. The prevalence may be indicative of an amount the object is accessed and/or utilized.
For example, the prevalence may include a high prevalence or a low prevalence. In this case, a high prevalence may indicate that an object is accessed and/or utilized regularly, or more than a predetermined amount. A low prevalence may indicate that an object is not accessed and/or utilized frequently, or less than a predetermined amount. In one embodiment, the prevalence information may be obtained utilizing client system based antivirus software.
The segments may then be allocated such that at least one of the segments corresponds to low prevalence objects. Additionally, at least one of the segments may correspond to high prevalence objects.
In one embodiment, the method 300 may further include determining whether to perform a lookup operation on the database. As an option, a Bloom filter may be utilized to determine whether to perform the lookup operation on the database. In this case, the Bloom filter may be stored on a client system. The Bloom filter may also be associated with and/or represent a blacklist.
Furthermore, a server system may be configured to update the Bloom filter stored on the client system. in this case, the updating may include pushing hashes stored as Bloom filter bit vectors to the client system. As an option, Bloom filter updates may be sent along with additional software updates.
More illustrative information will now be set forth regarding various optional architectures and features with which the foregoing technique may or may not be implemented, per the desires of the user. It should be strongly noted that the following information is set forth for illustrative purposes and should not be construed as limiting in any manner. Any of the following features may be optionally incorporated with or without the exclusion of other features described.
As shown, a signature lookup request is received. See operation 402. The signature lookup request is then analyzed using a Bloom filter stored on a client device. See operation 404.
It is then determined whether to perform a lookup based on the analysis. See operation 406. If it is determined that a lookup is to be performed, the lookup is performed. See operation 408.
Thus, it may be determined whether to perform a lookup operation on a database utilizing a Bloom filter. In this case, the Bloom filter may be stored on a client system. The client system may include a computer, a PDA, a mobile phone, or any other type of computing device.
Furthermore, a server system may update the Bloom filter stored on the client system. In this case, the updating may include pushing hashes stored as Bloom filter bit vectors to the client system. As an option, Bloom filter updates may be sent along with additional software updates. Furthermore, the Bloom filter may be associated with a blacklist.
Using the method 400, the number of network based lookups in a network may be reduced. For example, in many systems, the number of network based lookups in a cloud is very high. This is because the network based lookups involve signature lookups across a network for each file scanned on a system (e.g. a client system, etc.).
In some cases, however, it may be desirable to keep the lookup rate to less than a certain number of lookups per day. For example, it may be desirable to keep the lookup rate to less than ten lookups per day per client. To accomplish this, harsh criteria is often used to keep the lookup rates low. As a result, many problematic items (e.g. malware, etc.) are not examined and such items are missed on the client systems.
By performing a lookup of file signatures that are available locally on a client machine, better results may be achieved. In some cases, an antivirus DAT (AV DAT) based scanning model may be implemented. In these cases, the high number of specific signatures based on checksum or hash functions (e.g. Cyclic Redundancy Check, Message Digest Algorithm, etc.) in the DAT set may inflate the size of the DATs, making the DAT set computationally and economically infeasible. For example, large memory footprints of DATs may be a challenge on some low memory systems and on systems with slower connectivity to the Internet for downloading these files.
Additionally, the DAT releases may have to be very frequent to achieve the existing performance levels of real time lookups. Thus, there is a need for a relatively smaller DAT size that is sufficient to determine if the MD5 being looked up is present in a blacklist database.
Accordingly, in one embodiment, a set membership data structure may be utilized, such as a Bloom filter, that provides large savings in space, potentially at the expense of false positives. As an option, the MD5 hashes may be stored as a Bloom filter bit vector and pushed very frequently to the client system. Since, in some cases, an MD5 lookup may only determine if the MD5 for a given file is present in the bad file set, this lookup may be accomplished with the local bloom filter.
As the hit needs to be confirmed by a lookup, Bloom filters may be used to determine if a lookup should occur. Where false rates are not an issue, Bloom filters that have a high compression, and therefore a very small size, may be utilized. Additionally, in one embodiment, Bloom filter updates may be streamed between DAT releases to ensure these are near to real time lookups.
As shown, the system 500 may include memory 502. The memory 502 may be allocated to a database dedicated to a whitelist database 504 and/or a blacklist database 506. The whitelist database 504 and the blacklist database 506 may be located on a client system 508. The client system 508 may be in communication with a server system 510 over a network 512.
As shown, the whitelist database 504 may be segmented into segments that include high prevalence objects and low prevalence objects. This may be implemented to store a large whitelist of programs on a host in a memory efficient way.
For example, in the context of network security, the threat landscape has grown exponentially and continues to grow. The threats have grown so much that almost all the Anti-Virus (AV) vendors are currently evaluating and implementing various technologies to mitigate the unmatched growth in number of threats. Behavioral detection, automated signature creation, heuristic detections, black listing packers, etc. are few of the recent innovations that most of AV vendors implement.
Much of these innovations use the “black listing” approach, where a threat is detected and mitigated if it is known to be of malicious nature. These threats may include a file, a network packet, a particular behavior, etc.
Black listing generally only promises to detect a threat if the threat was analyzed before by the AV provider and has been deemed malign. One issue with this approach is the increasing number of signatures a client side solution needs to carry every time an AV vendor analyzes and deems a file/network packet/behavior as malign. These are typically delivered to the client computers in the form of signature updates.
The exponential growth in the threat landscape has also resulted in an exponential growth in signatures carried by these AV solutions. As another approach, a white listing technique may be implemented to keep a system free from threats. These systems are generally based on the premise that anything not known could be malicious.
This technology is generally more pro-active in mitigating the threats as anything new entering a system is deemed suspicious. This technique again calls for the client systems to carry the most recent updates of a whitelist database. A whitelist database would carry signatures of all the files that are known to be benign. However, with time and advancements in technology, the number of “good” files is also expected to increase. Thus, white listing may also see exponentially increasing updates.
Also, new proactive techniques may have higher than usual false positive rates. To mitigate this, a technique may be implemented to store a large whitelist of programs on a host in a memory efficient way. Therefore, the ability to store a large whitelist on a host allows proactive techniques to be more aggressive against new and potentially unseen malware samples.
In the case of good files, or the files that are benign in nature, a whitelist database may be segmented into several parts, including high prevalence parts and low prevalence parts. In one embodiment, this information may be collected through the client side AV software whenever programs are executed on the system. A first segment may contain signatures for files that are most prevalent (e.g. information on all Microsoft Office files Adobe files, all system .dlls loaded by these applications, etc.). A second segment may contain signatures for the files that are not prevalent.
By nature of the design of a computing system, the first segment may contain files released as part of operating systems and as part of widely used software applications. In general, this set of files would not change frequently. As an option, these files may be delivered as a bloom filter bit vector, representing the MD5 values of all the white listed files to the client systems incrementally at longer intervals of time. In this way, the overhead of delivering large sized signature files may be reduced.
In one embodiment, Bloom filters may be used as a whitelist to offset a high false positive rate an aggressive proactive test may introduce. For example, if a data mining technique is used to detect 90% tpr at 1% fpr, a Bloom filter may be used to make sure that the 90% do not contain known good applications. In this way, as a worst case, the heuristic would be ineffective if the Bloom filter has a false positive.
Furthermore, with respect to the system 500, the blacklist 506 may be represented by a set membership data structure, such as a Bloom filter, that provides large savings in space. The MD5 hashes may be stored as a Bloom filter bit vector and pushed very frequently to the client system 508 by the server system 510 over the network 512. Since, in some cases, an MD5 lookup may only determine if the MD5 for a given file is present in the bad file set, this lookup may be accomplished with the local bloom filter.
In this way, the Bloom filter may be used to determine if a lookup should occur. As an option, Bloom filters that have a high compression and a small size, may be utilized. In one embodiment, Bloom filter updates may be streamed between DAT releases provided by the server system 510.
While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 12605678 | Oct 2009 | US |
| Child | 13645164 | US |
