How to Enable Local Admin Access without the Risk

June 16, 2011

In today’s Windows environment, end users are accustomed to having local administrator privileges which allow them to download a variety of applications and potentially misconfigure their PCs. While standard wisdom may be to simply solve the problem by revoking local administrator rights on users’ systems, the reality is that this may not be an option at all organizations. And removing local admin rights doesn’t address applications such as Google Chrome or browser plug-ins for which admin access isn’t required.Fortunately, there’s hope for IT administrators seeking to gain control over the Windows environment while still offering local admin rights to the user base – through application whitelisting. With application whitelisting, IT can gain power over what types of applications their users install and limit their access to under-the-hood controls that determine how well config¬ured the machine remains.



Sam: Hello, everyone and welcome to this Lumension webcast titled How to Enable Local Admin Access without the Risk. My name is Sam Erdheim and I'll be your moderator for today's event. In today's Windows environment end users are accustomed to having local administrative privileges. This allows them to download a variety of applications and potentially misconfigure their PCs. While some revoke local administrator's rights on user systems to reduce risk, the reality is that this may not be an option at all for all organizations. And removing local admin rights doesn't address applications such as Google Chrome or browser plugins for which admin access isn't required. Fortunately there's hope for IT administrators seeking to gain control over the Windows environment while still offering local admin rights to the user base. With application whitelisting IT can gain power over what types of applications their users install and limit their access to under the hood controls that determine how well configured the machine remains.
With us today to delve into this topic are two panelists Roger Grimes, Security Consultant, Author and Columnist. Rogers is a 23 year security industry veteran author, a co-author of 8 books and over 300 magazine articles on computer security. And also today with us is Chris Merritt, Director of Solution Marketing with Lumension where he leads the market positioning and strategies for the Lumension endpoint and data protection solutions. And Chris is also a regular contributor to the Lumension blog at Welcome gentlemen, thank you for joining us today.
Roger: Hello.
Chris: Thanks Sam.
Sam: In today's webcast Roger and Chris will examine why revoking local admin rights won't solve the problem of unwanted and malicious applications. How to promote productivity through local admin access while achieving control over configuration changes via application whitelisting. And they'll examine additional application whitelisting benefits. But before we move on to this discussion I'd like to open with a poll for the audience. What local admin privileges do your users have? A, fully restricted, b, limited rights, c, promotable rights, or d, no restrictions. Please make the most appropriate selection and we'll review those results in a few minutes. One housekeeping note I'd like to point out, audience members if you have any questions for Roger or Chris at any point please submit them via the questions tab at the top of the screen, and we will get to them in our Q& A session. And we'll try to answer as many questions as we can. And with that Roger will share the result after Roger's part of the discussion. Roger at this point I will turn it over to you.
Roger: Thanks, hello everyone. So I'm gonna talk about the local administrator dilemma which in all of us [inaudible 00:02:58] fighting for 20 years. But the first thing is what is a local administrator and a lot of people don't understand exactly how powerful that account is. I tell people to kinda explain the difference. I can give you if you're standard user full control to every file, folder, object, and resource, and permission on your computer and you're still not the same as a local administrator, you're still not as powerful. Local administrators can do so much more, they have all kinds of rights and privileges. Rights and privileges are things like log on locally, log on as a batch job, debug programs, take ownership of other files and folders and objects, create symbolic links, lots of different rights. And rights are things that are privileges that you give when you're doing log on authentication and a privilege like take ownership or create symbolic links, that's something you can do all the time. And it isn't just evaluated during authentication.
But rights and privileges are pretty powerful, I mean depending on what version of Windows you have there's somewhere around 18 to 20 of them and there's 8 or 9 of them act as part of the operating systems that are considered high risk. Meaning that if you have them even if you're not a local administrator, all the local administrators get all rights and privileges by default or can get them. But if you have one of those special eight or nine high risk privileges like access part of the operating system, debug programs that sort of stuff, you can become, or there's nothing that we can do to stop you from becoming local system and completely controlling the environment. So that's an important thing to remember is that local administrator is very, very powerful not just for rights and permissions like everybody thinks, but really they can do lots of stuff. They can add and delete users, they can take control of files, they can control log on policy, audit policy and all that sort of stuff. It's certainly not hyperbole to say that local admins can perform any system on the local system. And if by chance if they couldn't immediately they can change something to make sure they could do it. Local admins become local system and just do anything to the local system, they can modify the local system.
Although at least for the last 10 years many companies are saying you shouldn't be logged in as administrators all the time because it allows the bad guys and malware to act in those highly privileged security context. So at least for, if not for 20 years, at least for the last 10 years everyone's been saying you shouldn't be logged in as local admin all the time, that you should be logged in as a standard less privileged user most of the time doing internet browsing and picking up your email. And only log in as local admin when you need to change something. So the big question is why is so many computers and so many people still logged in as local admin all the time or the majority of the time? And certainly a lot of it has to do with the way that the older operating systems were made. Back in the old days of the first version of Windows XP and it was prior to that pretty much that's just the way they worked. 
In Windows 95 and 98 they just logged in as local admin, every user you created was a local admin, you could actually in Windows 95 and 98 you could escape around the login prompt and you would be in as a local admin. Even in Windows XP, in Windows 2008, and Windows 2003 and all that stuff, still it's very easy when you create additional users for them to become admin. It wasn't till actual Windows Server 2008 and Windows Vista that when you add additional users that it actually allowed them to be standard user by default. So all the way prior to Vista and Server 2008 as you added additional users they were pretty much put in the local admin group by default anyways. And because that was kind of the default that everybody, every user ended up in local admin, all of the developers ended up assuming that users had all full admin rights. How common was it forced to be troubleshooting something with the vendor and the vendor's like, "You're logged in as local admin right?" Because their developers had developed that program to be logged in as local admin or for the user running it to be logged in as local admin.
Sometimes even if it only had to modify maybe one protected registry key, or write files during [inaudible 00:07:24] into the system 32 directories or something. But so much software just kind of assumed you're a local admin that's the way that it was written. It was so bad one of the best examples I can remember is I've run an older version of QuickBooks at home and it requires that the logged on user that's trying to do an invoice or to check accounts payable be a member of the domain admins group. So in the older version of QuickBooks you had to be a domain admin, had to be in the group, you couldn't just have full rights and control of the system. You couldn't just have full rights to QuickBooks that literally upon start-up check to see does your user account belong in the local administrators group, in the domain administrators group before it would allow you to do an accounts payable invoice entry, it was insane. 
Well not only that but because all the software kind of required it and the operating systems kind of made it easy you had a lot of companies that got used to that, that's just how everything worked. And if they tried to kind of take that away and go to the standard user or at least privilege user security context they typically get a lot of problems, a lot of pushback, a lot of things broke. I can remember probably about 10 years ago when I was going around the security [inaudible 00:08:43] doing presentations and saying, hey you shouldn't be logged in as local admin all the time, well I realized for a couple years that I was saying that while I was logged in as local admin. So I decided to put my money where my mouth is and for a couple years I decided not to be logged in as local admin all the time. 
And what can I tell you is that it really was horrible, it was really difficult to almost do anything. You couldn't even change your IP address, you couldn't change between wired and wired, you couldn't do simple changes to your system, software broke, things crashed. I was always amazed even Microsoft's software would break but there are a lot of things games broke, programs broke, websites broke, this is amazing thing, very difficult. It's a lot easier today to run as a non-local admin but you still have a lot of that legacy software around. And certainly you have lots of organizational culture where people are just allowed to install and do everything.
So a big thing to remember again, is that local admins can absolutely do anything on their system and from a security perspective that of course, is the worst thing. That end users can do anything on their systems. Users can install unwanted or unauthorized software which many times happens to be malware. I think I was reading a survey by Microsoft and Internet Explorer 9 the other day that said somewhere between 9% to 40% of all software downloaded by end users that they're prompted to install, is malicious. That's pretty significant, that's a large portion of the software that people are installing that have worms, or Trojans, or something in them. And here's an amazing thing I like to tell people is that when an end user is local admin and they can install and do anything, well the malware developers, just like regular software developers, kind of assume that's what they have. That they have local admin many times it's starting to change a little bit but certainly in the past that was always the case. But somewhere around 90% of all of today's malicious exploitations are caused by an end user installing something that they shouldn't. It's the fake anti-virus, it's the fake disc scanner, it's the fake update, it's whatever.
I like to put it to people this way, suppose every software developer in the world made zero defect codes, suppose there were no zero days that Microsoft, and Apple, and Google, and Macromedia Flash, and all those things, imagine if all of them which literally together have hundreds of vulnerabilities, imagine if they all of a sudden went to zero. There was nothing, they made perfect code in a perfect world. That would almost not stop malicious exploitation at all. That's a big thing to let sink in that most maliciousness on a computer happens because the end user is socially engineered into running something they shouldn't and they end up installing malware. They sometimes even though they have the ability to install patches sometimes they even remove patches. I've had many people that turn off on their computer systems while the patches have caused problems. So they turn off Windows Update or Microsoft Update, or they remove patches because they read on some website somewhere they weren't supposed to have this patch or it caused this problem.
And yes certainly that patch got fixed and updated in a couple of days but that end user never installs that patch again. So you can even have a company that has very aggressive patching where all your high criticality stuff is patched within a couple of days or a week or something like that. If the end user is an admin they can remove the patch, they can turn off all the services, they can turn off firewalls, they can turn off... If the local user is a local admin they can disable any security functionality you put in there. You can even have very good software that does something like network access control, this is where you have to have this, and you have to have this, you have to have a firewall on, you have to have an up to date anti-virus, you have to have this. But if there are local admins they can turn all of that stuff off. They can turn off their requirements, they can lie to the management machine that's doing all the checking. 
And that's where it gets kind of defeating is that you're trying to manage a large organization and we all know how to kind of protect our personal PC. We now run anti viruses up-to-date, don't click on stuff that you shouldn't. We're all very savvy about that but when you try to do it across 200 or 1,000 machines and you're trying to put out these security measures that you know that will make people safe like not allowing on untrusted ActiveX Controls to run or something like that even if you enable that end-users just can very easily disable it or even social engineering.
Inside of the email I saw one the other day it was a malicious Microsoft Excel file that had an older zero day Adobe Flash exploit, but the email said, hey you if get a warning that this thing could run malicious code, download run malicious code ignore it and just say tell it to allow it. And I was amazed of how many people in that particular zero day had run it. They actually do my testing had somewhere around three different warnings that said, hey be careful this could be malicious and they still ignored the security warning. They still turned the thing off, they turned off their firewall, they turned off the Microsoft Office macro warning that sort of stuff. And not only that but they can change their configurations so that it maybe it's not even security related at all it's just they change stuff, they install stuff when end users are local admins they end up... If you run a program like AutoRuns or Silent Runners or something you can end up easily see hundreds of auto starting programs on a person system. 
So for all these reasons because local admins can do anything on their system and there are often times hurting themselves, those are the reasons we want to remove local admin access. Ultimately you're trying to lower the total cost of ownership, the idea is that if I as an IT manager, if I put out an image that has everything that they need to do their job and no more and no less, but if I stop them from installing malware, if I stop them from doing stuff they shouldn't do, if I stop them from installing 40 different little even legitimate programs that could slow them down, its total cost of ownership lowering for themselves, for the IT Department and for myself. Ultimately if you can control that system so that the end users can't hurt themselves maybe you're only [inaudible 00:15:27] that machine once a year versus every quarter, four times a year or whatever.
But many times when you hear the term total cost of ownership it doesn't really happen in fruition. So you say well I'm going to take this control away to lower costs you make all these good arguments, but then you have users and senior executives result in revolt. You take away their local admin rights, all of a sudden they can't install... Like I've seen it where senior manager said, "Yes we want to lower total cost of ownership, we want to make a list of all the programs that are approved to run." And then the first time the senior executive is trying to put on his golf handicapping program or his favorite stock program boom you're yelled at. Or the first time the favorite senior executive goes in the CEO and says, "Hey, I can't run this program," the next thing you know you're in trouble. You go from hero to zero kind of quick. On top of that you have all these programs that literally will not work without admin rights even if they legitimately don't need admin rights like the QuickBooks example. There's no reason why QuickBooks would ever need anything than maybe local admin but literally requires and does a check for domain admins, and it will not work without that, just crazy. I used to put it on a website called the Wall of Shame for many, many, many, many years and QuickBooks people just didn't care, it just is what it was.
Plus probably one of the worst things is when you take away local admin although you're protecting the end user you're taking away a whole lot of legitimate uses that the end user needs to do. They do need many times to modify their system or change their... I don't know change their screen saver or, map to drive somewhere, add a device driver. It can be very frustrating if you're an end user and you're trying to install a USB key, or a camera, or some new software that you've been told that you have to have and it just won't install. That can certainly be very, very frustrating.
Another reason why taking away local admin doesn't work is that now since Windows Vista, and Server 2008, and Windows 7 those things have a User Account Control Program that kind of bothers the end user if they need to do so something that's local admin. It will put up that little box or blacken the screen and say are you sure you want to do it. With that nuisance of User Account Control has made more and more developers make their software so it can be installed without having to be elevated, without having to be a local administrator. One of my best examples of that is Google Chrome. You can install the whole Google Chrome browser and it'll never prompt you for being in local admin. It will be installed completely in the HKEY_CURRENT_USER in your local user profile.
So think that if... And the big thing is that ultimately, taking away local admin, today it does not stop all malware, in the future it's going to stop even less. Because a lot of people...because of UAC, and Windows 7, and Server 2008 are moving away from local admin, well the bad guys are responding to that and they're making it so it's just not as helpful anymore. The bad guy can do almost everything that they want to do and as a regular end user that they wanted to do before with maybe two exceptions. And the big ones there are they can't install themselves kind of in a root kit and hide easily and they can't modify the operating system as easily. But can they steal your password? Yes. Can they steal your login credentials? Yes. Can they socially engineer you and take everything they need to take? Yes. Can they steal your money? Yes. Can they steal your identity? Yes.
So that's one of those big scary points that a lot of people don't wanna talk about is that even if we take away local admin, but you allow the malware to still run it's not gonna stop the crime, it's not going to lower total cost of ownership. Getting all your end users and getting away from local admin if you can even do that in the end...and I guarantee you this I will put my 20 year reputation on the line is that even taken away local admin all the way it really won't stop the bad guys. It'll be a momentary blip on the history of computer crime.
So that's the kind of example of this slide here is that many programs including thousands of malware programs… I saw some statistic yesterday it was so unbelievable, I almost couldn't believe it but it was something like 16 or 60 million different malware programs are built every year or maybe it was every month. Really realistically once you get to like 10 million a year [inaudible 00:20:09] 10 million new programs a year and 60 million a month, whatever the number was it was incredibly huge. But way back I've been tracking malware program since like 1987 but ever since 1989 I've seen a couple of programs that could infect without you being local admin. If you wanna think about some easy common ones all the macro viruses that came out, the VB scripting viruses and all that sort of stuff, a lot of things like that just didn't need admin. As a matter of fact there's probably in a typical Windows system, probably has about 120 places where you can put auto launching, auto executing code and maybe only 60%-70% of those locations need to have local admin for the bad guy to modify that location.
Anything under HKEY_CURRENT_USER you can modify, anything your local user profile you can modify, I can put my bad program in the Windows temp directory, I can put many, many... I can put my bad program just about anywhere. The malware program does not need to be under Windows or system 32 to do its bad work. And some people asked well why is that so much malware is under Windows system 32, or HKEY_LOCAL_MACHINE\Software, or Microsoft\Windows\CurrentVersion\Run, why is it there? Well, for the same reason many of the end users are. It's just the way that it worked for 20 years and it worked so people started taking away admin. But since for the last 20 years there has been dozens and dozens of programs that just worked fine without being in local admin, and they will continue. They will always be programs like that and because a lot of people are going away from local admin the malware guys are just shifting faster to be able to make sure that they don't have to be local admin. And I tell people this all the time, if the Google Chrome browser can install without admin, what can a malware program not do that the entire browser program can't do?
You certainly have a lot of browser add-ons that don't require local admin, you have many ActiveX controls that don't require admin. And those are just getting more, and more, and more, those aren't going away there's just more of those coming every day. And of course, once an approved program is exploited, let's say you have a flash buffer overflow or something like that, or a Java, these days the two most popular attacks besides socially engineer Trojans are Adobe Flash problems and Sun Java applet programs. But once those programs are exploited the bad guy can and then do almost anything. I've been a [inaudible 00:22:43] tester going on 10 years and the soon as you get that first insight hook then the sky's the limit.
And again lastly as I covered before is that this is something important to remember and this is not...I've written about it in some of my column over the last couple years, but it's almost like this hidden dirty little secret is that malware can do almost everything. I don't wanna say everything but almost everything that it needs to do without having to be local admin. They can still install malicious programs, infect files, they can live through reboots, no problem, they can record your keystrokes, they can record your password, they can steal your identity, they can log on to your bank and steal all your money, they can attack other machines. It's only been because the malware expected everybody to be local admin, that most malware programs expected everyone to be local admins. But did it ever need it, did it ever need truly to have access to the system 32? No, it didn't and that's the dirty little secret that is starting to become uncovered. And with that I'll throw it back to Sam.
Sam: Thanks Roger, before we move on to the next section I'd like to share the result of our first poll. The question was what local admin privileges do your users have? Thirty-six percent said limited rights, 32% said fully restricted, and 26% said no restrictions. Roger, I guess I'll just pose this to you. Any surprises or thoughts regarding this data?
Roger: No, certainly we've seen a move away from local admin, I think if you'd asked the same question probably five years ago it would have been almost no one was not in as local admin. So it's changing and sadly enough just as a kind of covered [inaudible 00:24:48] is that even as people move the local admin the ultimate long term success of defeating malware and computer criminals it just isn't gonna have that big of an impact, they've already passed that. 
Sam: True. Thank you, I have one more polling question before we get to Chris's part of the discussion that I'd like to ask the audience. How many incidents have you had in the last year to local admin abuse? And that includes negligent users and malware one, two to three, four to five, more than five incidents, or none. Please make your selection then we'll get to those results after Chris's part of the discussion. And with that Chris I'd like to turn it over to you.
Chris: Great thanks, Sam and thanks for the great discussion there Roger. I like to start off by talking a little bit about what Roger was talking about the all or nothing approach to controlling local admin really doesn't work as Roger's amply pointed out. So yeah, new approaches are needed. Microsoft is doing a lot to try to mitigate the risk as Roger pointed out with UAC on the latest versions. But they can't necessarily do it all. They have legacy software to support their own apps and other apps, and they've got a huge user community as polar opposite needs. So it's very difficult for Microsoft to meet everyone's specific need to the level they might wish. So yeah how do you approach this problem? You need to provide some visibility and some control over what's going on within your environment, but you don't want to impact productivity or as Roger pointed out impact somebody's golfing app, something I don't know much about.
But we can look at other tools that have come along in order to try to gain control over local admin. I think the results of that first poll reflects some of that there are some good tools out there that help with this issue. But again it doesn't address some of the areas that Roger was pointing out. So basically what about that 90% of the malware that get installed even if the code were perfect. How do you deal with that? And even beyond that how do you deal with things that are within your system that users have installed that your organization might just not wanna have there. The example I always use is P2P program. P2P is perfectly legit in a lot of cases. If you work at an advertising agency and you develop very large files, graphics and so on so forth, that you have to share with vendors, or your partners, or your customers P2P is incredibly useful. On the other hand if you work at the Pentagon or a defense company something like that P2P might be considered a bad thing, a way for things to leak out. 
One of the most famous cases recently is the presidential helicopter plans that got leaked out what three years, two years ago certainly not what they had intended. So we have not only the issue of malware but we have the issue of unwanted or unauthorized software that execute on your endpoints that you need to gain control over. And simply turning on and off local admin won't necessarily deal with those issues. So we've looked at this problem and have taken a slightly different approach to provide a visibility for the business and IT to see what's going on within their network. After all you can't really manage what you don't know about, and to reassert control to the extent desired. And we'll look into that a little bit more in-depth here in a second. We wanna extend beyond just local admin control to look at these unauthorized or unwanted apps. And we want to do that within the existing ecosystem and cultural norms to start to nudge those into the direction that's appropriate for the organization.
So some of the things that one might worry about that local admins can do, are things like installing applications. So very easy right there as a local admin I can install any application and indeed in most cases that's good but what if the end user is installing stuff we don't want? What if he is doing, as Roger pointed out, installing that 90% of malware that gets installed. So how do you deal with that? So Lumension has developed application control product, it's been in the marketplace for I'm going to say over eight years now. A new version of that has just come out that gives the organization much better granularity or granular control over what sorts of things get installed. One way we do this is something called easy lockdown. Now easy lockdown is basically a one button push to examine what is running on any given end point and then to allow the organization to determine which of those you're going to allow to continue to run and which of those you're going to block.
It's done on per end point or individual endpoint basis, so you don't have to do that massive set up where you're trying to get a gold image, and keep everybody to that gold image, and try to make that one gold image work for everyone in the organization. And after all the folks in engineering generally need very different set of tools than the folks in finance or the folks in marketing. And what may be legit in finance if it were in the hands of say an engineer you might not want that. So by providing granular control over what sorts of applications individuals are allowed to run we reassert that control that IT business sends on what folks are doing. In addition with the latest version of application control we've introduced something called the trust engine.
Trust engine is a very unique capability that allows you to determine ahead of time what sorts of changes you're going to allow on your endpoint. There's a lot of changes being made to software, perfectly legitimate, we just got through with Patch Tuesday. And we all have some version of WebEx or GoToMeeting on our boxes that self-update these sorts of things. And if you require the IT organization to vet each one of those, it can be painful especially if it comes from a known vendor or it's a trusted program. And so the trust engine has been designed to allow IT to automate the update of the whitelist and the programs that are allowed to run on the endpoint. And this means that IT can now step away from the day to day maintenance routine and to focus instead on a more strategic issues. What are the software needs of the organization, what tools are legitimate, what's not legitimate. And they start to re-use their IT bandwidth on more strategic initiatives that support the business goals. Business goals are rarely security centric, they're generally revenue centric, and by taking your bandwidth and reorganizing it toward supporting these strategic initiatives you become much more in tuned with what the business is trying to do.
Other things that local admins can do include changing configurations as Roger pointed out. Configuration management is a very important part of maintaining a clean and well operating system. They can install and remove, or uninstall software and remove patches. Again, as Roger pointed out some folks go through and they read some alarmist thing on some website and they go and remove a patch and they never go and reinstall it. And so the organization may think that a platform is patched but it turns out it's not and they don't know about it. And local admins can defeat security tools, kill processes, and so on and so forth. 
So as part of the application control that Lumension has done is created a blacklist where you can go through and target individual executables to be included on these denied applications tool and it gives you that ability to target specific things to remove from the end user that prevents them from wreaking havoc on the end point. So all of these tools put together allow the IT to reassert control over what's going on to the end point without having to take away the local admin and labor under the notion that they've now done everything they need to do.
Because in the end what we're looking for as a said earlier is to really promote the business goals. We're trying to provide the control necessary to meet whatever internal policies we have and external regulations which there are more and more these days, but we need to maintain the productivity. So the key point is to provide the knobs and the buttons which allow IT to reach the appropriate balance between productivity and the control. This allows the organization to make security a business decision as opposed to being limited by the technology. And reduces the total cost of ownership of trying to maintain their end points.
How does it do this? Well, one of the ways is to eliminate software configuration conflicts. So think about all the help desk calls that are made because I just installed such and so and now my box doesn't boot up. And your tier one and tier two support folks get involved, they have to remediate the problem end users down. So there's a lot of these sorts of costs associated with not only malware but also with unwanted and unauthorized applications getting installed and run on end points. When it gets really bad then you end up having to reimage the box, not only do you lose of the time it takes to reimage the box and the bandwidth of the end user and the tier three support folks, but you also lose a lot of data that way and productivity in that way. So there's a lot of cost associated with not only malware but the unwanted software that by reasserting control the organization will reap a lot of benefits.
So whitelisting helps in a lot of different ways. You stop playing whack-a-mole, it's one of my favorite games, by providing the visibility into what's going on within the organization as a whole, and get to see what applications are running on individual boxes, and what's going on in the aggregate. And then start asserting control as necessary across the organization, and again, at the end points as appropriate. And it's not binary, as Roger pointed out, removing local admin access is a binary control, it's on it's off, it allows you to do this, it doesn't allow you to do that. By using application control you end up providing a granular level of control that pinpoints what it is you're trying to achieve for different users at different times. And this is very important in maintaining the productivity of the organization and thus lead to the better control.
It prevents from malicious executables, malware, from executing on the box which is really in the end the key point. All of the exploits that are targeted by the bad guys, as Roger pointed out, all have an end goal, as he point out, getting a hook into the box, because once they get the hook into the box and the sky's the limit, as he said. So by using application control and not allowing unknown unauthorized programs from running or executing on that box you're forting their goal. They may be able to exploit a hole but they won't be able to do anything with it. So this becomes a very important point in your continued fight against malware.
It also provides you the breathing room as you're going through Patch Tuesday what was it, 66 patches this past Tuesday. You have to test them, vet them, make sure it's not going to break anything. If you're worried about those holes being exploited you have to do that in a hurry. By having an application whitelisting system on your endpoints you provide yourself a little bit of breathing room. You can do a more considered approach on them and go through a more thorough process.
So in the end you provide better visibility into what's going on, you provide the granular control necessary to allow your organization to be productive without giving up your boxes to malware or other unwanted or unauthorized applications. Prevents those malware attacks and lowers your total cost of ownership. And as I said earlier that all then means that your IT bandwidth can be re-appropriated to more strategic initiatives that will support the revenue generating end of the business which will integrate IT with the overall goals of the organization. And with that, Sam I'm gonna hand it back to you.
Sam: Okay, great thank you Chris. At this point I'll share out the results of our second poll. Again, that question was how many incidents have you had in the last year due to local admin abuse. Very interesting answers, 40% said none, 35% said more than 5, 12% said 4 to 5 and then 7% for 1 or 2 to 3. Chris, if I'm looking at that sort of looks like almost an all or nothing.
Roger: That's what I start to call a non-normal distribution or [inaudible 00:42:22]. 
Chris: Yeah, very interesting and yeah, who knows what exactly that means but you never know how much of these malware attacks and such can be directly attributed to local admin. I think one of the points that Roger made about 90% of malware gets installed by the end user kind of on purpose or unknowingly it kind of will address some of this, very interesting.
Roger: I wonder how certainly gotta have, I would think almost every organization got to have a lot of productivity issues by stuff being installed that you didn't mean to be installed. Let's think about.... Even if all I'm doing is updating some Sun Java, Adobe Flash they sneak those other programs on there all of a sudden it's the Google toolbar, MSN toolbar and they're all of a sudden indexing your machine. Those are issues that even approved programs with the secondary process that kind of get snack on there, that's got to hit everybody. 
Chris: Absolutely.
Roger: [inaudible 00:43:36].
Sam: Roger, have you seen in your experience any anecdotes related to some of these numbers we're seeing here in this poll?
Roger: To be honest with you I'm surprised it's just not higher but of course, maybe not everybody always expect to be 80%, 90% more than 5 type thing because people are just being hit so many places. It's funny not only is it corporate... And I deal lot 41,000 midsize businesses and a couple of small businesses but it's been a tough year. It's actually less attacks but more successful and more damaging, it isn't... I almost want to whine for the days of the macro virus sending around 20,000 emails in one minute because that was a pain in the butt, but they weren't selling my company's data. Now it's these very focused spear phishing attacks, installing stuff and getting out with real valuable data. There's a couple of companies that have suffered probably… I think for the first time in history of computing we're gonna have a couple of companies this year that are going to suffer what's called... I'm a CPA as well as being a computer geek. But they're gonna suffer what's called a material effect that will have to be reported to financial statements. Because they're losing tens to hundreds of millions of dollars due to a single hacking attack and that's pretty... It's history, it's historic.
Chris: One of our listeners pointed out that the visibility issue is paramount in answering a question like this, and if you don't have the visibility you don't know about what attacks are directly associated with a local admin etc. That might explain some of these results but the material attack that's a good point.
Roger: And of course somebody pointed out, one of the viewers pointed out they may not know you're known unknown and [inaudible 00:45:32] whatever, but yes certainly there's a lot going on. I go to a lot of companies, part of half the companies I go to say how come we're not exploited in every case except for one over the last five years they've been exploited. When we start looking around and doing the forensics work I mean so it's a very, very common for me to hear people say well I'm surprised we haven't been attacked. And lo and behold they've been easily many times exploited for years, or another stat I read I think was in the Verizon data breach report that said, in something it was over half, but over half that reported exploitation were reported by somebody else other than the company that's being exploited. So that's certainly there's a lot of that going on.
Sam: Great, thank you both that actually lead into a quick good commercial for discovering what's in your environment. Lumension... before we get into the Q&A a couple just resources I'd like to make our audience aware of that Lumension is made available. Information on Lumension intelligent whitelisting which is what Chris was discussing as part of his presentation. We also have a demonstration of the solution and also an application scanner that enables you to discover every application and executable on your network. So a key tool to get some of that visibility that we're talking about. And also some whitepaper... I'm sorry.
Chris: That's a great tool. I think a lot of people could use it for a million other things, it's a great tool to have.
Sam: Excellent, and we also have some whitepapers and videos available around local admin, and one on why your antivirus solution may not be working for you. Sort of a look at the approach of whitelisting and its role in the security defense. So with that we do have some questions that have come in. Chris, I'll point the first one to you. This is regarding sort of usability and security of productivity and security, and sort of, if a company have to err on one side when it comes from local admin rights should they err on the side of usability or security or how do they get that balance?
Chris: Well, that's a good question and that's not one that I can answer as a blanket statement and it really depends on the organization. And I kind of fall back to the story about P2P perfectly legitimate application in many instances. I've used it myself when working with large files over a long distances especially over in the old days, good old modems. But in other instances say you work at the White House, say you work at the Defense Department, in instances like that P2P might not be the application that you wanna find on your end points. So that balance between productivity and control or security is really very dependent on the organization and what their needs are and what their environment is like, if you are in an environment where you've got valuable data then you might err on the side of security. Especially in say that again the defense arena. But I think the other thing is that people really need to take a realistic look at what their threaten environment and what their security needs are. We tend to hear a lot of stories like the recent Sony hack. Where what was it? Twenty-five million credit card numbers and so on and so forth were stolen. And those sorts of consumer data are the subject of a lot of laws both in the US and in the EU and elsewhere, and the subject of a lot of news stories.
The stories that we don't read so much, we don't hear about so much are the ones where organization are concerned about their revenue generating IP. I had an interesting discussion with the CISO at Disney and the extent to which they went to protect the final episode of "Lost" television show the subject of a lot of blogs and a lot of people really interested in understanding what's going on and that sort of thing. If the conclusion of that series had leaked out ahead of the episode then it would have cost them real money both in terms of the show, the revenue from adverts that day and in syndication, and DVD, and so on so forth. So they went to a great extent to protect that IP. And so a company like Disney which doesn't have what we would typically consider a critical IP but it is the life blood of the organization, that's how they make their money. And that's something that you really need to think about when you're making that risk assessment and how do I achieve that balance and what is appropriate. I mean we all...
Roger: I'm sorry, I'm gonna cut in. You just said perfect I think going back to the smart grid question you got the... The question says I've got a smart grid lots of endpoints thinking about meters, that's the question. And you said about balance and risk balances that there's not a whole lot of risk on your meters yet. Meters are of course hooked over the Internet and the VPNs and that sort of stuff and if they get more risk I think you get more controls around them. But you really in the organization have to decide where is the risk, how much of value, how much risk is in the company on the meters or on the endpoint versus the crown jewels. 
So I'd like what you said which was balance because we don't need the same protection everywhere and sometimes that binary decision of local admin versus not local admin it's hard to make the shades of gray that you need to protect something that doesn't need as much protection as it might be with the crown jewels. And that's not to say that a smart grid meter doesn't need to be protected so it doesn't get exploited because the bad guys can exploit that meter and get to the crown jewels, but you have to make that risk balanced decision. And you for sure don't want the same level of protection on every device and depending on what they can access you wanna put more and more protection around it, but I loved what you just said there which is the right risk balance, that was great.
Sam: Thanks gents. Chris, a question just came in, I'm sure Roger will have some thoughts too, but I think this is a good one for you. If most attacks come through common software such as Flash or Java and those apps are whitelisted because a lot of websites and other apps don't work properly without them how does whitelisting help them in that situation?
Chris: Yeah, that's a very good question and Roger pointed out that that's becoming a more and more common attack vector. To answer that properly I think we have to understand what it is the attackers are really trying to do. They're looking for holes, vulnerabilities within your organization in any form that they can find them. Zero day exploits that are known to them. Vulnerabilities and configuration set up and these sorts of things and then they create a code or use code to exploit that to gain a foothold on whatever device it is that they managed to exploit. So that's the hook that Roger was talking about. So once they've got their hooks into, now what they're doing is okay, now I get to do what it is I'm really trying to do, which is going to be do install some piece of code that allows them to gain control over that asset, and then to use that asset to find the crown jewels as Roger says and to exfiltrate that data, so that they can use that for money.
And we have to remember that for the most part these days the days of script kiddies who come in to take over something just because they can and post it on their website, those days are gone. Today we're facing very sophisticated financially motivated cyber criminals and some nation states are pseudo nation players, national players that are looking for national secrets, and other things, economic exploits that they can make. And in cases like that they're always interested in taking data out. And to do that you have to install some malware on the box that allows you to do that, it's some sort of code that lets you exfiltrate the data. Using whitelisting where you aren't trying to block all the known bad things because there's... In a world, what did you say 60,000 malware produced per month Roger...
Roger: Millions.
Chris: In a world where... yeah millions I think you said.
Roger: That I think was [inaudible 00:55:21] stat I saw the other day.
Chris: In a world where that many new things being produced basically every second it's almost impossible to stay on top of it. However, we know that on an average box you've got 26,000 legitimate executables running. If I know what those legitimate 26,000 things are, I can control that, I can visualize that, I can control those. And anything else that shows up I can say well that's not on my list, I'm not gonna let it run. If I'm not gonna allow the code that the malware writers put on to my box to run to exfiltrate the data I've forted there end purpose. So that's how whitelisting works in a world where Java and other exploits can exist.
Roger: Couldn't have said it better, you stop and break in and then whitelisting is one of the few things that can stop what happens after that. [inaudible 00:56:22].
Sam: Great thought, thank you both. We have time for one more quick question before we have to wrap up and Roger I'll put this to you. What would you recommend in terms of organizations where users bring in personal devices, so not something that's quote unquote been sanctioned by the organization? How to handle those?
Roger: Yeah, how do you manage or how do you whitelist something that hasn't been managed. You kind of have to create... that's more kind of a long network access control where you say you can't connect to the network unless we can verify that you have something. So it would be through some type of a whitelisting client or something like that, where you'd say if you don't have this particular agent or manager then we won't let you on. I mean that's tough, people got a ton of stuff.
Sam: Great, well thank you, with that we are running short on time. So any questions that we were not able to get to we'll follow up via email with you directly. We will also make available...we'll also send emails to all the attendees with the recording of this webcast as well as the slides that Roger and Chris have done such a great job of presenting. So you'll get those from us within the next couple of days. And the webcast will also be available on For more information on Lumension's solutions you can contact us by going to, visit our blog You can call us at 1 888-725-7828, or you can email us at [email protected]
Thank you everyone for participating in today's event. Thank you Roger and Chris for this great discussion. And we will see you next time on the next Lumension webcast. Now I conclude our webcast.
Chris: Thanks Roger.