No one would argue that software auditing is not an important feature of mission critical applications. If a software based process is critical to the life of your company, then so is the security and access control surrounding resources managed by that software based process. Auditing is the way you track who did what to what and when it happened. Lately, however, the software industry has been lackadaisical at best regarding auditing. Off the shelf software developers either care about auditing, or they don’t. When they do care, they either create elaborate custom auditing solutions that don’t inter-operate with existing tools, or they simply send a few extra messages to the system logging facility and call it auditing—more often the latter. This article is about the benefits of the Open Group’s Distributed Auditing Service (XDAS), and particularly about OpenXDAS, a free software implementation of the XDAS standard sponsored by Novell.

A quick history of software auditing

In the early days of computers, software was almost a by-product. When companies like IBM and Hewlett Packard were custom-manufacturing large mainframe computer systems for banks, businesses and institutions the software was free. Heck, if you bought a computer back then, you probably just blew any budget you might have had for software, anyway! But that’s the way things were done. Computer hardware was so expensive that hardware manufacturers would write and maintain custom software for their customers—almost as a fringe benefit.

As requirements were collected, software developers would try to find a fit between existing software they’d already written, and the software system that would fall naturally out of the requirements gathering process. Sometimes, only small changes were necessary to the customer’s process in order to reuse an existing package already written for a previous customer. At that point, negotiations between customers and developers would result in the ability to reuse some existing software, with perhaps a few customizations. But since computers were a big deal back then, customers were willing to change their processes significantly in order to accommodate the “requirements” of the computer.

Heck, if you bought a computer back then, you probably just blew any budget you might have had for software, anyway!

Over the last 30 years, the roles of hardware and software have become juxtaposed. As elaborate general purpose software systems were developed, hardware manufacturers found it more and more difficult to sell their wares to a customer based on the merits of the hardware. Customers began to expect all of the features of certain well-known software systems from their hardware vendors. Slowly vendors began to make the transition to selling the software for real money, while nearly giving away the hardware.

Free market pressures have pushed this paradigm to the limit in recent years with common off the shelf (COTS) software packages. It now costs far less for both hardware and software than it ever has, but the ratio of software prices to hardware prices has stabilized at around two to one (respectively). For a real world example, a reasonably high-end Intel processor-based CAD/CAM system today costs about US$3000. But a copy of AutoCAD 2006 costs twice that amount, at around US$6000.

What’s happened to our priorities?

Unfortunately, those same free market pressures that brought (relatively) cheap hardware and COTS software to market have also hurt software quality. Software features that are not readily visible to CEOs such as auditing have slipped through the cracks. Software security architects often know the advantages of software auditing, but don’t have the clout they need with their engineering and product managers to ensure that auditing is a well-designed aspect of their company’s software products. Auditing is not sexy and, much like insurance policies or regular backups, it’s not missed until there’s a problem.

There’s no doubt about it—our priorities have degraded to the point where we’re willing to settle for whatever we can get these days with regard to software auditing or other important back-end features.

Auditing vs. logging

Let me lay it on the line for you. Logging is not auditing. It’s really that simple, and yet we’re being sold a bill of goods these days by software vendors who don’t really understand proper software auditing anymore than we consumers do.

By logging, I mean either the use of existing logging systems as the Unix Syslog facility, or the Windows application and security event logs. Or, even more simply, the use of a file-based logging system, where software sends messages to the log file whenever something happens that is considered worthy of such a message. Often what’s considered worthy is extremely subjective—arbitrary really—as developers are given the task to “log something”, so sales people can spout terms like auditing and logging with some degree of integrity.

But auditing is really very much more than logging. Logging allows a system to send free-form informational messages to the console or to a log file. Log messages are really designed from the start to be read by humans. They contain informational text messages such as, “Xenobar system successfully started on 3 Oct, 2006 at 15:32”, or “Footech subsystem loaded properly”. Audit messages, on the other hand, should be machine readable. Not that they should be unreadable by humans, but rather that they should be easily parsed and categorized by software.

Logging is not auditing. It’s really that simple

The software I’m talking about here is called security analysis software. Entire companies have become prosperous by providing security analysis software that spends literally 90 percent of its CPU cycles just parsing and categorizing human readable log messages. They spend most of their time trying to heuristically extract minuscule bits of security-relevant information from near useless log messages pumped out by mission critical software packages. The Sentinel product by eSecurity (recently acquired by Novell) is an example of such a security analysis software package.

And now, consider what happens when a new version of Xenobar is shipped, and the latest developer working on this version decides to change all of the log messages throughout the program because he doesn’t like the format used by the previous developer. After all, they’re just log messages, right?

“But,” you say, “if a company recognized that security analysis software would be designed to read their log messages, could they not provide a well-defined format, and then ensure that it never changes from version to version?” Sure, and this has been done before. Novell’s eDirectory product, for example, contains a trace facility that is widely used by eDirectory customers for many reasons—including system auditing. This trace facility was originally intended to be used only as a debugging tool by eDirectory engineers, but they soon discovered that several key customers were relying on third-party tools to parse eDirectory trace logs, in order to extract information critical to their business processes. After that, the developers were ordered not to change the format of most of the trace messages between versions. It’s sad really, because now this debugging tool can no longer be used effectively for its original purpose—to help engineers find and fix defects in the product.

Proper auditing demands three key features:

1. An application programmer’s interface or API, entirely separate from the logging facility.
2. A common standardized audit event record format.
3. A common standardized audit event taxonomy (a set of events with associated well-defined and documented semantic meanings).