Bit9

As security is moving into hardware, network cards, hard drive firmware and motherboards, are starting to look more and more like mini-Operating Systems. This is all the opposite direction to where the TransMeta promise would have taken us.

But from the security perspective, it appears that the security infrastructure that we have been building so far will be useless as well. This is something that is already happening with Virtualized Environments as people are expecting new tools and new technologies to be developed.

We can expect hardware components to be owned, participate in distributed attacks and permanently shut our ability to easily recover already at the hardware level.

How often would you be patching your firmware embedded web browser?

More software complexity will expose more bugs, more vulnerabilities, and will bring in more third party code to erstwhile monolithic code bases. It will be interesting to watch firmware updates performing automatic over the web updates. I wonder how will it inform the user of the impeding system reboot request? Let's assume for the moment that the time of trivial protections against random firmware flashing, and PDOS attacks are over.

Intel's Centrino Active Management, built a web server into your motherboard, allowing you to quite easily override the behavior of your hardware, firewall rules, etc., even when the machine is powered off. This is all quite alarming on the Cryptography mailing list. Ivan Krstic, one of the most influential security minds according to eWeek, has been quite severe in his keynote address at the FIRST 2008 conference in Vancouver. Obviously, all the rage is over advanced "features" that are now accessible to anyone even when the machine is powered off. I bet Ivan hasn't read Eric Filiol's piece from July's edition of VirusBulletin that talks about accessing RAM when the machine is powered off. Yes indeed, data continues to persist. Let's welcome a new set of spy movies.

From the Application Whitelisting perspective, this is a worthy opportunity, since who will not want to have the firmware image locked down? You just want the trusted components and their updates to reside in the hard to reach depths of your hardware. But to get there, we need to start promoting some basic standards and procedures. For example, this still seems to be quite relevant. For purpose built operating systems, firmware images and appliances, a control harness that limits the built-in OS to do only what it should, has to be a priority from the security aspect.

This was a particularly well thought out blog post from Threat Fire on whether whitelists will kill AV or work with them. It is a response to CNET writer Robert Vamosi's article  Defense in Depth column on whitelisting that quotes Bit9 CEO Patrick Morley. The Threat Fire writer talks about AV and whitelisting working together, with AV eventually - in the future -  becoming commoditized (JAMPoJ if you like silly jargon). When the writer talks about the whitelisting solutions sitting beside the "more exposed" whitelisting ones, I take it to mean that whitelisting will be the first line of defense at the endpoint - stopping malware and unauthorized software from running. In terms of when this will happen, there is  the ideal and then there is the real. When it comes to innovative technology like whitelisting, it will not be a wholesale change, but a more gradual one as the Threat Fire writer said.

Every other week unchecked POS systems end up costing organizations dearly. Credit card number from only one of Dave & Buster's restaurants rung as much as $600,000 in unauthorized charges. The culprit was unauthorized network sniffing software. This sounds very similar to Hannaford Brothers scenario. How much of card member's money needs to be spilled before users of POS systems realize that their devices are not meant for surfing internet and playing games?  They should rather be machines whose configuration needs to be locked down.

 Even more so Peter Tippett, VP at Verizon Business claims that 45% of all breaches have a POS element. He would know as Verizon Business is exclusive forensics investigator for Credit Card industry when these breaches happen.

Not to boast our own successes, but everyone should look up to what Marks & Spencers is doing in UK. All POS systems need to be locked down with application whitelisting products like Bit9 Parity.

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. 

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.