4 0 0 T o t t e n P o n d R o a d W a l t h a m, M A 0 2 4 5 1 7 8 1. 8 1 0. 4 3 2 0 w w w. v i e w f i n i t y. c o m Utilizing Pervasive Application Monitoring and File Origin Tracking in IT Security
TABLE OF CONTENTS Introduction 3 Malware Inhibitors 3 Furthering Default Deny 3 Managing Unknown Software 3 The Role of File Origin 4 Why Automating Whitelists Matters 5 Automation Via Designation of a Trusted Sources File Origin 6 Least Privilege Consideration 6 Conclusion 7
Introduction The vulnerability of computer systems to malware has spawned a substantial and growing industry in anti-virus software, intrusion detection systems, and other defenses to protect networks from malicious programs. Faced with a malware environment that is constantly evolving and changing, however, it is a continuing challenge for vendors to keep their products up-to-date and effective against the newest threats. For businesses that find it too risky to rely solely on these measures for protection against malware, the more stringent option of application whitelisting ( default deny model) is growing in popularity. Malware Inhibitors Antivirus programs by default allow new executables on machines except for those that have been previously identified as malware. This has the benefit of being extremely easy for end-users and system administrators: they simply install the antivirus software on their machines and it automatically detects and removes known malware, without requiring further user intervention and without inhibiting the users ability to install many programs. Application whitelisting mechanisms, by contrast, typically do not allow any new executables to be installed except for those that are pre-approved (or whitelisted). This much more restrictive form of security has the benefit of protecting against a wider range of new and unknown malware but also requires significantly more involvement on the part of system administrators and causes greater inconvenience for individual users seeking to download new software. Furthering Default Deny For some system administrators, this degree of control and stringent limiting of allowable software may be desirable, but for many others strict whitelisting rules may be difficult to maintain and can constrain users ability to do their jobs. The major difficulty in whitelisting maintenance is that the list is dynamic and in large IT environments there are hundreds and even thousands of new executables which need to be categorized each day. One of the possible means of mitigating this daunting task is to automate how whitelisting policies are manage; one based on so called trusted sources. For instance, any new software that is signed by vendor X will be automatically whitelisted because we trust the signature of this vendor, or another software package is trusted because it was installed by a trusted person from within the IT organization. One of the limitations of the trusted source approach is that during its lifetime, a file can change ownership, such as its location on the network and other attributes and thus will lose its alignment with the trusted universe. For security and manageability it is important to be able to track a file s history and assign its true origin: we need to know from which site or USB this file was initially downloaded, when it was done and who did it. Technology that automatically tracks the origins of new and existing software will help automate the administrator s task of maintaining the whitelist and enable more accurate forensic investigation of malware incidents. This technology has the potential to strengthen security, particularly within whitelisted environments, though it may also be limited by the granularity with which it can identify file origins. For instance, it is not always possible to define a URL from which the software was downloaded. A complimentary approach is to implement a means of greylisting for applications that are not explicitly whitelisted or blacklisted, but instead are permitted to run in a restricted manner, or with limited access, thus being potentially less harmful to the core infrastructure and data of enterprise. Now you have achieved the optimal balance of ensuring that user productivity is not disrupted while also still operating a secure environment. Managing Unknown Software Malware is rampant in the computing world, with malicious programs infecting computers through a variety of channels, including email, websites, and USB connections. Microsoft s Security Intelligence Report (SIR) notes that it can sometimes be difficult for even experienced Internet users to avoid coming into contact with malware. The
cybercriminals who publish and distribute malware devote significant effort to convincing or tricking Internet users into clicking links that lead to malware, or that download malicious attachments or applications. Even familiar and trusted websites can sometimes be exploited by attackers to distribute malware using tactics such as drive-by downloads. 1 A 2010 report by Panda Security found that 25 percent of new worms were designed to spread via USB devices, with 27 percent of more than 10,000 surveyed companies confirming that they had identified infections which could be traced back to USB connections. So far, these types of infection are still outnumbered by those that spread via email, but it is a growing trend, PandaLabs reported. 2 Clearly, malware from a variety of sources continues to target computer systems worldwide, but, of course, there is also a significant quantity of non-malicious, useful software that organizations may wish to allow on their networks. Whitelisting software may help an organization avoid unwanted malware, but it may also constrain how quickly and the extent to which employees can make use of non-malicious, new programs that would aid them in their work. A report from the Public Interest Advocacy Centre points out that in some cases whitelisting may be too restrictive and overly broad, infringing on the functionality of a computer and the network [D]epending on who is managing the whitelist and vetting new or updated software, it may take several weeks for new or updated software to be added to the whitelist. 3 Security expert Bruce Schneier echoes this concern, writing, The average corporate IT department doesn't have a good idea of what software is running on all the computers within the corporation, and doesn't want the administrative overhead of managing all the change requests. 4 Reducing the administrative overhead needed to implement application whitelisting is a major motivation for tracking file origins. Maintaining information on the source of all software downloaded on a system can allow organizations to automate, to some extent, the role of the system administrator in whitelisting, blacklisting or even greylisting new programs. This information may also play a vital role in helping investigate any security breaches or malware problems that arise in a system by identifying the source of the malicious executables. The Role of File Origin Tracking File origin tracking is intended as a means of enabling a combination of the convenience of default allow defenses, like anti-virus software, with the effectiveness of default deny defenses, such as application whitelisting. The central use case driving file origin tracking technology is that by intercepting installation attempts, as well as changes in the file attributes, the software has the capability to automatically assign a trusted or untrusted status to the application, based on the original event that introduced the file into a corporate environment. For instance, an organization may decide to differentiate between programs downloaded via trusted processes, or signed by certain vendors, from those downloaded from the Internet, or via USB devices. By distinguishing between different categories of origins that can be designated to whitelists, greylists, or blacklists, companies may be able to automate a good portion of the whitelisting administrative overhead. Additionally, this information can be leveraged in the event of a security breach. If the program responsible for the breach can be identified, the origin data may then lend itself to better forensic analysis of the original source of that malware and can be used to update security policies. 1 Microsoft Security Intelligence Report, vol. 14. Available from http://download.microsoft.com/download/e/0/f/e0f59be7-e553-4888-9220-1c79cbd14b4f/microsoft_security_intelligence_report_volume_14_english.pdf 2 25% of new worms in 2010 are designed specifically to spread through USB devices Panda Security press release. Aug. 26, 2010. Available from http://press.pandasecurity.com/news/25-of-new-worms-in-2010-are-designed-specifically-to-spread-through-usbdevices/#sthash.gbhom2co.ic6wwalc.dpuf 3 Janet Lo. Whitelisting for Cyber Security: What It Means for Consumers. Public Interest Advocacy Centre. November 2010. Available from www.piac.ca/files/whitelisting_final_nov2010.pdf 4 Bruce Schneier. Is Antivirus Dead? November 10, 2009. Available from http://www.schneier.com/blog/archives/2009/11/ is_antivirus_de.html.
The goal of combining file origin tracking technology with whitelisting mechanisms is to introduce some greater degree of automation to whitelisting and reduce the need for manual configuration and management by IT personnel. Keeping track of the source of new files what website they were downloaded from, what vendor signed the installation package, etc. makes it easier to make automatic decisions for classifying whitelisting, greylisting, and blacklisting of new executables. For instance, this could allow for programs whose origin is signed by a trusted vendor or distributed by an IT department s internal software distribution system or System Center Configuration Manager to stay as whitelisted during all changes in file origin, location etc. regardless of any changes, the hash and details of origin will remain true. In this manner, an organization may simply designate trusted vendors and internal installation procedures and reduce the need for IT involvement in the whitelisting procedures, enabling greater flexibility and more rapid updating of systems than a straightforward default-deny whitelisting mechanism could. As a precursor to whitelisting, many of our customers initially use file history in a monitoring mode, which shows what applications are actually in use. The monitoring lets you know if these applications require admin rights, and can build trusted software source locations such as SCCM, Altiris, CA, LANDesk, trusted OS image, network shares, publishers, etc. It s a logical approach for this type of project because the monitoring ensures users aren t shut off from using an application they need. Why Automating Whitelists Matters While whitelisting mechanisms are gaining some traction in the corporate world, and were even cited in a 2010 SANS Institute report as the most effective way to significantly reduce the impact of malware in today s environment, 5 the overhead associated with their implementation and maintenance is significant. This is evident even in the most successful commercial deployments of whitelisting app stores for smartphones and tablet devices. Apple iphones and ipads operate on a fundamentally whitelist-based model, in which users may only download onto their devices apps that have been pre-approved by Apple. These app stores allow Apple the opportunity to screen for any security threats, as well as other unwanted content, and have enjoyed considerable success as a crucial component of the wildly popular Apple mobile devices. However, they have also come in for criticism, not just because these stores limit users ability to download programs and force developers to give over a portion of their app revenue to Apple, but also because the approval or whitelisting process can be extremely time-consuming and resource-intensive. According to records filed with the Federal Communications Commission (FCC) in 2009, Apple then employed more than forty full-time app reviewers, and each application had to be independently reviewed by two different reviewers to ensure uniformity. The filings with the FCC s Wireless Telecommunications Bureau also noted that 95 percent of Apple s app applications are approved within two weeks of their submission. 6 In 2012, many app developers complained that the approval process was running longer up to as much as three weeks in the months leading up to the end-of-year holidays. 7 In other words, even with the significant resources Apple devotes to staffing its app review team, it has at times proved challenging for the company to keep up with the demands of developers and the timeline desired by its customers. The security advantages of this model, however, were lauded in a 2011 Symantec report on mobile device security, which found that the ios security model is well designed and has thus far proven largely resistant to most types of attacks. 8 5 Jim Beechey. Application Whitelisting: Panacea or Propaganda? SANS Institute. December 2010. Available from https:// www.sans.org/reading_room/whitepapers/application/application-whitelisting-panacea-propaganda_33599. 6 Apple Answers the FCC s Questions. August, 2009. Available from: http://www.apple.com/hotnews/apple-answers-fccquestions/. 7 Tricia Duryee. The Latest Long Apple Line: Developers Waiting for App Approval. All Things D. November 8, 2012. Available from: http://allthingsd.com/20121108/the-latest-long-apple-line-developers-waiting-for-app-approval/. 8 Carey Nachenberg. New Symantec Research: The Current State of Mobile Device Security. June 27, 2011. Available from http:// www.symantec.com/connect/blogs/new-symantec-research-current-state-mobile-device-security.
Translating this whitelisting security model, which has been used so successfully in Apple consumer devices, to the computer systems of the corporate world requires careful evaluation of the approval process for additions to the whitelist. Since whitelisting programs for internal corporate use is not as directly profitable and central to the business of most companies as whitelisting new apps is to Apple, it is unlikely that many organizations will be willing or able to devote the same level of resources to the approval of new files in a corporate setting. Still, the security benefits of a whitelisting model may appeal to many organizations interested in improving their internal system security to reinforce more automated defenses like antivirus programs. In order to enable more companies to act on this interest, though, it will be essential to automate whitelisting mechanisms, bringing them more in line with the maintenance requirements and ease-of-use of antivirus software. Automation via Designation of a Trusted Sources File Origin One important step in automating whitelisting technologies for greater ease-of-use is allowing organizations to establish the library of trusted sources and whitelisting files by knowing the true origin. Without knowing the history of a file, however, it is very difficult to ascertain whether or not it should be a trusted source. This is one crucial function of file origin tracking in implementing whitelisting: it allows organizations to automatically whitelist, greylist, or blacklist new files based on their source or origin rather than having to review each one individually. Furthermore, keeping records of which websites new programs are downloaded from can help mitigate malware infections. The Microsoft SIR notes, Attackers often use websites to conduct phishing attacks or distribute malware. Malicious websites typically appear to be completely legitimate and often provide no outward indicators of their malicious nature, even to experienced computer users, according the Microsoft SIR, volume 14. It continues, In many cases, these sites are legitimate websites that have been compromised by malware, SQL injection, or other techniques in an effort by attackers to take advantage of the trust users have invested in them. 9 Even when designating trusted sources is insufficient to prevent malware installation for instance, when legitimate sites are compromised tracking file origins may enable more effective, rapid investigation of the incident by allowing administrators to immediately identify the source of the malware, track other installations from that same source, and block further downloads from that source. Least Privilege Consideration There is great danger if administrative rights are allowed in a whitelisting model: users that retain administrative rights may attempt to bypass or uninstall application control agents, and attackers may target the whitelisting mechanism to have bad code recognized as legitimate. Thus, it is a highly-regarded opinion among IT professionals that moving to a locked down environment and controlling rights on personal computers and servers is a crucial part of any security solution. Adhering to the principle of least privileges is in the best interest of all companies and is best depicted in the following use case: An end user, who has full administrative rights, receives an email containing a URL that points to a malicious executable which was hacked and signed with a well-known digital certificate. Since the signature is known to be good it is on the approved whitelist. Once that user clicks on the URL, malicious software is installed with file transfer enabled, and the web camera and remote terminal are activated. At this point, the company s assets and data are exposed. In a least privilege environment, using the example above, the user would not have local administrator rights. When the user clicks on the URL, the malicious software cannot be installed because administrative rights are required for the malicious code to register certain components. If file origin tracking is in place, the unclassified executable would be flagged and an indicated that it originated from the internet and assigned a low reputation score, and automatically blacklisting the executable. 9 Microsoft Security Intelligence Report, vol. 14. Available from http://download.microsoft.com/download/e/0/f/e0f59be7-e553-4888-9220-1c79cbd14b4f/microsoft_security_intelligence_report_volume_14_english.pdf
This use case outlines how controlling which applications are allowed to run in your environment through whitelisting, and reinforcing that protective layer by allowing standard administrative rights only, exemplify best practices for reducing security risks. Conclusion By improving the ease with which organizations can both designate trusted sources as well as investigate security breaches, file origin tracking has the potential to considerably lessen the burdens imposed by implementation of whitelisting solutions. By empowering companies to create customized whitelisting strategies and processes, depending on their desired degree of security and unique set of trusted sources, file origin tracking can also enhance the customizability of whitelisting technology, allowing for more tailored security solutions that harness the effectiveness of default deny defenses while reducing the resources needed for their implementation and maintenance.