Bit9

In my last post, I graphed the introduction of software onto a new system.  In this post, I'll graph the risk that that software poses to an environment.

By introducing an unapproved application, end users seldom realize the risk that change could have to the network.  For example, a single user introducing an alternate web browser onto their computer might have a risk profile that looks like the graph below.  By itself, a single application on a single computer does not pose a huge threat to the network (unless of course that application is malicious in nature, but we will assume for now it is not).

(You can download a larger version here:  http://bit.ly/aXBFnE )

Over time, there may be patches or updates that need to be applied to the application, and because the end user is likely the only one who knows about this application, it is up to them to be responsible for applying these patches or updates.  In an attempt to address the lack of central patching and upgrading, many products now come with self-updating functionality that will either check at runtime or on a set schedule for these files.  Unfortunately, most end users are neither aware of the importance or the urgency with which some of these patches need to be applied.  Therefore, updates get postponed, versions get skipped, and vulnerable applications grow within the network.

Now the graph will move up the risk scale a bit because there is little control over this unknown web browser and there is a level of uncertainty about its patch level.  Depending upon the application that has been installed, the responsiveness of the publisher, and the timeliness of the patches can also bump up the risk level.  For example, Secunia reports that Firefox, a very common alternate browser, had to release patches for 115 vulnerabilities in 2008 (source:  http://bit.ly/cFAA4z ).  Comparatively, Internet Explorer, which IT has a fairly good grasp over patching, suffered from 31 in 2008.

(You can download a larger version here:  http://bit.ly/biXqpK )

This issue is only compounded by the fact that not only will users install an alternate web browser, but also install games, toolbars, media players, peer-to-peer tools, and a plethora of other programs either intentionally or unintentionally.

This final graph shows the compound level of risk that multiple machines introduce when they all have unwanted programs added to them.  It is very easy to see why unauthorized software is almost more of a concern these days than malicious software.

(You can download a larger version here:  http://bit.ly/ddF79Q )

All of these programs expose an organization to increased support costs as unwanted programs conflict with business-related applications, increase re-imaging costs as the easiest and most effective way to eliminate this software from an end user’s computer is to start from scratch, and increases the risk that a computer will be compromised with an attack on a vulnerable application.

Coupled with strong written policies, it is understandable why many organizations are turning towards methods that can apply tighter control around what software end users are able to introduce onto their systems.  Without a reasonable mechanism for attempting to inventory and patch unauthorized software, the best approach for IT is to prevent the introduction of these applications in the first place.

At Bit9, we talk with customers and prospects every day about the risk that unauthorized software introduces into an environment.  Some IT folks have a difficult time presenting to senior management what the actual threat to the environment is of users introducing programs like iTunes, Firefox, or Skype. They are so commonplace that we start to get the impression that they are benign!

I've put together some charts, that could be incorporated into a presentation, to help convey the message that any unmanaged application, especially if IT is unaware that it exists within the environment, is an exposure that should be addressed.

(You can download a larger version here:  http://bit.ly/8YxzqJ )

This graph illustrates the typical introduction of new software onto a freshly imaged system.  The bane to any of us who have ever spent days or weeks creating a pristine base image!  I think the important thing to note is that much of the "software pull" that happens over the lifetime of the computer, happens relatively early.  Within hours or days of a user being issued a system, they have re-introduced their favorite chat programs, music players, screen savers, and more.  Once the user is satisfied with the state of the software, then over the coming months and years, you have blips of software packages getting installed, or a package upgrading to a newer version.

Once new unknown software has been introduced, the attack surface of that system goes up significantly.  My next post will discuss this further.

Bit9's annual report on the Top Vulnerable Applications  for 2009 found that Adobe Acrobat, Flash Player, Reader and Shockwave showed high risk for arbitrary code execution, memory corruption and application crashing. Also rated highly vulnerable in NIST's database for 2009 were Apple Quicktime, Mozilla FireFox, Opera, RealPlayer, Sun Java and Trillian.

Microsoft's IE 6 and 7 received an "honorable mention" for a zero-day exploit that went unpatched for a period of time in August.  All applications on the list require end users to manually patch or upgrade the software to eliminate the vulnerability, and are extremely common on PCs at work and home.

Should enterprises use these apps? If it makes sense for the business - of course they should. Most businesses would find it hard not to use Adobe PDF, for instance.  And yet just today, SANS Institute's Internet Storm Center (ISC) reported that they'd received samples of a new rigged PDF document that hijacked PCs using a bug Adobe acknowledged Dec. 14.  See Gregg Keizer's story on it in ComputerWorld today. So if enterprises do in fact use these apps, they need to put some monitoring and controls in place to protect their business.

Enterprise  IT organizations that are not monitoring their endpoints have no reliable way to ensure that the patches for these applications have been properly applied.  We encourage organizations to monitor the applications being used by their end users to make sure first, that they know what is running and second, they know that they have been patched properly. And in the case of this "zero-day" attacks, IT needs to put controls in place to protect against these zero-day attacks in which no patches or fixes exist.

Organizations that take a layered approach can best protect themselves with: visibility across endpoints;  a centralized patch-management process;  and application whitelisting to prevent the use of unauthorized and potentially malicious software.
To read the report, click here

Welcome to my final posting in a series entitled "Are You Ready for Enterprise Application Whitelisting?" I hope these little snippets have been helpful and have assisted you in determining if your IT organization is mature enough to consider whitelisting - and if you would be able to take advantage of its benefits.

Today's post is one that I've seen many IT groups struggle with first-hand. It has to do with the complexity of modern security products and how much training they seem to require today. Lots of IT administrators simply are not equipped to effectively manage these overly-complicated security policies. Which leads us straight to the question:

Question 5: Is the security expertise required by endpoint protection suites too much?

Think about that one for a minute and ask yourself a few questions:

• Do you run an advanced desktop security suite that includes antivirus, personal firewall, HIPS, and other components?
• If not - why? What's holding you back?
• If so - are you really using all the components?
• If you aren't using everything - why did you buy such a comprehensive piece of software and not use it to full effectiveness?
  

The answer is almost always that most IT organizations simply are not ready or don't contain the skillsets to run and operate an advanced security tool that forces you to define cross-product policies that account for malicious behavior patterns and multi-layered protection schemes.

IT organizations have always been great at deploying AV because all they had to do was make sure that the AV packages was installed and up-to-date. They didn't have to decide what was secure and what wasn't.

But operating a HIPS solution or even a personal firewall today requires the operations team to be making decisions about the security policy that will have dramatic impacts on the ability for the organization to actually protect its systems and its data.

Usually what happens is the IT group gets one of these advanced desktop security products and then doesn't deploy it. So they've increased costs and decreased security, all at the same time.

If you are one of these people then you are absolutely ready to look at application whitelisting. Becuase with whitelisting, there are no complex security policies to understand. Simply choose the applications that your business should be running. Nothing else gets in.

If an application is found to contain a vulnerability - ban it. If an application fails to pass some basic security screens, stop it from being able to run. If you don't know what an application is, you never have to be concerned abnout judging its behavior because it simply will not be able to execute.

An application that can't execute can't do any damage.

I hope you've enjoyed these postings on application whitelisting and I really hope that you've learned something from it. We've learned a tremendous amount from our customers and what's enabled them to make the transition to a whitelisting environment. Now it's your turn to ask yourself one more time: are you ready for enterprise application whitelisting?

I'm writing my third posting in a series called "Are You Ready for Enterprise Application Whitelisting?" The purpose of these posts as I've mentioned previously is to help IT people understand if their processes and organization are advanced and mature enough to be ready for implementing whitelisting - and basically only letting software run on corporate PCs that has been pre-authorized.

My previous posts covered a couple questions, including "Is your IT staff stretched too thin?" and "Do you need better auditing, reporting, and compliance?" Both of these questions are related to the needs of the organization and the services IT provides. But our next checkpoint asks about the maturity of the systems that IT uses to manage PCs. So here it is:

Question 3: Are adequate software delivery (SMS, WSUS) systems in place?

So why do we ask this question? Well the reason is because if you have implemented good, strong processes for delivering software easily and efficiently to desktops, you are pretty much at the point where the next logical step for control would be to whitelist the software on those PCs.

Think about it this way. Most company's IT processes have matured over the years along a relatively consistent pattern:

1. Provisioning / Imaging: Make it easy to get a standard image of the operating system and core applications when a new PC is issued to an employee, without taking a lot of time.
   
2. Deployment / Delivery: Get new applications or updates to applications out to all the users without having an army of IT people carry CDs to each workstation one by one.
3. Patch Management: Every time a new vulnerability or exploit is announced, vendors rush to deliver patches. A smooth patch management process means you don't have to scramble to protect your PCs.

So once you have these three components, you have effectively achieved total control over pushing software out to your PCs. So what's next for you? What are you looking to achieve after control over "pushed software?"

The answer is control over "pulled software." Users will receive their provisioned PCs and use the apps that are pushed to them... but then they will get on the Internet and start downloading their own apps. And as powerful as your software deployment processes are, most organizations can not reach 100% coverage of the apps that their users need. So you have to rely on users being able to download apps for themselves so you don't have to send IT people to every user whenever they need something.

And now you've opened Pandora's box. Because you can't control what your users will install...

... unless you whitelist.

Because when you whitelist, you authorize your users to download certain apps, but they can't get whatever they want. This gives you control. 

We've just released our top 10 list of the most vulnerable applications for 2007. This is the second year we've put the list together, and it is focused on those applications that users tend to download. These apps are often very difficult for IT to see, let alone patch, and therefore represent unexpected and unquantified vulnerabilities in an enterprise IT environment.

To make it onto the list, the following criteria must be met. Each application:

1. Must run on Microsoft Windows
2. Must be well-known in the consumer space and frequently downloaded by individuals.
3. Must not be classified as malicious by enterprise IT organizations or security vendors
4. Must contain at least one critical vulnerability:
• first reported in June 2006 or after,
• registered in the U.S. National Institute of Standards and Technology’s (NIST) official vulnerability database at http://nvd.nist.gov, and
• with a severity rating of high (between 7.0-10.0) on the Common Vulnerability Scoring System (CVSS).
5. Relies on the end user, rather than a central administrator, to manually patch or upgrade the software to eliminate the vulnerability, if such a patch exists.

It is important to note that in most cases, the vendor or publisher of the applications on this list has already produced a patch for the particular vulnerability or vulnerabilities reported here. But at a company, there is usually no way that IT can ensure that the patch has been properly applied - that's requirement #5 on the list of criteria above.

Last year when we released this list, a lot of people commented on how we left off so much Microsoft software - some even going so far as to say that Microsoft sponsored this research! So let me be clear - this is entirely produced and financed by Bit9. The reason most Microsoft software doesn't make the list is because by now most companies have a pretty good process in place for identifying, patching, and fixing vulnerable Microsoft software. The same can not be said for apps like Firefox, iTunes, and other packages.

You can download the full list of vulnerable applications here which includes the specific versions, the vendors' solutions, the nature of the vulnerabilities, and references to the CVE numbers for the identified vulnerabilities. Also, you can learn what to do to help protect your company from vulnerable applications like these.

So without further ado, here are the apps on the list. Do you have a comment about it? Please submit!

1. Yahoo! Messenger 8.1.0.239 and earlier
2. Apple QuickTime 7.2
3. Mozilla Firefox 2.0.0.6
   
4. Microsoft Windows Live (MSN) Messenger 7.0, 8.0
5. EMC VMware Player (and other products) 2.0, 1.0.4
6. Apple iTunes 7.3.2
7. Intuit QuickBooks Online Edition 9 and earlier
8. Sun Java Runtime 1.6.0_X
9. Yahoo! Widgets 4.0.5 and previous
10. Ask.com Toolbar 4.0.2.53 and previous