Security Adviser | Roger A. Grimes » TAG: Risk Management

April 04, 2008 | Comments: (0)

It's the applications, stupid

TAGS: Risk Management

It's always written that the first Presidential candidate Clinton posted, "It's the economy, stupid!" as a banner marquee in his campaign office during his premiere run. This saying supposedly helped focus the staff, resulting in a surprise win for the Democrats.

Well, if you're reading computer security headlines these days, we should all have "It's the client applications, stupid!" in our war rooms. Nothing I'm saying in this blog post is news. I just want to reiterate it so that everyone is on the same page.

Most of today's popular operating systems are becoming fairly hardened at the OS and OSI layers 1 to 3. Remote attacks, where the end-user is not involved at all, are becoming almost a rarity. They are not gone completely, but they are becoming far less prevalent than attacks involving their end-user and installed client applications.

This was reinforced at the CanSecWest conference, which had a hacking contest pitting fully patched versions of Windows versus Mac OS X and Ubuntu Linux. The first day's competition offered a $20,000 prize for remote exploit hacking. No one claimed the prize, and that's a good thing. There may be remote exploits that would work -- there's bound to be in the larger world of crimeware -- but most contestants waited until day two, when hacking on the box was allowed. Day two required that the hacking be conducted using only default installed software. The Mac was felled in two minutes using a Safari exploit by professional white hat hacker Charlie Miller to gain a $10,000 prize. I've interviewed Charlie Miller before, and his knowledge of Mac hacking is solid.

The other two computers didn't fall that day.

Day three, with a $5,000 prize, allowed "common" applications to be installed and hacked locally. On day two, several unsuccessful hackers said aloud that they couldn't wait until day three and for Flash to be installed. Sure enough, the Windows Vista machine was felled by a vulnerability in the Flash software. Apparently the default defenses of Vista's SP1 kept the hackers at bay for several hours, but they were eventually able to circumvent the protections using another third-party application installed on day three, Sun Java.

To be honest, the hacking contest results alone don't really mean much. There's nothing to say that Vista or Ubuntu couldn't have been hacked just as fast on day two (other than they weren't). Charlie Miller obviously had the Safari zero-day in his back pocket and pulled it out to win some money. The winner of day three said the Flash vulnerability could have been equally successful on either of the other two platforms.

So Windows, Mac, and Linux zealots don't really have any more ammunition to attack each other after the contest than they had before. And the positive note was that none of the computers were felled by remote exploits, which, when they exist, can be devastating. That's good for everyone, no matter which platform you are partial to. And the contest did reinforce the idea that client-side applications are the biggest threat. If it isn't something purely browser related, it's a media player, content reviewer, productivity application, or browser plug-in. Most, but not all, require the end-user to click on a link, download content, or execute a file.

If your applications are unpatched, it is much more likely that simply visiting a Web site can silently infect your computer. And remember, visiting only well-known, legitimate Web sites is no longer a defense.

The bad guys (and girls) are using mostly legitimate, well-known Web sites to spread their malware. If you can think of the Web site's name that you visit frequently -- and I mean any Web site -- there is a high likelihood that it was, at least once, infected by malware that spread to visiting users. Even anti-malware vendor Web sites are falling like hot potatoes. Many of the Web sites unknowingly carried malicious advertisements in their banner ads. Others are hacked using Web site vulnerabilities, PHP issues, SQL injection, and so on.

The defenses are to make sure your systems are fully patched, both OS and applications, and to educate your end-users about client-side vulnerabilities:

1. Client-side vulnerabilities are one of the biggest threats they face
2. They can no longer automatically trusted legitimate, well-known Web sites
3. Pictures, video, and active content (such as Flash) can be used to take over their PCs
4. Do not install unapproved client applications

Day after day, I read about how some large store, bank, or government site was taken over by a client-side-initiated attack. Many system administrators are struggling with improving their security. Let this column be your banner.

Posted by Roger Grimes on April 4, 2008 03:00 AM

March 07, 2008 | Comments: (0)

Re-thinking the security of virtual machines

TAGS: Risk Management

Recently, I've heard many security officers talking about using virtual machines as a way to increase security. If your developers need local administrator rights and privileges and they can't have them on their normal PCs, just give them a VM. If an end-user needs to circumvent a few enterprise policy settings but can't get the management approval, give them an unmanaged VM. If people need to browse untrusted Web sites, give them a VM they can easily reset. At least, these are the reasons I'm hearing why security-lessened VMs were created.

And here's what I want to communicate: If you allow the VM to be connected to your network and/or domain (specifically, if the VM has network capabilities), the VM probably increases your security risk -- it doesn't lessen it. Get it straight in your head and undo the bad conventional wisdom. Unless the VM is network-disconnected, you need to treat the VM machine just like you do a physical, real machine; or accept the increase in security risk.

By their very nature, virtual machines mimic nearly all the qualities of a working production OS. Every security threat -- and potentially more -- that you have with a real machine, you have with a virtual machine. The transient nature of virtual machines leads people to be more lax about their security.

First, virtual machines are less likely to be patched. How can the VM get patched, when it is constantly stopped, started, and reset? It can be done, but it takes more consistent effort. "Why patch it at all if I can just reset when it gets infected?", some users are surely thinking.

Second, users, and especially IT support people, tend to use weaker passwords in VMs than they use on real machines. Many of the VMs I come across have a password of password (or Password2 if complex passwords are required). Many VMs have blank admin passwords (which can actually be secure against unauthorized remote logons). But by far, the biggest problem I've seen is the reuse of passwords between the VM system and the user's production system.

Because the VM system is more likely to be weaker security-wise, reusing passwords is just asking for trouble. It's probably not as bad as reusing business passwords at home but not much. Think about it. If the VM has been intentionally set up to be more open and less secure, it needs stronger password policies, not weaker.

Third, virtual machines are more likely than traditional workstations to contain rogue software that the end-user doesn't want management to know about. I've found many VMs running password cracking and sniffing tools. The user places them in VMs that they have shutdown most of the time so that the typical nightly network scanning tools can't find their stray software and alert security folks.

Fourth, another big reason people have VMs is to visit untrusted Web sites, which they can quickly reset if they suspect malware has infected their session. The user's more risky behavior means they are more likely to come in contact with malware. Add to that the fact that the VM is less likely to be patched, and you have a malware writer's silent installation dream.

How many users will even recognize that their session was infected and reset the VM? If end-users were so good at recognizing when they got infected we wouldn't even need the VM in the first place.

How much more likely is it that VM users will not reset their VM sessions over longer and longer periods of time? And even if the user resets their VM image daily, malware can do all the damage it needs to do during the user's current session. Today's network bots are intentionally designed for short useful lives. They don't need 8 hours to search your network for available open shares, to steal passwords, or to send out millions of spam messages.

Finally, a VM can be weaker than a real PC because of the break-out-of-VM-to-the-underlying-host issues. There have been dozens of theoretical attacks, and a few real exploits, against VMs that allow attackers hitting the VM to access the underlying host machine. So, in this respect, VMs can actually be less secure than a real computer.

To clarify, if a VM is connected to your network and domain, and its security is lessened as compared to your normal production computers, it will increase the risk of malicious attack. For me, when someone suggests using a VM as the solution to some security problem, I think of the VM just like I would a real, physical PC. The same security risks are still relevant.

If the VM can be isolated from the network or doesn't have a network connection at all, then there are potential security benefits. There are also virtual environments that are specifically built to prevent malware infection, but I've yet to find the VM environment that worked perfectly to prevent malicious modification. There are ways to give certain groups of users more open environments, but I don't find that VMs are the answer most of the time.

Posted by Roger Grimes on March 7, 2008 03:00 AM

November 30, 2007 | Comments: (0)

Go RBAC now

TAGS: Risk Management

Implement role-based access control for stronger security in your environment

Good computer security is driven by role-based, least-privilege access control. Each user should be given only the access that is necessary to perform their job -- no, make that the specific task they are performing at a specific point in time.

Unfortunately, even though RBAC (role-based access control) was formally introduced in 1992, it is still in its infancy on most platforms. There are many role-based management tools that work in Windows, Linux, and other OSes, but the most popular products work with only a few large products (that is, SAP, PeopleSoft, and so on) or just haven't been widely adopted. For example, Microsoft has formally supported the RBAC model since it released Authorization Manager and a role-based API in Windows Server 2003. But it is rare that I run into a system admin or developer who has heard of it, much less worked with it. If you haven't heard of Authorization Manager, go to any Windows 2003 or later Windows server and type Azman.msc in the Run command line. There's lots of information on it if you do an Internet search.

Linux has long had RBAC capabilities. Nearly any decent Linux distro will allow you to add an RBAC security module. Many versions, such as SELinux (Security Enhanced Linux), come with RBAC by default. If you don't have SELinux, there's still a good chance your Linux supports RBAC already. Just look for the MAC module and read the man pages. There are also many developing RBAC initiatives, such as the OASIS XML-based RBAC effort for Web-based content (PDF).

Reasons for RBAC
Why investigate RBAC solutions? They're a good way to implement stronger security in your environment, and often it is required. Many industry-wide regulations, such as the Payment Card Industry Data Security Standard (PCI DSS), require role-based security (PDF). If you're required to support PCI DSS in your environment, review section 7. Hospital and health-care-related entities are already aware that Health Insurance Portability and Accountability Act of 1996 (HIPAA) mandates use RBAC to protect patient information.

The vision of RBAC security is this: No one knows better what security permissions or rights should be needed by a particular end-user when performing a particular task than the developer of the application. Unfortunately, this particular assumption is largely untrue. In general, most developers don't have a clue about the security needed to run their application. They just know the application runs perfectly fine when given Administrator or root privileges. This attitude is changing, with Windows Vista's User Account Control (UAC), Linux's sudo, and better development tools that allow needed security to be measured and defined.

Let's assume that application developers do know exactly what permissions are needed for each task in their application -- and this is indeed true of any application developed with RBAC in mind. The developers create application-specific groups that mimic the various roles that an end-user would perform in their application.

For example, in a payroll application, you might have the payroll data entry clerk, the accounting and general ledger associate, the check publisher, and the payroll manager. The application developer defines the various roles and ties each role to various tasks needed to perform the role (called transaction authorization in RBAC terminology).

When the application is installed, the application manager assigns the various users or groups to their needed roles (called role authorization). Then the end-user can perform only the tasks assigned to their role (rule assignment).

A great benefit of role-based security is dynamic access control. When the end-user is not performing a particular task, they don't have any access permissions to the underlying resources. For example, when a payroll data entry clerk is logged into a RBAC application performing their normal duties, they have read and write access to the appropriate fields of the payroll database. When they come out of that particular task -- say, to a main menu -- their access to the database is removed altogether.

This is a great improvement over other access control implementations. Consider how access control works on most systems today. The payroll clerk is probably given read and write permissions to the entire database file in perpetuity until their user account is disabled or deleted. Unbeknown (hopefully) to the payroll clerk, they could probably delete or overwrite the entire database file if they accessed it directly using a file share instead of through the application view (called view-based access control). Our security is based on obscurity and the hope that our employees don't want to harm the company. What's to stop the employee from downloading the entire database to gazillion-gigabit USB drives and taking it to a competitor?

Time to start
If you don't have a role-based security model, you should start researching it and strive to move to RBAC, if only a tiny step at a time. You can start by defining your access control security groups by roles instead of departments. Don't designate HR, IT, and accounting security groups; instead, create security groups for each department based on their roles. Look to your company's organizational chart or job descriptions if you need a beginning point.

Start investigating software that uses an RBAC model. Look at the RBAC tools in your OS, whether it's Windows, Linux, Unix, OS X, Solaris, or something else. Investigate software that can bring role-based access control to your environment. Just use the keywords role-based access control or role-based management in your favorite Internet search engine.

Ask your software vendors what they are doing to facilitate RBAC in your environment with their products. Educate your vendors if they have never heard of it. When the vendor hears it enough or if you have enough dollar votes alone to make it happen, the vendor will become a RBAC proponent. Then everybody wins.

Implementing a RBAC model is a lot of work and a lot of groups, but anything less means you aren't truly implementing least privilege in your environment. Until you have RBAC, least privilege is just something you repeat over and over as a mantra, but can't really accomplish.

Posted by Roger Grimes on November 30, 2007 03:50 PM