This also occurred with our setup and we had to roll back to the last release.We worked with TAC to see what actually occured and they believe there might have been a problem with one of the antivirus databases (same release as yours), or one of the updates corrupted the PANs database . Waiting to see what happens with the next release
The message "protected by an older version of antivirus" randomly appears and disappears. No rhyme or reason. Clients now on the latest version of LogMeIn, 4.1.0.14148. No change. Customer support has not been able to assist me with this issue. Stuck in limbo.
K7 Full Version Antivirus Free Download
tag_hash_104 🔥 https://urllio.com/2yjYVz 🔥
Often, it takes a while for this message to appear on the clients. Normally, the "Protected by an older version of antivirus software" appears in the Central Admin console, not on the clients themselves.
Other times, I've found that manually running the "Check Update" does nothing. Instead, I have to wait until the automatic "check update" process runs a couple times successfully. Then, clients' status changes from "Protected by an older version of antivirus software" to "Antivirus software updated" on their own in the Central Admin console.
Each month, we stop over 1.5 billion cyberattacks all around the globe thanks to an unrivaled threat detection network, which is why professionals and amateurs alike love our free and paid antivirus protection.
Abstract:Antivirus software is one of the most widely used tools fordetecting and stopping malicious and unwanted files. However, the long termeffectiveness of traditional host-based antivirus is questionable. Antivirussoftware fails to detect many modern threats and its increasing complexityhas resulted in vulnerabilities that are being exploited bymalware. This paper advocates a new model for malware detection on end hostsbased on providing antivirus as an in-cloud network service. This modelenables identification of malicious and unwanted software by multiple,heterogeneous detection engines in parallel, a technique we term `N-versionprotection'. This approach provides several important benefits includingbetter detection of malicious software, enhanced forensicscapabilities, retrospective detection, and improveddeployability and management. To explore this idea we construct and deploya production quality in-cloud antivirus system called CloudAV.CloudAV includes a lightweight, cross-platform host agent and a networkservice with ten antivirus engines and two behavioral detection engines. Weevaluate the performance, scalability, and efficacy of the system using datafrom a real-world deployment lasting more than six months and a database of7220 malware samples covering a one year period. Using this dataset we find thatCloudAV provides 35% better detection coverage against recent threatscompared to a single antivirus engine and a 98% detection rate across the fulldataset. We show that the average length of time to detect new threats by anantivirus engine is 48 days and that retrospective detection can greatlyminimize the impact of this delay. Finally, we relate two case studiesdemonstrating how the forensics capabilities of CloudAV were used byoperators during the deployment.
1 IntroductionDetecting malicious software is a complex problem. The vast, ever-increasingecosystem of malicious software and tools presents a daunting challenge fornetwork operators and IT administrators. Antivirus software is one of the most widely used tools for detecting and stopping malicious andunwanted software. However, the elevating sophistication of modern malicioussoftware means that it is increasingly challenging for any single vendor todevelop signatures for every new threat. Indeed, a recent Microsoft survey found more than 45,000 new variants of backdoors, trojans, and bots during thesecond half of 2006 [17].Two important trends call into question the long term effectiveness ofproducts from a single antivirus vendor. First, there is a significantvulnerability window between when a threat first appears and when antivirusvendors generate a signature. Moreover, a substantial percentage of malware isnever detected by antivirus software. This means that end systems with thelatest antivirus software and signatures can still be vulnerable for longperiods of time. The second important trend is that the increasing complexityof antivirus software and services has indirectly resulted in vulnerabilitiesthat can and are being exploited by malware. That is, malware is actuallyusing vulnerabilities in antivirus software itself as a means to infectsystems. SANS has listed vulnerabilities in antivirus software as one of thetop 20 threats of 2007 [27].In this paper we suggest a new model for the detection functionality currentlyperformed by host-based antivirus software. This shift is characterized by two key changes.Antivirus as a network service: First, the detectioncapabilities currently provided by host-based antivirus software can be moreefficiently and effectively provided as an in-cloud network service.Instead of running complex analysis software on every end host, we suggestthat each end host run a lightweight process to detect new files, send them toa network service for analysis, and then permit access or quarantine thembased on a report returned by the network service.N-version protection: Second, the identification of maliciousand unwanted software should be determined by multiple, heterogeneousdetection engines in parallel. Similar to the idea of N-version programming,we propose the notion of N-version protection and suggest that malwaredetection systems should leverage the detection capabilities of multiple,heterogeneous detection engines to more effectively determine malicious andunwanted files.This new model provides several important benefits. (1) Better detectionof malicious software: antivirus engines have complementary detectioncapabilities and a combination of many different engines can improve theoverall identification of malicious and unwanted software. (2) Enhancedforensics capabilities: information about what hosts accessed what files provides an incredibly rich database of information for forensics andintrusion analysis. Such information provides temporal relationships betweenfile access events on the same or different hosts. (3) Retrospectivedetection: when a new threat is identified, historical information can beused to identify exactly which hosts or users open similar or identical files.For example, if a new botnet is detected, an in-cloud antivirus service canuse the execution history of hosts on a network to identify which hosts havebeen infected and notify administrators or even automatically quarantineinfected hosts. (4) Improved deployability and management: Movingdetection off the host and into the network significantly simplifies hostsoftware enabling deployment on a wider range of platforms and enablingadministrators to centrally control signatures and enforce file accesspolicies.To explore and validate this new antivirus model, we propose an in-cloudantivirus architecture that consists of three major components: a lightweighthost agent run on end hosts like desktops, laptops, and mobiles devicesthat identifies new files and sends them into the network for analysis; anetwork service that receives files from hosts and identifies maliciousor unwanted content; and an archival and forensics service that storesinformation about analyzed files and provides a management interface foroperators. We construct, deploy, and evaluate a production quality in-cloud antivirussystem called CloudAV. CloudAV includes a lightweight, cross-platform hostagent for Windows, Linux, and FreeBSD and a network service consisting of tenantivirus engines and two behavioral detection engines. We provide a detailedevaluation of the system using a dataset of 7220 malware samples collected inthe wild over a period of a year [20] and a production deployment ofour system on a campus network in computer labs spanning multiple departmentsfor a period of over 6 months.Using the malware dataset, we show how the CloudAV N-version protectionapproach provides 35% better detection coverage against recent threatscompared to a single antivirus engine and 98% detection coverage of theentire dataset compared to 83% with a single engine. In addition, weempirically find that the average length of time to detect new threats by asingle engine is 48 days and show how retrospective detection can greatlyminimize the impact of this delay.Finally, we analyze the performance and scalability of the system usingdeployment results and show that while the total number of executables run byall the systems in a computing lab is quite large (an average of 20,500 perday), the number of unique executables run per day is two orders of magnitudesmaller (an average of 217 per day). This means that the caching mechanismsemployed in the network service achieves a hit rate of over 99.8%, reducing theload on the network and, in the rare case of a cache miss, we show that theaverage time required to analyze a file using CloudAV's detection engines isapproximately 1.3 seconds.
2 Limitations of Antivirus SoftwareFigure 1:Detection rate for ten popular antivirus products as a function ofthe age of the malware samples.AV Vendor Version 3 Months 1 Month 1 Week Avast 4.7.1043 62.7% 45.8% 39.6% AVG 7.5.503 83.8% 78.6% 72.2% BitDefender 7.1.2559 83.9% 79.7% 78.5% ClamAV 0.91.2 57.5% 48.8% 46.8% CWSandbox 2.0 N/A N/A N/A F-Prot 6.0.8.0 70.4% 49.6% 46.0% F-Secure 8.00.101 80.9% 74.4% 60.3% Kaspersky 7.0.0.125 89.2% 84.0% 78.5% McAfee 8.5.0i 70.5% 56.7% 53.9% Norman 1.8 N/A N/A N/A Symantec 15.0.0.58 60.8% 38.8% 45.2% Trend Micro 16.00 79.4% 74.6% 75.3% (a)(b)Antivirus software is one of the most successful and widely used tools fordetecting and stopping malicious and unwanted software. Antivirus software isdeployed on most desktops and workstations in enterprises across the world.The market for antivirus and other security software is estimated to increaseto over $10 billion dollars in 2008 [10].The ubiquitous deployment of antivirus software is closely tied to theever-expanding ecosystem of malicious software and tools. As the constructionof malicious software has shifted from the work of novices to a commercial andfinancially lucrative enterprise, antivirus vendors must expend more resources tokeep up. The rise of botnets and targeted malware attacks for the purposes ofspam, fraud, and identity theft present an evolving challenge for antiviruscompanies. For example, the recent Storm worm demonstrated the use ofencrypted peer-to-peer command and control, and the rapid deployment of newvariants to continually evade the signatures of antivirus software [4].However, two important trends call into question the long term effectivenessof products from a single antivirus vendor. The first is that antivirussoftware fails to detect a significant percentage of malware in the wild.Moreover, there is a significant vulnerability window between when a threatfirst appears and when antivirus vendors generate a signature or modify theirsoftware to detect the threat. This means that end systems with the latestantivirus software and signatures can still be vulnerable for long periods oftime. The second important trend is that the increasing complexity ofantivirus software and services has indirectly resulted in vulnerabilities thatcan and are being exploited by malware. That is, malware is actually usingvulnerabilities in antivirus software as means to infect systems.2.1 Vulnerability WindowThe sheer volume of new threats means that it is difficult for any oneantivirus vendor to create signatures for all new threats. The ability of anysingle vendor to create signatures is dependent on many factors such asdetection algorithms, collection methodology of malware samples, and responsetime to 0-day malware. The end result is that there is a significant period oftime between when a threat appears and when a signature is created by antivirusvendors (the vulnerability window).To quantify the vulnerability window, we analyzed the detection rate ofmultiple antivirus engines across malware samples collected over a one yearperiod. The dataset included 7220 samples that were collected between November11th, 2006 to November 10th, 2007. The malware dataset is described in furtherdetail in Section 6. The signatures used for the antiviruswere updated the day after collection ended, November 11th, 2007, and stayedconstant through the analysis.In the first experiment, we analyzed the detection of recent malware. Wecreated three groups of malware: one that included malware collected more recently than 3 months ago, one that included malware collected morerecently than 1 month ago, and one that included malware collected morerecently than 1 week ago. The antivirus engine and signature versions along withtheir associated detection rates for each time period are listed inFigure 1(a). The table clearly shows that the detection ratedecreases as the malware becomes more recent. Specifically, the number of malwaresamples detected in the 1 week time period, arguably the most recent andimportant threats, is quite low.In the second experiment, we extended this analysis across all the days in theyear over which the malware samples were collected.Figure 1(b) shows significant degradation of antivirus enginedetection rates as the age, or recency, of the malware sample is varied. Ascan be seen in the figure, detection rates can drop over 45% when oneday's worth of malware is compared to a year's worth. As the plot shows,antivirus engines tend to be effective against malware that is a year old butmuch less useful in detecting more recent malware, which pose the greatestthreat to end hosts.2.2 Antivirus Software VulnerabilitiesA second major concern about the long term viability of host-based antivirussoftware is that the complexity of antivirus software has resultedin an increased risk of security vulnerabilities. Indeed, severevulnerabilities have been discovered in the antivirus engines of nearly everyvendor. While local exploits are more common (ioctl vulnerabilities,overflows in decompression routines, etc), remote exploits in managementinterfaces have been observed in the wild [30]. Dueto the inherent need for elevated privileges by antivirus software, many ofthese vulnerabilities result in a complete compromise of the affected endhost.Figure 2:Number of vulnerabilities reported in the National Vulnerability Database(NVD) for ten antivirus vendors between 2005 and November 2007Figure 2 shows the number of vulnerabilities reported in theNational Vulnerability Database [21] for ten popular antivirus vendorsbetween 2005 and November 2007. This large number of reported vulnerabilitiesdemonstrates not only the risk involved in deploying antivirus software, butalso an evolution in tactics as attackers are now targeting vulnerabilities inantivirus software itself.
3 ApproachThis paper advocates a new model for the detection functionality currentlyperformed by antivirus software. First, the detection capabilities currentlyprovided by host-based antivirus software can be more efficiently andeffectively provided as an in-cloud network service. Second, theidentification of malicious and unwanted software should be determined by multiple, heterogeneous detection engines in parallel.3.1 Deployment EnvironmentBefore getting into details of the approach, it is important to understand theenvironment in which such an architecture is most effective. First andforemost, we do not see the architecture replacing existing antivirus orintrusion detection solutions. We base our approach on the same threatmodel as existing host-based antivirus solutions and assume an in-cloudantivirus service would run as an additional layer of protection to augmentexisting security systems such as those inside an organizational network likean enterprise. Some possible deployment environments include:Enterprise networks: Enterprise networks tend to be highlycontrolled environments in which IT administrators control both desktop andserver software. In addition, enterprises typically have good networkconnectivity with low latencies and high bandwidth between workstations and back office systems.Government networks: Like enterprise networks, governmentnetworks tend to be highly controlled with strictly enforced software and security practices. In addition, policy enforcement, access control, and forensic logging can be useful in tracking sensitive information.Mobile/Cellular networks: The rise of ubiquitous WiFi andmobile 2.5G and 3G data networks also provide an excellent platform for aprovider-managed antivirus solution. As mobile devices become increasinglycomplex, there is an increasing need for mobile security software. Antivirussoftware has recently become available from multiple vendors for mobile phones [9,13,31].Privacy implications: Shifting file analysis to a centrallocation provides significant benefits but also has important privacyimplications. It is critical that users of an in-cloud antivirus solutionunderstand that their files may be transferred to another computer foranalysis. There are may be situations where this might not be acceptable tousers (e.g. many law firms and many consumer broadband customers). However, incontrolled environments with explicit network access policies, like manyenterprises, such issues are less of a concern. Moreover, the amount ofinformation that is collected can be carefully controlled depending on theenvironment. As we will discuss later, information about each file analyzedand what files are cached can be controlled depending on the policies of thenetwork.3.2 In-Cloud DetectionThe core of the proposed approach is moving the detection of malicious andunwanted files from end hosts and into the network. This idea was originallyintroduced in [23] and we significantly extend andevaluate the concept in this paper.There is currently a strong trend toward moving services from end host andmonolithic servers into the network cloud. For example, in-cloudemail [5,7,28] and HTTP [18,25] filteringsystems are already popular and are used to provide an additional layer ofsecurity for enterprise networks. In addition, there have been severalattempts to provide network services as overlaynetworks [29,33].Moving the detection of malicious and unwanted files into the networksignificantly lowers the complexity of host-based monitoring software. Clientsno longer need to continually update their local signature database, reducingadministrative cost. Simplifying the host software also decreases the chancethat it could contain exploitablevulnerabilities [15,30]. Finally, alightweight host agent allows the service to be extended to mobile andresource-limited devices that lack sufficient processing power but remain anenticing target for malware.3.3 N-Version ProtectionThe second core component of the proposed approach is a set of heterogeneousdetection engines that are used to provide analysis results on a file, alsoknown as N-version protection. This approach is very similar toN-version programming, a paradigm in which multiple implementations ofcritical software are written by independent parties to increase thereliability of software by reducing the probability of concurrentfailures [2]. Traditionally, N-version programminghas been applied to systems requiring high availability such as distributedfilesystems [26]. N-version programming has also beenapplied to security realm to detect implementation faults in web services thatmay be exploited by an attacker [19]. WhileN-version programming uses multiple implementations to increase faulttolerance in complex software, the proposed approach uses multiple independentimplementations of detection engines to increase coverage against a highlycomplex and ever-evolving ecosystem of malicious software.A few online services have recently been constructed that implement N-versiondetection techniques. For example, there are online web services for malwaresubmission and analysis [6,11,22]. However, theseservices are designed for the occasional manual upload of a virus sample,rather than the automated and real-time protection of end hosts.
4 ArchitectureFigure 3:Architectural approach for in-cloud file analysis service.In order to move the detection of malicious and unwanted files from end hostsand into the network, several important challenges must be overcome: (1)unlike existing antivirus software, files must transported into the networkfor analysis; (2) an efficient analysis system must be constructed to handlethe analysis of files from many different hosts using many different detectionengines in parallel; and (3) the performance of the system must be similar orbetter than existing detection systems such as antivirus software.To address these problems we envision an architecture that includes threemajor components. The first is a lightweight host agent run on end systems likedesktops, laptops, and mobiles devices that identifies new files and sends theminto the network for analysis. The second is a network service thatreceives files from the host agent, identifies malicious and unwanted content, andinstructs hosts whether access to the files is safe. The third component isan archival and forensics service that stores information about whatfiles were analyzed and provides a query and alerting interface for operators.Figure 3 shows the high level architecture of the approach.4.1 Client SoftwareMalicious and unwanted files can enter an organization from many sources. Forexample, mobile devices, USB drives, email attachments, downloads, andvulnerable network services are all common entry points. Due to the broadrange of entry vectors, the proposed architecture uses a lightweight fileacquisition agent run on each end system.Just like existing antivirus software, the host agent runs on each end host andinspects each file on the system. Access to each file is trapped and divertedto a handling routine which begins by generating a unique identifier (UID) of the file and comparing that identifier against a cache of previously analyzed files. If a file UID is not present in the cache then the file is sent to the in-cloud network service for analysis.To make the analysis process more efficient, the architecture provides amethod for sending a file for analysis as soon as it is written on the end host's filesystem (e.g., via file-copy, installation, or download). Doing soamortizes the transmission and analysis cost over the time elapsed betweenfile creation and system or user-initiated access.4.1.1 Threat ModelThe threat model for the host agent is similar to that of existing softwareprotection mechanisms such as antivirus, host-based firewalls, and host-basedintrusion detection. As with these host-based systems, if an attacker hasalready achieved code execution privileges, it may be possible to evade ordisable the host agent. As described in Section 2,antivirus software contains many vulnerabilities that can be directly targetedby malware due to its complexity. By reducing the complexity of the host agentby moving detection into the network, it is possible to reduce thevulnerability footprint of host software that may lead to elevated privilegesor code execution.4.1.2 File Unique IdentifiersOne of the core components of the host agent is the file unique identifier (UID)generator. The goal of the UID generator is to provide a compact summary of a file. That summary is transmitted over the network to determine if an identical file has already been analyzed by the network service. One of the simplest methods of generating such a UID is a cryptographic hash of a file,such as MD5 or SHA-1. Cryptographic hashes are fast and provide excellent resistance to collision attacks. However, the same collision resistance also means that changing a single byte in a file results in completely different UID. To combat polymorphic threats, a more complex UID generator algorithmcould be employed. For example, a method such as locality-preserving hashing in multidimensional spaces [12] could be used track differences between two files in a compact manner.4.1.3 User InterfaceWe envision three majors modes of operation that affect how users interact withthe host agent that range from less to more interactive.Transparent mode: In this mode, the detection software iscompletely transparent to the end user. Files are sent into the cloud foranalysis but the execution or loading of a file is never blocked orinterrupted. In this mode end hosts can become infected by known malware butadministrators can use detection alerts and detailed forensic information toaid in cleaning up infected systems.Warning mode: In this mode, access to a file is blockeduntil an access directive has been returned to the host agent. If the fileis classified as unsafe then a warning is presented to the user instructingthem why the file is suspicious. The user is then allowed to make the decisionof whether to proceed in accessing the file or not.Blocking mode: In this mode, access to a file is blocked untilan access directive has been returned to the host agent. If the file isclassified as suspicious then access to the file is denied and the user isinformed with an error dialog.4.1.4 Other File Acquisition MethodsWhile the host agent is the primary method of acquiring candidate files andtransmitting them to the network service for analysis, other methods can alsobe employed to increase the performance and visibility of the system. Forexample, a network sensor or tap monitoring the traffic of a network may pullfiles directly out of a network stream using deep packet inspection (DPI)techniques. By identifying files and performing analysis before the file evenreaches the destination host, the need to retransmit the file to the networkservice is alleviated and user-perceived latencies can be reduced. Clearlythis approach cannot completely replace the host agent as network traffic canbe encrypted, files may be encapsulated in unknown protocols, and the networkis only one source of malicious content.4.2 Network ServiceThe second major component of the architecture is the network serviceresponsible for file analysis. The core task of the network service is todetermine whether a file is malicious or unwanted. Unlike existing systems,each file is analyzed by a collection of detection engines. That is, each fileis analyzed by multiple detection engines in parallel and a finaldetermination of whether a file is malicious or unwanted is made byaggregating these individual results into a threat report.4.2.1 Detection EnginesA cluster of servers can quickly analyze files using multiple detectiontechniques. Additional detection engines can easily be integrated into anetwork service, allowing for considerable extensibility. Such comprehensiveanalysis can significantly increase the detection coverage of malicioussoftware. In addition, the use of engines from different vendors usingdifferent detection techniques means that the overall result does not rely tooheavily on a single vendor or detection technology.A wide range of both lightweight and heavyweight detection techniques can beused in the backend. For example, lightweight detection systems like existingantivirus engines can be used to evaluate candidate files. In addition,more heavyweight detectors like behavioral analyzers can also be used.A behavioral system executes a suspicious file in a sandboxed environment(e.g., Norman Sandbox [22], CWSandbox [6]) or virtualmachine and records host state changes and network activity. Such deepanalysis is difficult or impossible to accomplish on resource-constraineddevices like mobile phones but is possible when detection is moved todedicated servers. In addition, instead of forcing signature updates to everyhost, detection engines can be kept up-to-date with the latest vendorsignatures at a central source.Finally, running multiple detection engines within the same service providesthe ability to correlation information between engines. For example, if adetector finds that the behavior of an unknown file is similar to that of anfile previously classified as malicious by antivirus engines, the unknown filecan be marked as suspicious [23].4.2.2 Result AggregationThe results from the different detection engines must be combined todetermine whether a file is safe to open, access, or execute. Severalvariables may impact this process.First, results from the detection engines may reach the aggregator atdifferent times - if a detector fails, it may never return any results. Inorder to prevent a slow or failed detector from holding up a host, theaggregator can use a subset of results to determine if a file is safe.Determining the size of such a quorum depends on the deployment scenario andvariables like the number of detection engines, security policies, and latencyrequirements.Second, the metadata returned by each detector may be different so thedetection results are wrapped in a container object that describes how thedata should be interpreted. For example, behavioral analysis reports may notindicate whether a file is safe but can be attached to the final aggregationreport to help users, operators, or external programs interpret the results.Lastly, the threshold at which a candidate file is deemed unsafe or maliciousmay be defined by security policy of the network's administrators. For example, some administrators may opt for a strict policy where a single engineis sufficient to deem a file malicious while less security-conscious administrators may require multiple engines to agree to deem a file malicious.We discuss the balance between coverage and confidence further in Section 7.The result of the aggregation process is a threat report that is sent to thehost agent and can be cached on the server. A threat report can contain a varietyof metadata and analysis results about a file. The specific contents of the reportdepend on the deployment scenario. Some possible report sections include: (1)an operation directive; a set of instructions indicating the action to beperformed by the host agent, such as how the file should be accessed, opened, executed,or quarantined; (2) family/variant labels; a list of malware family/variantclassification labels assigned to the file by the different detection engines; and (3)behavioral analysis; a list of host and network behaviors observed duringsimulation. This may include information about processes spawned, files andregistry keys modified, network activity, or other state changes.4.2.3 CachingOnce a threat report has been generated for a candidate file, it can be storedin both a local cache on the host agent and in a shared remote cache on theserver. This means that once a file has been analyzed, subsequent accesses to that file by the user can be determined locally without requiring network access. Moreover, once a single host in a networkhas accessed a file and sent it to the network service for analysis, anysubsequent access of the same file by other hosts in the network can leverage the existingthreat report in the shared remote cache on the server. Cached reports storedin the network service may also periodically be pushed to the host agentto speed up future accesses and invalidated when deemed necessary.4.3 Archival and Forensics ServiceThe third and final component of the architecture is a service that providesinformation on file usage across participating hosts which can assist in post-infection forensic analysis. While some forensicstracking systems [14,8] providefine-grained details tracing back to the exact vulnerable processes and system objects involved in an infection, they are often accompanied by high storagerequirements and performance degradation. Instead, we opt for a lightweightsolution consisting of file access information sent by the host agent and stored securely by the network service, in addition to the behavioral profiles of malicioussoftware generated by the behavioral detection engines. Depending on the privacy policy of organization, a tunable amount of forensics informationcan be logged and sent to the archival service. For example, a more security conscious organization could specify that information about every executable launch be recorded and sent to the archival service. Another policy might specify that only accesses to unsafe files be archived without any personallyidentifiable information.Archiving forensic and file usage information provides a rich information sourcefor both security professionals and administrators. From a security perspective, tracking the system events leading up to an infection can assistin determining its cause, assessing the risk involved with the compromise, and aiding in any necessary disinfection and cleanup. In addition, threat reports from behavioral engines provide a valuable source of forensic data asthe exact operations performed by a piece of malicious software can beanalyzed in detail. From a general administration perspective, knowledge ofwhat applications and files are frequently in use can aid the placement of filecaches, application servers, and even be used to determine the optimal number oflicenses needed for expensive applications.Consider the outbreak of a zero-dayexploit. An enterprise might receive a notice of a new malware attack and wonderhow many of their systems were infected. In the past, this might requireperforming an inventory of all systems, determining which were runningvulnerable software, and then manually inspecting each system. Using theforensics archival interface in the proposed architecture, an operator couldsearch for the UID of the malicious file over the past few months andinstantly find out where, when, and who opened the file and what maliciousactions the file performed. The impacted machines could then immediately bequarantined.The forensics archive also enables retrospective detection. Thecomplete archive of files that are transmitted to the network service may bere-scanned by available engines whenever a signature update occurs.Retrospective detection allows previously undetected malware that has infecteda host to be identified and quarantined.
5 CloudAV ImplementationTo explore and validate the proposed in-cloud antivirus architecture, weconstructed a production quality implementation called CloudAV. Inthis section we describe how CloudAV implements each of the three maincomponents of the architecture.5.1 Host AgentWe implement the host agent for a variety of platforms including Windows 2000/XP/Vista, Linux 2.4/2.6, and FreeBSD 6.0+. The implementation of the hostagent is designed to acquire executable files for analysis by the in-cloudnetwork service, as executables are a common source of malicious content.We discuss how the agent can be extended to acquire DLLs, documents, and other common malcode-bearing files types in Section 7.While the exact APIs are platform dependent (CreateProcess onWin32, execve syscall on Linux 2.4, LSM hooks on Linux 2.6, etc), the hostagent hooks and interposes on system events. This interposition is implementedvia the MadCodeHook [16] package on the Win32 platform and via the Dazuko [24] framework for the other platforms. Process creation events are interposed upon by the host agent to acquire and process candidate executables before they are allowed to continue. In addition, filesystem events are captured to identify new files entering a host and preemptively transfer them to the network service before execution to eliminate any user-perceived latencies.As motivating factors of our work include the complexity and security risks involved in running host-based antivirus, the host agent was designed to be simple and lightweight, both in code size and resource requirements. The Win32 agent is approximately 1500 lines of code of which 60% is managed code, further reducing the vulnerability profile of the agent.The agent for the other platforms is written in python and is under 300 lines of code.While the host agent is primarily targeted at end hosts, our architecture isalso effective in other deployment scenarios such as mail servers. Todemonstrate this, we also implemented a milter (mail filter) frontend for use with mail transfer agents (MTAs) such as Sendmail and Postfix to scan all attachments on incoming emails. Using the pymilter API, the milter frontend weighs in at approximately 100 lines of code.5.2 Network ServiceFigure 4:Screen captures of the detection engine VM monitoring interface (a) and the web management portal which provides access to forensic data and threat reports (b). (a)(b) The network service acts as a dispatch manager between the host agent and thebackend analysis engines. Incoming candidate files are received, analyzed, anda threat report is returned to the host agent dictating the appropriate actionto take. Communication between the host agent and the network service uses aHTTP wire protocol protected by mutually authenticated SSL/TLS. Between thecomponents within the network service itself, communication is performed via apublish/subscribe bus to allow modularization and effective scalability.The network service allows for various priorities to be assigned to analysisrequests to aid latency-sensitive applications and penalize misbehaving hosts.For example, application and mail scanning may take higher analysis prioritythan background analysis tasks such as retroactive detection (described inSection 7). This also enables the system to penalize ortemporarily suspend misbehaving hosts than may try to submit many analysisrequests or otherwise flood the system.Each backend engine runs in a Xen virtualized container, which offerssignificant advantages in terms of isolation and scalability. Given thenumerous vulnerabilities in existing antivirus software discussed inSection 2, isolation of the antivirus engines from therest of the system is vital. If one of the antivirus engines in the backend istargeted and successfully exploited by a malicious candidate file, thevirtualized container can simply be disposed of and immediately reverted to aclean snapshot. As for scalability, virtualized containers allows the networkservice to spin up multiple instances of a particular engine when demand forits services increase.Our current implementation employs 12 engines: 10 traditional antivirusengines (Avast, AVG, BitDefender, ClamAV, F-Prot, F-Secure, Kaspersky, McAfee,Symantec, and Trend Micro) and 2 behavioral engines (Norman Sandbox andCWSandbox). The exact version of each detection engine is listed inFigure 1(a). 9 of the backend engines run in a Windows XPenvironment using Xen's HVM capabilities while the other 3 run in a GentooLinux environment using Xen domU paravirtualization. Implementing eachparticular engine for the backend is a simple task and extending the backendwith additional engines in the future is equally as simple. For reference, theamount of code required for each engine is 42 lines of python code on averagewith a median of 26 lines of code.5.3 Management InterfaceThe third component is a management interface which provides access to theforensics archive, policy enforcement, alerting, and report generation. Theseinterfaces are exposed to network administrators via a web-based managementinterface. The web interface is implemented using Cherrypy, a python web development framework. A screen capture of the dashboard of the managementinterface is depicted in Figure 4.The centralized management and network-based architecture allows foradministrators to enforce network-wide policies and define alerts when thosepolicies are violated. Alerts are defined through a flexible specificationlanguage consisting of attributes describing an access request from the hostagent and boolean predicates similar to an SQL WHERE clause. The specificationlanguage allows for notification for triggered alerts (via email, syslog,SNMP) and enforcement of administrator-defined policies.For example, network administrators may desire to block certain applicationsfrom being used on end hosts. While these unwanted applications may not beexplicitly malicious, they may have a negative effect on host or networkperformance or be against acceptable use policies. We observed several classesof these potentially unwanted applications in our production deploymentincluding P2P applications (uTorrent, Limewire, etc) and multi-player gaming(World of Warcraft, online poker, etc). Other policies can be defined toreinforce prudent security practices, such as blocking the user from executingattachments from an email application.
6 EvaluationIn this section, we provide an evaluation of the proposed architecture throughtwo distinct sources of data. The first source is a dataset of malicioussoftware collected over a period of a year. Using this dataset, we evaluatethe effectiveness of N-version protection and retrospective detection. We alsoutilize this malware dataset to empirically quantify the size of vulnerabilitywindow.The second data source is derived from a production deployment of the systemon a campus network in computer labs spanning multiple departments for aperiod of over 6 months. We use the data collected from this deployment toexplore the performance characteristics of CloudAV. For example, we analyzethe number of files handled by the network service, the utility of the cachingsystem, and the time it takes the detection engines to analyze individualfiles. In addition, we use deployment data to demonstrate the forensicscapabilities of the approach. We detail two real-world case studies from thedeployment, one involving an infection by malicious software and one involvinga suspicious, yet legitimate executable.Figure 5:The average detection coverage for the various datasets (a) and thecontinuous coverage over time (b) when a given number of engines are used inparallel.Engines3 Months1 Month1 Week173.9%63.1%59.6%287.7%81.0%77.6%392.0%87.8%84.8%493.8%90.9%88.4%594.8%92.4%90.5%695.4%93.4%91.8%795.9%94.0%92.8%896.2%94.5%93.5%996.5%94.8%94.0%1096.7%95.0%94.4%
(a)(b)6.1 Malware Dataset ResultsThe first component of the evaluation is based on a malware dataset obtainedthrough Arbor Network's Arbor Malware Library (AML) [20]. AML iscomposed of malware collected using a variety of techniques such asdistributed darknet honeypots, spam traps, and honeyclient spidering. The useof a diverse set of collection techniques means that the malware samples aremore representative of threats faced by end hosts than malware datasetscollected using only a single collection methodology such asNepenthes [3]. The AML dataset used in this paperconsists of 7220 unique malware samples collected over a period of one year(November 12th, 2006 to November 11th, 2007). An average of 20 samples werecollected each day with a standard deviation of 19.6 samples.6.1.1 N-Version ProtectionWe used the AML malware dataset to assess the effectiveness of a setof heterogeneous detection engines. Figure 5(a) and (b)show the overall detection rate across different time ranges of malwaresamples as the number of detection engines is increased. The detection rateswere determined by looking at the average performance across all combinationsof N engines for a given N. For example, the average detection rate across allcombinations of two detection engines over the most recent 3 months of malwarewas 87.7%.Figure 5(a) demonstrates how the use of multipleheterogeneous engines allows CloudAV to significantly improve the aggregatedetection rate. Figure 5(b) shows the detection rate overmalware samples ranging from one day old to one year old. The graph shows howusing ten engines can increase the detection rate for the entire year-long AML datasetas high as 98%.The graph also reveals that CloudAV significantly improves the detection rate of more recent malware. When a single antivirus engine is used, the detection rate degradesfrom 82% against a year old dataset to 52% against a day old dataset (adecrease of 30%). However, using ten antivirus engines the detection coverageonly goes from 98% down to 88% (a decrease of only 10%). These results showthat not only do multiple engines complement each other to provide a higherdetection rate, but the combination has resistance to coverage degradation asthe encountered threats become more recent. As the most recent threats are typicallythe most important, a detection rate of 88% versus 52% is a significantadvantage.Another noticeable feature of Figure 5 is the decrease inincremental coverage. Moving from 1 to 2 engines results in a large jump indetection rate, moving from 2 to 3 is smaller, moving from 3 to 4 is evensmaller, and so on. The diminishing marginal utility of additional enginesshows that a practical balance may be reached between detection coverage andlicensing costs, which we discuss further in Section 7.In addition to the averages presented in Figure 5, theminimum and maximum detection coverage for a given number of engines is ofinterest. For the one week time range, the maximum detection coverage when using only a single engine is 78.6% (Kaspersky) and the minimum is39.7% (Avast). When using 3 engines in parallel, the maximum detectioncoverage is 93.6% (BitDefender, Kaspersky, and Trend Micro) and the minimum is 69.1% (ClamAV, F-Prot, and McAfee). However, the optimal combination of antivirus vendors to achieve the most comprehensive protection against malware may not be a simple measure of total detection coverage. Rather, a number of complex factors may influence the best choiceof detection engines, including the types of threats most commonly faced by the hosts being protected, the algorithms used for detection by a particular vendor, the vendor's response time to 0-day malware, and the collection methodology and visibility employed by the vendor to collect new malware.6.2 Retrospective DetectionWe also used the AML malware dataset to understand the utility ofretrospective detection. Recall that retrospective detection is the ability touse historical information and archived files stored by CloudAV to retrospectively detect andidentify hosts infected that with malware that has previously goneundetected. Retrospective detection is an especially important post-infectiondefense against 0-day threats and is independent of the number or vendor ofantivirus engines employed. Imagine a polymorphic threat not detected by anyantivirus or behavioral engine that infects a few hosts on a network. In thehost-based antivirus paradigm, those hosts could become infected, have theirantivirus software disabled, and continue to be infected indefinitely. In the proposed system, the infected file would be sent to the network servicefor analysis, deemed clean, archived at the network service, and the hostwould become infected. Then, when any of the antivirus vendors update theirsignature databases to detect the threat, the previously undetected malwarecan be re-scanned in the network service's archive and flagged as malicious.Instantly, armed with this new information, the network service can identifywhich hosts on the network have been infected in the past by this malware fromits database of execution history and notify the administrators with detailedforensic information.Figure 6:Cumulative distribution function depicting the number of days betweenwhen a malware sample is observed and when it is first detected by the McAfeeantivirus engine.Retrospective detection is especially important as frequent signature updatesfrom vendors continually add coverage for previously undetected malware. Usingour AML dataset and an archive of a year's worth of McAfee DAT signature files(with a one week granularity), we determined that approximately 100 newmalware samples were detected each week on average (with a standard deviationof 57) by the McAfee updates. More importantly, for those samples that wereeventually detected by a signature update (5147 out of 7220), the average timefrom when a piece of malware was observed to when it was detected (i.e. thevulnerability window) was approximately 48 days. A cumulative distributionfunction of the days between observation and detection is depicted inFigure 6.6.3 Deployment ResultsWith the aid of network operations and security staff we deployed CloudAVacross a large campus network. In this section, we discuss results based onthe data collected as a part of this deployment.6.3.1 Executable EventsFigure 7:Executable launches (a) and unique executable launches (b) per dayover a one month period in a representative sample of 50 machines in thedeployment. (a)(b) One of the core variables that impacts the resource requirements of thenetwork service is the rate at which new files must be analyzed. If this rateis extremely high, extensive computing resources will be required to handlethe analysis load. Figure 7 shows the number of total executionevents and unique executables observed during a one month period in auniversity computing lab.Figure 7 shows that while the total number of executables run byall the systems in the lab is quite large (an average of 20,500 per day), thenumber of unique executables run per day is two orders of magnitude smaller(an average of 217 per day). Moreover, the number of unique executables islikely inflated due to the fact that these machines are frequently used bystudents to work on computer science class projects, resulting in a largenumber of distinct executables with each compile of a project. A more static,non-development environment would likely see even less unique executables.We also investigated the origins of these executables based on the file pathof 1000 unique executables stored in the forensics archive.Table 1 shows the break down of these sources. The majorityof executables originate from the local hard drive but a significant portionwere launched from various network sources. Executables from the tempdirectory often indicate that they were downloaded via a web browser andexecuted, contributing even more to networked origins. In addition, anon-trivial number of executables were introduced to the system directly fromexternal media such as a CDROM drive and USB flash media. This diversityexemplifies the need for a host agent that is capable of acquiring files froma variety of sources.
0852c4b9a8
www free download english songs
free download flash 8.0 full version