And then…

I spent most of last week in Boston, attending the Red Hat Summit. This is an annual show put on by Red Hat to discuss various topics of interest to their customers, partners and analysis. I was there because Likewise is a Red Hat partner and because we received an Innovator of the Year award.

I sat in on various sessions. One of the most interesting ones was an update on changes to the auditing system in the Linux kernel and in the associated Red Hat tools.

What is auditing? Auditing is the ability to detect access to specific resources and to note who performed the access and when the access was performed. Examples of this are auditing when someone reads from or writes to the /etc/passwd  in UNIX or when someone tries to add a member to the Domain Admins group in Windows Active Directory. In both of these cases, there might be completely legitimate reasons for such access. Auditing is about collecting information, not about enforcing security. Of course, if security is violated, auditing information can provide forensic evidence to discover whodunnit and what was dun.

The auditing system in Red Hat and others versions of Linux is implemented by a combination of kernel modifications and code in the auditd daemon. Auditd reads configuration files and informs the kernel what information it’s interested in. When relevant events are detected in the kernel, it signals back to auditd that, in turn, generates log information and/or passes information to other interested parties.

Auditd provides a rich set of things that can be audited. For example, any system call can be logged as can access to any file.

Configuring auditd is not trivial. Here’s a link to a page that describes how it’s done. Additionally, if you want to read audit output, it can be messy, too.

As with most things UNIX-y, there’s little consistency between versions. Linux offers one thing. Solaris, HPUX and AIX all offer something different (from Linux and from each other!). They all do more or less the same thing.

And then there’s Windows.

Windows takes a fundamentally different approach to auditing. In Windows, the auditing mechanism is almost identical to its security mechanism. Security is implemented by using access control lists (ACLs). So is auditing.

Windows supports two types of ACLs: discretionary ACLs (DACLs) and system ACLs (SACLs). The former is used for security, the latter for auditing. Just as Windows uses a DACL to determine if a user has access to a resource, it uses the SACL to determine whether or not the access should be logged. Log output is sent to event logs.

The ACL approach means that Windows can audit access to any resource that has ACLs associated with it. You can audit access to a file (or to entire directories since ACLs are “inherited”). You can also audit access to registry entries or nodes in Active Directory. Of course, things without ACLs cannot be audited. You can’t audit when an application calls a specific system call, for example.

OS auditing is a very powerful feature that can give you assurances that your security systems are working effectively and that your privileged users are not unnecessarily accessing restricted data. Even in Windows, however, where configuring the audit system is easy, I think the features are underutilized. In UNIX/Linux/Mac I suspect they’re used by fewer than 5% of users.

In the Implementing Effective Access Control webinar that I did a few days ago, I spent a little time talking about sudo. It’s a pretty cool utility that, I think, is vastly underutilized. With some care, sudo can be the basis for a powerful role-based access control (RBAC) system on Linux.

Sudo is a Linux/UNIX/Mac OS X utility that reduces the need to run as root. Rather than logging in with the root account in order to access priviliged commands and restricted files, you log in with your personal (non-administrative) account and then invoke the sudo program whenever you want to perform an operation that requires root priviliges.

For example, to restart the network, instead of logging in as root and running:

/etc/init.d/network restart

You would log in with your personal account and run:

sudo /etc/init.d/network restart

The sudo command runs the privileged command for you after first consulting its configuration file, /etc/sudoers, to verify that you’re allowed to run the command.

In addition to minimizing the need to share the root password, sudo is also valuable because it performs logging. The command above would result in a log entry being written that identified who (your personal account) performed what operation (the network restart).

While we find that our customers are familiar with sudo, we find that many of them don’t use it. The problem with sudo is that, to use it, you need to carefully design a correspoding /etc/sudoer configuration file. Clearly, you don’t want everyone to be able to perform every privileged operation. You want to design a set of roles, for example:

• System administrator
• Database administrator
• Storage administrator
• Developer
• Help desk assistant
• End user
• …

And then you want to determine what privileged commands will be available to each of these roles. Finally, you need to assign roles to your users.

Adding individual users to /etc/sudoer can be painful. If new employees are being hired and fired frequently, it’s inconvenient to have to push out new versions of this file to all the machines in your network. Although /etc/sudoer allows the referencing of user groups instead individual users, without a centralized authentication system, identifying groups in sudo is no more convenient that identifying individual users. Each time an employee is hired or fired, you’ll need to push out a new /etc/groups file to all of your systems.

This is where our software comes us. Likewise allows Linux/UNIX/Mac OS X machines to authenticate users with the Active Directory credentials. We allow these non-Windows machines to be joined to AD and to perform Kerberos/LDAP based authentication against AD without any local account.

With Likewise, adding/removing employees from AD groups is all done at the central LDAP repository; no file needs to be updated on each participating Linux/UNIX/Mac OS X machine. Additionally, Likewise extends the Microsoft group policy architecture to these non-Windows systems and provides a GP setting for sudo. We can use group policy to distribute sudo configuration files automatically.

The combination of Likewise software and sudo makes it much, much, easier to eliminate the use of privileged accounts by relying on sudo as controlled by AD group memberships.

Strangely enough, there’s no equivalent functionality in Windows. The closest thing to sudo is the ability to runas another user (impersonation). At the shell level, you can right click on an application icon and invoke the Run As… menu item. You can then specify the credentials for an administrator and run an application to which you might not normally have access. With this technique, however, you still need to know the credentials for an administrative account.

At least one third-party implementation of sudo for Windows has been written (this one).

A few days ago, I prepared a Powerpoint presentation and a demo script for a Webinar. The topic under consideration was Implementing Effective Access Control.

The first thing I did was to look for a good definition of “Access Control.” As usual, Wikipedia did the trick, “Access control is the ability to permit or deny the use of a particular resource by a particular entity.” Pretty straightforward.

After defining the term, I demonstrated several different ways that our product (Likewise) provides to implement access controls. I came up with 4 different mechanisms and I know I skipped at least a couple of variations! Likewise lets you implement access controls by placing restrictions on a user account, by manipulating Cells (groups of computers), through access control lists on resources and by using group policy. There are other ways, too, based on setting ACLs on computers and by directly editing configuration files.

On one hand, we can brag about the power of our software. We’ve got enough mechanisms that we can satisfy anyone. Some customers don’t want to use group policy for non-Windows computers; fine, they can use Cell-based mechanisms. Others want a simple Cell architecture and no GP; fine, they use account restrictions or they can set configuration files manually.

On the other hand, when you step back and note the plethora of access control mechanisms, it’s hard not to think that all this should be easier to accomplish.

The real art in software development is providing power while maintaining usability. “Powerful, yet easy to use” has become such an oft-repeated mantra that it has lost all marketing value. Too many programs have promised such but failed to achieve one of the goals (or both!).

Although Apple has a well-earned reputation for delivering capable-yet-usable products, let me mention a couple of others: cars and cameras.

When I look at the dashboard of my car (one with, admittedly, more doodads than most) I note over 100 different buttons that I can press. Controls for windows, wipers, lights, radio, climate, GPS, traction control, locks, cruise control, turn indicators, telephone, parking radar, heat seaters, rear shade, etc. My car has a button that controls whether my door mirrors stick out, pull in or move in and out automatically. If I include “soft” buttons on the touchscreen GPS device, there’s probably more like 200-300 buttons.

In spite of the complexity, it took me less than one hour to learn 95% of the car’s functionality (I still don’t know how to set Address book entries without a Bluetooth phone).

I had a similar experience when I checked out the Canon 40D and Rebel XSi, recently. I was able to flip through the various exposure modes, figure out how to squeeze off multiple shots, and how to perform several other basic camera features. I dutifully noted the “CF” button on the back, but didn’t press it.

Why is that cameras and cars are easier to manipulate than spreadsheets and word processors? You can argue that the latter offer more features, but I think that 200-300 car features is probably comparable to the number of features I use in office products.

I think the key difference is whether or not people have a good existing mental model of how something is supposed to operate. I know, for example, that pretty much any non-American car is going to turn headlights on and off with some stick on the left side of the steering wheel. I’m probably going to pull it back and forth to activate the high beams. I know that there’s going to be an AM/FM band selector for the radio and that there’s going to be a button (probably, with a red triangle on it) that controls the emergency flashers. Every once in a while, I’ll rent an American car and I’ll have to hunt for a headlight know on the dashboard, to the left of the wheel. Every once in a while, too, I talk to someone old enough to remember the metal “pushbutton” on the floor that controlled the high beams on American cars until about 1970.

I knew how to operate the Canon cameras because I already own a Canon camera. Canon is smart enough to minimize UI differences between cameras. They’re also smart enough to exploit common standards or practices. The exposure mode knob is pretty standard on most cameras (with settings for “P”, “M”, “Av” and “Tv” and a bunch of icons). The “CF” button though is not. “CF” stands for “Custom Function”. This is where Canon “hides” about 25 functions that only advanced (or anally retentive) users need to access.

Cameras are a great example of the need to balance power and complexity. The Canon 40D is a formidable instrument. It provides tremendous flexibility over shutter speed, aperture control, flash synchronization, mirror lockup, picture resolution, etc. Either that or you can just put it on “P” and press the shutter.

“Software”, broadly, has no such well-defined model for how it should operate. There are some standard paradigms (for example: establish a selection and then perform an operation on it), but beyond the basics, there is too much variation between applications. For a while, we could count on “File”, “Edit”, “View” and “Help” menus but now Microsoft has gone and messed that up, too. After months of using the new version of Office, I’m still playing “find where they’ve gone and hidden my favorite operation.”

My only excuse when preparing my talk was that, at least, we only make matters a little more complicated. For the most part, the access control mechanisms that we provide are ones with which our customers should already be familiar (on Windows computers). We extend these mechanisms to work with UNIX, Linux and Mac OS X computers adding “only one” new one: the Cell concept. Here, too, we associate Cells with AD organizational units rather than inventing a parallel administration entity.

By the way, if you want to watch the recorded Webinar, you can see it here.

Computer authentication is all about making sure that people are who they say they are. Authentication is usually the first step that you have to perform before being allowed to work on a computer.

For most of us today authentication is synonymous with entering a username and password. Passwords are one form of authentication and when you perform only one such form you are employing single factor authentication.

Two factor authentication is becoming increasingly important. Passwords are much too easy to “steal” by guessing them, phishing for them or simply looking under mouse pads.

Two factor authentication requires, naturally, two mechanisms for authentication. A password might be used but only accompanied by something else. What other authentication “factors” are there?

Wikipedia has a good taxonomy for authentication techniques. It breaks up authentication into three categories:

A password is an example of something a person knows. A smartcard is an example of something the person has. A fingerprint is an example of something a person is or does.

In case you’re thinking that a person has a fingerprint, you may be right. The difference between has and is may not always be easy to ascertain. To some degree, it’s a matter of convenience and intended purpose. The intended distinction between the two categories is that while you can lose or give away something you have you can’t do the same with something you are or do. This is mostly true although, if you saw Minority Report or, more recently, the made-for-TV version of The Andromeda Strain you’ve seen gruesome fictional depictions of “stealing” eyeballs and fingerprints.

Two factor authentication requires that two authentication techniques be employed. Ideally each technique would use a different mechanism. Perhaps something you know (a password) and something you have (an RSA or Verisign OTP device). Some companies, however, have started to make use of two factor authentication based on two things the user knows. You’ve probably seen banking Web sites, for example, that ask you for a password as well as your mother’s maiden name or the name of your pet.

Being in the security space, my company has spent a lot of time looking into the issue of two factor authentication. Smartcards seem like a great idea but we are disillusioned by inconsistent implementation of standards and the need for a plethora of drivers for different devices and different cards. OTP (one time password) devices don’t require any drivers but the companies that dominate the market (RSA and Verisign) are not very partner friendly.

Employing biometrics seems like a good alternative to relying on what the user has. IBM/Lenovo laptops have been shipping fingerprint readers for years. Microsoft makes an inexpensive fingerprint reader, as well.

Maybe, soon, giving your computer “the finger” will take on a completely different meaning.

My company sells software that allows users to login to non-Windows computers by using their Windows (Active Directory) credentials. We enable users to have a single username and password that works across all Windows, UNIX, Linux and Mac OS X systems.

While there are several “vertical” markets in our space (retail, financial, government) one particularly interesting one is the educational market. Schools, universities in particular, frequently run many different operating systems and frequently need to provision (add) and deprovision (remove) user accounts as students enroll and graduate (or fail to graduate!).

Microsoft Active Directory performs authentication by using the Kerberos protocol. This security protocol was developed by MIT and features various clever cryptographic techniques that make it valuable for user authentication. For various reasons, however, Kerberos is used exclusively within corporate networks; it is not used to authenticate users on the public Internet. Users will login to their desktop or laptop computers and will be authenticated by an Active Directory (AD) server within the corporate network. When users access resources within the corporate network their AD credentials are re-used (what is termed, single sign-on) and they are not prompted for any new credentials. When those users try to access resources (for example, secure web pages) in the public internet, however, other security protocols are used (for example, basic authentication over SSL) and the users typically have to type in new credentials.

This concept of authentication inside and outside the firewall, I believe, may soon be a thing of the past and some educational customers demonstrate why.

Although many universities still employ firewall-based architecture others have resigned themselves to a porous network and treat all computers as, essentially, being on the public Internet. From the IP addressing perspective, their computers typically are within a protected network. Few large organizations have enough publicly assigned IPv4 address space that they can put all machines directly on the Internet; they use private networks, NAT (network address translation) and routers/firewalls to allow external access. From the practical perspective, however, some universities are assuming that their internal networks might be completely compromised.

Our product is of limited use to these schools. They still have private networks for things like accounting and student record keeping but these private networks are further isolated from their general university-wide networks. They might be in subnetworks within the general networks or they may be completely disconnected from any network that their students can access. They might choose to use our product within those private subnetworks but not to perform authentication throughout their general university-wide networks.

I think we will see similar moves in corporate networks. At some point, organizations will concede that it is impossible to protect their entire internal networks. Rather than putting up a wall around their entire organizations, some companies will choose to protect critical applications (payroll, human resources, etc.) but will assume that all users in their general corporate networks are potentially hostile. This will actually make it easier to implement wide area networks as there won’t be much need for VPNs. A user in the corporate network will not be considered to be any more trustworthy than a user in the public Internet. Users in remote offices might as well come in directly through the public network instead of setting up a virtual private network. Either way, some more secure mechanism will have to be used when a user tries to access a protected resource.

I’m still not sure what this mechanism will be. It might be some type of identity federation (based on Active Directory or not) but I’m concerned about slow adoption rates and the complexity of setting up federation between organizations. Perhaps Network Access Control and/or dual-factor authentication will play important roles, too.

One thing I am sure of is that, like funeral parlors and waste management, the security business will never go away.