Bit9

It may seem passé to be discussing an attack from 2008. Two years is an eternity in the cyberworld. But the incident discussed in a recent New York Times article (see also CNN) was a watershed moment worthy of revisiting.

In 2008, a flash drive was plugged into a laptop on an American military base. It contained the Agent.btz virus, and proceeded to propagate from device to device, machine to machine, planting its tentacles across both secure and non-secure networks within the government. Details of what information or what systems were compromised were never made public, but we know the attack was severe enough to warrant a security brief for the President of the United States. The effort to counter this attack was dubbed Operation Buckshot Yankee.

I was there, working with our government and civilian customers, when the DoD ban of all portable devices went into effect (it was later relaxed, but the initial ban was without exception across all their sub-agencies and contractors). All of the computer systems within the Defense Department were running the latest antivirus software with firewalls, intrusion detection, internet filtering, and advanced policy management settings. Millions, if not billions, of dollars had been spent on IT security. Yet one tiny device, with a payload less than 1MB, went undetected and wreaked havoc. All that money, manpower, and technology, and Uncle Sam was reduced to physically banning the use of USB sticks.

It reminds me of a Dr. Seuss story that I used to read to my kids, Yertle the Turtle. There’s a line in that story, “his burp shook the throne of the king”. One tiny turtle, at the bottom of a stack, caused the entire system to collapse. This flash drive “burp” got the attention of the highest levels of government. It’s as if a light bulb went off in the heads of the top brass, “This really happened? How could our cyber defenses be so ineffective? There has to be a better approach.”

I saw two things happen next. First, the collective recognition within the government that traditional “react-and-respond” security was ineffective against today’s cyber threats. New approaches, like the “proact-and-prevent” paradigm of whitelisting, were needed. Bit9 was already successful within the government sector, but this raised awareness to a new level.

The second thing that happened is, when the global ban of all things removable went out, the world didn’t end. It quickly evolved into more relaxed policies and selective/monitored exceptions, and it’s certainly not the ideal way I would recommend transforming a security posture. But under fire, it was necessary. The posture transformed from “let everything in and then see if it behaves badly” to “block everything until it is verified to be good”. That model has always been the way the government approaches personnel security, but it had not been applied to cyber security. People were so used to the old way of thinking about security that they feared change. This incident and the Operation Buckshot Yankee response showed that approval based protection works.

Whether you’re talking about people, or removable devices, or software, positive security is more effective than negative security.

Right now I'm flying back to Boston after visiting a prospect this week (so I’m literally at 30,00 feet) and an interesting event occurred before takeoff that I thought I’d share! 

The plane waits at the gate for many extra minutes and a man eventually runs on, presumably because our flight had waited for him.  As he boards, he hands the flight attendant five or six candy bars.  That seemed odd, but she thanked him and he wandered down the aisle, likely getting stuck in a middle seat.

What happened next sent me into a tizzy.  The flight attendant opens the “flight deck” door and hands each of the pilots one of the candy bars!  Maybe I’ve watched one too many movies, but that immediately struck me as a horrible idea.  What if both pilots eat them?!  Then I thought “maybe the flight attendant knows the man and trusts him.”  So I asked the flight attendant if that was the case and she said “no, I have no idea who he is.”  Outstanding….

In reality, however, what happened there is analogous to what happens to our users every day when they browse the web and check email.  Innocent-looking and even "corporate-branded" websites and emails entice them to “click here”, “download this”, or “install now” and almost all of it is garbage.

Really, I’m fine if the man had handed candy bars to everyone on the flight and everyone gets sick and rolls off the plane.  But whatever food goes into that cockpit had better be WHITELISTED!  :D

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

This article, man-buys-used-ipod-gets-60-pages-of-sensitive-military-data.ars, on Ars Technica made me both laugh and groan. The subject of the article purchased a second hand mp3 player. Apparently the former owner was using the device as a removable storage disk to ferry data around. Many of us have done exactly the same thing. The difference, however, is this data contains the names and personal details of US soldiers

The US government has many rules and processes that govern secure data. There is a wealth of information on this at the Federal Information Security Management Act (FISMA) NIST site.

We can guess at which rules and what processes the original owner violated to enable this breach. That exact rule broken isn't as important as recognizing this breach happened because it was possible in the first place. 

In the effort to get jobs done short cuts often are taken. I can certainly think of a scenario where, in a time crunch, this government employee took some secure data home so they could finish up their task over a weekend. His employer may have acknowledged the sensitive nature of the data he was working on and required that this data exist only on computers attached to a secure network that has no connection to the internet. Unfortunately that tempting front mounted USB port calls to people. They bring in their camera and music player, their USB keys and webcams. Heck they may even bring in their USB rocket launchers to blow a little steam at the end of a tough day.

This article isn't the first time that removable storage has led to data loss.  The massive TJX breach comes to mind. More recently the details of more than 6,000 prisoners was lost. Through malicious and accidental acts gigabytes of data leak out USB ports around the world.

Physically removing USB ports may work for some organizations. Some have even suggested epoxy as an answer. USB ports have their uses, though, and these tactics are often too extreme. Antivirus and application whitelisting software can prevent the running of malicious code from these devices but they don't adequately address data loss issues. 

What then is the answer? Whitelisting hardware is something that is still in its infancy but for this class of problems I think it shows a lot of promise. Selectively allowing USB devices by the device's serial number or by the logged in user allows a flexibility that none of the others solutions posses, not even epoxy. :)

I would love to hear your thoughts on these issues. Are there better solutions out there that we, the security industry, should be exploring?

 -- 

Ex post facto introduction - Since this is my first time blogging for Bit9 a quick introduction might be in order. My name is Naveed Ihsanullah. I have worked in the field of software development and security for the past fifteen years. I have always been a firm believer in white listing as a solution for IT infrastructure control and to the ever increasing glut of malware. After hearing about the exciting Parity product, I joined Bit9 in Autumn 2008 as a Development Architect.

Ever since Symantec CEO John Thompson's keynote at the RSA Conference this past April, there have been several stories that quote statistics claiming that there is more malware produced than bona-fide good code.  At first it sounds quite alarming, have the bad guys won?  Do bad citizens outnumber the good ones?  As most of us do not believe such alarmist hoopla, these claims merit some looking into.  There may be more and more criminals focusing on Internet theft out there, as the population grows and the opportunities for cyber crime increases.  However, it is questionable whether there is actually more malware produced than good software.

The Bit9 Global Software Registry database grew 300% in 2007.  From what we have seen, by collecting the world's software in this database and cataloguing it, is that the amount of malware has only doubled in that the same period, based on most aggressive of reports.  This leads me to believe that there is not more bad software out there than good software.

Yet, the story of faulty statistics keeps being retold. In InfoWorld, the reporter quoted Thompson as saying there was more malware than good software. In ComputerWorld it was written that only in one month more than 54,000 new applications were discovered (BTW, Bit9 discovered more applications in a single day).  The story said the majority of them were malicious and it attributed the data to Symantec's Community Watch.  What we are not told in this story is that this system is looking only at new and suspicious applications among Symantec Enterprise customers.  And it is ignoring all other uninteresting but good applications.  Think about suspicious apps as something a HIPS or a Behavioral engine would detect.  Does this mean that Symantec's Community Watch approach to discovering malware yields as much as 50% of false positives? 

What is clear, is that there is a significant growth in the quantity of malicious software, as all anti-virus vendors and analysts have spoken about. In fact, Gartner analyst Peter Firstbrook called it the "explosion of the malware universe" recently at the Gartner IT Security Summit Conference in Washington, DC.  The most important takeaway here is that to keep up with this flood of malware, a new set of tools is required.  Existing products will not suffice for much longer, as the industry and analysts are painfully aware, and as such there will be more and more stories and technologies exploring approaches, including whitelisting.

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?

Welcome to Part 4 of my series on "Are You Ready for Enterprise Application Whitelisting?" Lots of people have been reading about application whitelisting - or at least wondering if there are easier ways of protecting endpoints than removing administrative rights - and are trying to figure out if now is the time to take a look at whitelisting.

So I'm presenting a number of questions that you can ask yourself to evaluate if you are in fact ready for whitelisting. And today we're going to talk about your users. Because if you have ever tried to remove administrative rights from users you know that it's an all-or-nothing proposition.

This leads us to the next question you can use to determine if you are in fact ready for enterprise application whitelisting:

Question 4: Do your users need flexibility (you can't lock them down too tightly)?

Let's talk a little more about removing admin rights from Windows computers. The motivation for doing this is because presumably users who can control the administrative aspects of their PCs are more likely to mess them up and get into trouble. Furthermore, any malware that may start running on the PC would be running with the privileges of the user, and if that was not at an administrative level the malware would be much less likely to inflict serious damage on the machine.

But because of the way that admin rights are implemented and managed in Windows, you practically are left with a very limiting and very inflexible choice. Either: 

1. You can remove administrative rights from your users but every time they need to make a change you have to send an IT admin to their desks to help them, or
2. You can't remove administrative rights because of legacy applications or cultural issues, and they can do anything they want to their PCs.

Most companies will assess each department individually to decide if the costs of supporting installations (#1 above) are higher or lower than the costs of managing, cleaning, and protecting against malware and unauthorized software (#2 above). On average, companies put about 75% of their users in bucket #1 and remove admin rights, leaving the other 25% of users in bucket #2, with admin rights.

But these results really aren't practical and don't meet the goals of the organization. Because IT needs more flexibility. And users need more flexibility. Why should a user who is locked down not be allowed to install the Adobe Acrobat Reader themselves if that is a well-known, trouble-free, and perfectly reasonable application to install? Why does IT need to get involved every time that happens?

The truth is: they don't. They shouldn't. Your protection strategy should be more flexible than that, and that is exactly where whitelisting comes in. Authorize users to install specific apps. Nothing else gets through.

If your users' behaviors and needs are complex... if you don't want to be babysitting them every time they need a simple non-standard installation done... then you are probably ready to look at enterprise application writelisting.